Bug#1064394: release-notes: English language output for the commands into script session
Franco Martelli wrote: >> 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? > > 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 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.) >> 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". > > It's more popular to use a non-privileged home directory. I don't follow: /var/tmp is a non-privileged location that anybody can 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. > Few people strictly adhere to the FHS ¹ specifications. 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 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. 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. > ¹ https://refspecs.linuxfoundation.org/fhs.shtml 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. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#1064394: release-notes: English language output for the commands into script session
On 21/02/24 at 23:49, Justin B Rye wrote: 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. Yes, users have to choice if they want to change localization inside the "script" session. 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? 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. 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". 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
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
Bug#1064394: release-notes: English language output for the commands into script session
The following message is a courtesy copy of an article that has been posted to gmane.linux.debian.devel.documentation as well. Franco writes: > " 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." Are we *sure* this is a good idea - i have some doubts? -- "strongly recommended" by who? where did anyone previously make this recommendation and why do they feel so strongly that it is needed in 2024 when it has not been suggested before? -- does anyone test the upgrade with this locale setting? telling people to use something less tested seems like a bad idea.eg, i have LANG=en_GB.UTF-8 would i still want to change locales? -- why are we suggesting non-english message are somehow less clear? if so, we should remove translations not hide them? -- why are we making the output harder to read for the user - that will make it harder for them to fix their own issue. isnt this is the opposite of what we want? -- isnt it better to say that if you get an error in non-english to search the web for the english vesion? it's not like you cant look-up the english version of the error message -- are we suggesting errors are likely? that isnt my experience with debian upgrades (maybe it makes more sense to do this if the upgrade fails and you can't debug)
Bug#1064394: release-notes: English language output for the commands into script session
On 21/02/24 at 16:00, Justin B Rye 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. Yes, my English is so scholastic. 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. I agree (Or do we also need to warn users to say "yes" and not "si"?) It shouldn't be necessary, if the user is comfortable with English, already he should expect this. However end users behavior is unpredictable … 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. 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). 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 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. (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? 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? 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. -- Franco Martelli
Bug#1064394: release-notes: English language output for the commands into script session
Franco wrote: > 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 --- I like this idea; but it might work better if we turn things around and start with the possible problem before offering the solution. > " 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 --- 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"?) > 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. 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.) > ¹ > https://www.debian.org/releases/testing/release-notes/upgrading.en.html#recording-the-session > ² https://lists.debian.org/debian-user/2024/02/msg00562.html 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:--] > Could I suggest that the syntax of "script" command in the "4.4.1. > Recording the session" section it should be: > > # script -T ~/upgrade-trixie-step.time -a ~/upgrade-trixie-step.script 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? -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#1064394: release-notes: English language output for the commands into script session
Package: release-notes Severity: wishlist X-Debbugs-Cc: martelli...@gmail.com 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
