Bug#1064394: release-notes: English language output for the commands into script session
I've just noticed that we're discussing this on debian-doc without
always Ccing the bug - see
https://lists.debian.org/debian-doc/2024/02/threads.html
Franco Martelli wrote:
>> immediately preceding line invoking screen with a 2>~/foo redirection*
>> won't work on csh (tested with bookworm's tcsh).
>
> Yes, the redirection of only stderr is not allowed in csh but with the new
> "script" command syntax this will be solved:
>
> # script -T ~/upgrade-trixie-step.time -a ~/upgrade-trixie-step.script
(We're imagining italic "variable" markup on "-step")
>> So I'm not sure there's any point using anything longer than:
>>
>> # export LC_ALL=C.UTF-8 LANGUAGE=
>
> Yes, but what's wrong if we have a syntax portable to all shells? If
> available.
What's wrong is that people might use csh! Nobody's been checking the
Release Notes for csh-compatibility, so recipes assume you can say
things like "cd $(mktemp -d)". Who are these people using csh, and
how do we stop them?
(In fact that use of $() is the only other incompatibility I can see
at the moment, but who's going to remember to check each new incoming
recipe next year?)
>> (But doing it separately from starting "script" does make sense, if
>> only to give us room for an explanation.)
>
> Sorry I missed the sense, what explanation?
If we said "LC_ALL=C.UTF-8 LANGUAGE= script -T ..." it would have all
sorts of disadvantages, including the fact that we'd have to explain
all of it together. Much easier to explain about script, then suggest
a "script -T..." commandline, *then* deal with locales separately.
>> I don't think the Release Notes ever mention the fact that we assume
>> a Bourne shell, but if you boot into an initrd rescue shell expecting
>> it to be csh then your day hasn't finished getting worse.
>
> Again, only if available, why don't we use a portable syntax to all shells?
"Portable" in the sense of "POSIX-ish" (including things like ksh or
zsh) makes sense. But the thing we should be recommending to anyone
doing a dist-upgrade under csh or fish or intercal is "please stop".
>> Ah, yes, avoiding the tricky redirection syntax (worthwhile even if
>> we don't care about csh). But if we're assuming this is already a
>> root session, "~/foo" will put that log in /root/; maybe we should
>> say that instead of using tilde-expansion?
>
> I'm for tilde-expansion I find it more elegant and more widespread use for
> referring to the home directory.
The question is, will users realise that they're putting the files in
*root's* home directory, and will they even know where that is?
If we really can't suggest using /var/tmp for this, that seems a pity;
that location *shouldn't* be wiped on reboot, and it's usable whether
you're running "sudo; screen" or "sudo screen" or "screen; sudo".
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: