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