Dear Debian Documentation Project staff,

I want to suggest to add a sentence like the following to the §4.4.1 "Recording the session" paragraph. ¹  Below the "script" command:
--- BEGIN of the statement ---
" If you are comfortable with English language it's strongly recommended that you run the following command as soon as you start the 'script' session:

  # LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE

  This will allow you to get command output messages in English into the script session. By doing so, it will help you for searching the web, during discussions or to submit a bug report."
--- END of the statement ---

This change it has been discussed on debian-user mailing-list here. ²
The syntax of the command was designed to be portable to all shells, csh included.


¹ https://www.debian.org/releases/testing/release-notes/upgrading.en.html#recording-the-session
² https://lists.debian.org/debian-user/2024/02/msg00562.html

Franco wrote:

I like this idea; but it might work better if we turn things around
and start with the possible problem before offering the solution.

A rephrased version:

    If you use a non-English locale during the upgrade, any progress
    or error messages are likely to be translated, so in the event of
    problems it may be difficult to get assistance from the Internet,
    or to submit a bug report. If you are comfortable using English
    then it is strongly recommended that you run the following command
    at the start of your 'script' session:

    # LC_ALL=C.UTF-8; LANGUAGE=; export LC_ALL LANGUAGE

    This will give you command output in English.

(Or do we also need to warn users to say "yes" and not "si"?)

I'm sorry, but if you're doing vital root-privileged sysadmin tasks
under csh, things have already gone badly wrong; the instructions in
the Release Notes all assume a Bourne-family shell.  For instance, the
immediately preceding line invoking screen with a 2>~/foo redirection*
won't work on csh (tested with bookworm's tcsh).

So I'm not sure there's any point using anything longer than:

   # export LC_ALL=C.UTF-8 LANGUAGE=

(But doing it separately from starting "script" does make sense, if
only to give us room for an explanation.)

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.

[--just as I was about to hit SEND:--]

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?

Yes, my English is so scholastic.

I agree

It shouldn't be necessary, if the user is comfortable with English,
already he should expect this. However end users behavior is unpredictable …

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

Yes, but what's wrong if we have a syntax portable to all shells? If
available.

Sorry I missed the sense, what explanation?

Again, only if available, why don't we use a portable syntax to all shells?

I'm for tilde-expansion I find it more elegant and more widespread use
for referring to the home directory.

The following message is a courtesy copy of an article
that has been posted to gmane.linux.debian.devel.documentation as well.

Franco <martellif67@gmail.com> writes:

Are we *sure* this is a good idea - i have some doubts?

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:

(We're imagining italic "variable" markup on "-step")

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?)

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.

"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".

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".

Yes, users have to choice if they want to change localization inside the
"script" session.

A minimal assumption of knowledge base of the FHS ¹  and tilde-expansion
should be take by Release Notes writers. I think we shouldn't worry
about this.

It's more popular to use a non-privileged home directory. Few people
strictly adhere to the FHS ¹  specifications. This is why I am in favor
of using tilde-expansion. No matters if the reader becomes root or runs
"script" as non-privileged user: the files will always go in the home
directory, where they will be used by "scriptreplay" command. By doing
so we won't have to take care of where the files reside.


¹ https://refspecs.linuxfoundation.org/fhs.shtml

Franco Martelli wrote:

It's possible to be a heavy commandline user for a long time without
discovering that ~/ can expand to /root/.  But we've got onto a
sidetrack from the main issue of this bugreport, and I probably
shouldn't have brought it up in the first place, since files are
dropped into ~/ in quite a few of the recipes in the Release Notes,
and changing them all would be more trouble than it's worth.

(So this email really ought to stop here.)
write to, and continue accessing before and after switching to a
different user account.  On the other hand, files created in /root/
aren't accessible to normal users, even if they know where to look.

People who diverge from the standards (e.g. by setting up an
overenthusiastic tmpreaper, if that's what you're thinking of) need to
remember their automated footguns and make allowances for them.

This is backwards.  If I use ~/, it expands to whatever home directory
is listed in /etc/password for my current user, and that can vary
non-obviously depending on what user I am.  The alternative is to give
an explicit path like /root/, in which case it's obvious what location
it's talking about - though it'll fail if they haven't run sudo yet.

Then again there's the option of using ./, which is another can of
worms.  Part of the problem is that we don't have a section saying
"start by getting a root commandline in a sane shell with a sane PWD";
if we did, that would also be a good place to go into the question of
appropriate locales.  Or maybe it would just encourage users to skip
that whole boring section to get to the "apt full-upgrade" part.

Most users haven't read that.  I know *I* hadn't looked at it since
before they updated it for /run and usrmerge and so on.