Re: GROUPS
On 8/11/21 8:00 PM, Franklin, Jason wrote: Chet: My apologies in advance for not responding in thread. The bug-bash archive interface doesn't expose the "Message-ID" header anywhere I can find, and I am not a subscriber. I suppose I should become one. :) I believe I'd rather have variables behave as they're documented. It's more predictable. Is it? Sure. Bash behaves as documented. The whole point of a standard like POSIX is that I should be able to write my code in accordance with the standard and have it run on compliant systems that I may not even be aware of or that might not have been developed yet. As long as you stick to things POSIX standardizes. Relevant here, the standard even includes a list of variables you should avoid using because various shells and applications use them. The standard determines what is "predictable" behavior, not the Bash documentation. Come on. The bash documentation describes how bash behaves. That's one of the problems here: the author never intended this script to run in any shell other that Debian's dash. If they had, maybe they would have tested it on other shells, even other shells that Debian includes. The author intended for portability and POSIX compliance. Otherwise, the script header would not have read "#! /bin/sh". It runs as expected on dash and ksh. Obviously not, since they never tested it on bash. It's more likely they expected it to run on Debian's /bin/sh -- hence the hashbang -- which is dash. POSIX is supposed to enable portability. Compliant code should run the same on any compliant interpreter or compiler. How can I possibly test on all systems that try to be compliant? I may not be aware of all of them or one may not even exist yet. That's an argument against extensions outside what POSIX standardizes. If you want a shell like that, they exist, but bash is not going to be that shell. Requiring someone to test on all possible current and future shells that claim POSIX-compliance defeats the purpose of a reference. As an aside: I believe in thorough testing in as many environments as feasible! Even then (using either solution), what does a script do if it wants to be invoked as: GROUPS='abelian ...' script [options] ? That case works, see above. Maybe it shouldn't, but it does. This doesn't work unless it was recently fixed. A variation does... The assignment preceding the command is performed in the current shell context and obeys the current shell's assignment rules. If bash sees GROUPS in the environment, it doesn't create a special variable with that name, as you discovered. The same with UID and EUID. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: GROUPS
On Fri, Aug 13, 2021 at 10:10:42AM -0400, Chet Ramey wrote: > As long as you stick to things POSIX standardizes. Relevant here, the > standard even includes a list of variables you should avoid using because > various shells and applications use them. Just out of curiosity, where is that? It's not under section 2.5.3 Shell Variables, which is where I looked first. The closest thing I could find is a section in the Rationale that describes some variables that are no longer covered by the standard, but either used to be, or are commonly used as extensions: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag_23_02_05_03 Is there another section that I've missed? > Obviously not, since they never tested it on bash. It's more likely they > expected it to run on Debian's /bin/sh -- hence the hashbang -- which is > dash. For the record, Debian uses dash as /bin/sh by default in modern versions, but historically, it used bash. And it still offers the user a supported means of switching "back" to bash as /bin/sh, for systems that require it. A Debian shell script which uses #!/bin/sh should be written to work under bash *or* dash (at the very minimum). If it fails under either of those shells, it's a bug.
Re: GROUPS
On 8/13/21 10:32 AM, Greg Wooledge wrote: On Fri, Aug 13, 2021 at 10:10:42AM -0400, Chet Ramey wrote: As long as you stick to things POSIX standardizes. Relevant here, the standard even includes a list of variables you should avoid using because various shells and applications use them. Just out of curiosity, where is that? It's not under section 2.5.3 Shell Variables, which is where I looked first. The closest thing I could find is a section in the Rationale that describes some variables that are no longer covered by the standard, but either used to be, or are commonly used as extensions: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag_23_02_05_03 Is there another section that I've missed? https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08 "It is unwise to conflict with certain variables that are frequently exported by widely used command interpreters and applications:" -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: gettext feature request
Le 12/08/2021 à 16:29, Chet Ramey a écrit : On 8/11/21 6:35 PM, Jean-Jacques Brucker wrote: Thank a lot Chet. I still think it would have been more consistent to extend the $'...' syntax. Why would it be more consistent to add translation to a quoting syntax that didn't have it than to post-process translations in a different way? Chet I'm probably less familiar with the history of shells and bash than you (and others on this mailing list), but it seems to me that: First were the chains: * '...' who did not expand anything * "..." which expanded the syntaxes $VAR and the unfortunate `...` [1] Then the syntax $"..." was introduced, then the syntax $'...' (bash 2.X). As the character '$' means "interprets (synonym: translates) what follows", it seems to me quite consistent that $"..." means "translates the entire following string" Conversely, the syntax $'...' seems to me much less consistent. (Reminder: C is prior to shells, and bash is itself written in C). However, the "C-string" feature is very useful (and nowadays probably more used than the translation feature). In absolute terms, if one day we would list all the historical design errors, dare to break some compatibilities, and manage to establish new shell standards (I'm probably dreaming ... but do we ever know ?). Then we could have: 1. "...": expanded shell string 2. '...': unexpanded shell string 3. `...`: unexpanded C string (today $'...' :-/ ) and logically: 4. $"...": translated expanded shell string (to NOT use for security reasons) 5. $'...': translated unexpanded shell string (soon released $"..." with shopt noexpand_translation !?) 6. $`...`: translated unexpanded C string (the feature[2] I dream of the most, maybe soon $'...' with a shopt like translate_c_string ?) [1]: cf. https://www.grymoire.com/Unix/Sh.html#uh-8a [2]: What I like the most about this feature, and that I could directly reuse existing translation chains. Not only to dig into the many existing C translations, but also not to redo the translations when, for various reasons (performance, etc.), we are forced to rewrite bash code in a compiled language. OpenPGP_signature Description: OpenPGP digital signature
Re: GROUPS
On Fri, 2021-08-13 at 10:10 -0400, Chet Ramey wrote: > As long as you stick to things POSIX standardizes. Relevant here, the > standard even includes a list of variables you should avoid using because > various shells and applications use them. GROUPS is not on this list that I can tell. It would be impossible for the standard to list every variable that may be treated as special by some shell or another. > > The standard determines what is "predictable" behavior, not the Bash > > documentation. > > Come on. The bash documentation describes how bash behaves. This evades the principle I'm trying to convey. Developers should be able to code tightly against the standard and have their code move easily between interpreters and compilers (which might not yet be written). If you were writing a C program, and you wanted to use a variable "foo", and you moved the project to another compiler and you were shut down because assignments to "foo" at runtime were silently ignored, you'd be surprised. > > POSIX is supposed to enable portability. Compliant code should run the > > same on any compliant interpreter or compiler. How can I possibly test > > on all systems that try to be compliant? I may not be aware of all of > > them or one may not even exist yet. > > That's an argument against extensions outside what POSIX standardizes. If > you want a shell like that, they exist, but bash is not going to be that > shell. Now, this is at least addressing the core of the issue. The only problem here is that Bash won't run otherwise perfectly POSIX-compliant scripts that happen to use no extensions and happen to assign to the variables GROUPS, UID, or EUID, etc. Of course, it sounds like Bash calls these variables extensions. > > > Even then (using either solution), what does a script do if it wants > > > to > > > be invoked as: > > > > > > GROUPS='abelian ...' script [options] > > > > > > ? > > > > > > That case works, see above. Maybe it shouldn't, but it does. > > > > This doesn't work unless it was recently fixed. A variation does... > > The assignment preceding the command is performed in the current shell > context and obeys the current shell's assignment rules. > > If bash sees GROUPS in the environment, it doesn't create a special > variable with that name, as you discovered. The same with UID and EUID. Right. So, If I want to write the following script... #! /bin/sh FOO=x /usr/bin/other_program I need to keep two things in mind: 1. FOO might be special under whatever shell /bin/sh is linked to. 2. Even if working with bash, FOO might be made special in a future version of bash while it's not special now. All of my scripts must thus look like this now... #! /bin/sh unset FOO FOO=x /usr/bin/other_program Of course, this still may fail if the shell that actually runs this script happens to make FOO readonly in its current or future version. I think this topic has been exhausted. I don't have much else to say here. I am aware of the behavior now, so I can't run into this myself. However, the choice to keep this behavior seems like an odd one. -- Jason
Re: gettext feature request
Le 13/08/2021 à 18:14, Jean-Jacques Brucker écrivait :
Le 12/08/2021 à 16:29, Chet Ramey a écrit :
On 8/11/21 6:35 PM, Jean-Jacques Brucker wrote:
Thank a lot Chet.
I still think it would have been more consistent to extend the $'...'
syntax.
Why would it be more consistent to add translation to a quoting syntax
that
didn't have it than to post-process translations in a different way?
Chet
I'm probably less familiar with the history of shells and bash than you
(and
others on this mailing list), but it seems to me that:
First were the chains:
* '...' who did not expand anything
* "..." which expanded the syntaxes $VAR and the unfortunate `...` [1]
Then the syntax $"..." was introduced, then the syntax $'...' (bash 2.X).
As the character '$' means "interprets (synonym: translates) what
follows", it
seems to me quite consistent that $"..." means "translates the entire
following
string"
Conversely, the syntax $'...' seems to me much less consistent.
(Reminder: C is
prior to shells, and bash is itself written in C).
However, the "C-string" feature is very useful (and nowadays probably
more used
than the translation feature).
In absolute terms, if one day we would list all the historical design
errors,
dare to break some compatibilities, and manage to establish new shell
standards
(I'm probably dreaming ... but do we ever know ?). Then we could have:
I would have really loved if Bash expanded translations with its
built-in printf using a `-g` flag for gettext and positional arguments
support instead of expanding string literal translations.
It would have allowed something like :
```sh
#!/usr/bine/env bash
# -g Gettext translation of Hello World into variable my_string
printf -v my_string -g 'Hello World!'
# Printout using gettext translated format string
printf -g 'String %1$q has %2$d characters\n' "$my_string" "${#my_string}"
```
Using this German language file:
```po
#: a.sh:4
msgid "Hello World!"
msgstr "Hallo Welt!"
#: a.sh:7
msgid "String %1$q has %2$d characters\n"
msgstr "%2$d Zeichen lang ist die Zeichenkette %1$q\n"
```
In default English, the output would be:
```none
String Hello\ World\! has 12 characters
```
In German, the output would be:
```none
11 Zeichen lang ist die Zeichenkette Hallo\ Welt\!
```
--
Léa Gris
Re: gettext feature request
On 8/13/21 12:14 PM, Jean-Jacques Brucker wrote: I'm probably less familiar with the history of shells and bash than you (and others on this mailing list), but it seems to me that: First were the chains: * '...' who did not expand anything * "..." which expanded the syntaxes $VAR and the unfortunate `...` [1] Then the syntax $"..." was introduced, then the syntax $'...' (bash 2.X). That's when bash introduced it. I picked it up from ksh93 with an existing meaning and semantics, and there was no reason to be incompatible. The $'...' syntax kind of came in the same way, but there was some discussion among shell maintainers at the time (early 2000s) about how to do it. I don't know how many other shells besides bash and ksh93 implement $"...". There are several that implement $'...' (mksh, zsh, NetBSD sh, FreeBSD sh) and several that don't (dash, yash). There is an existing proposal -- dating from 2010 -- to add $'...', based originally on the bash implementation, to the next version of POSIX. There have been various hangups, to say the least. The current issue is how to specify the \U and \u escape sequences. (Bash converts the hex digits to a 32-bit quantity and uses iconv to convert it to a character in the current locale, falling back to UTF-8 and, in a pinch, C escape sequences.) As the character '$' means "interprets (synonym: translates) what follows", it seems to me quite consistent that $"..." means "translates the entire following string" Conversely, the syntax $'...' seems to me much less consistent. (Reminder: C is prior to shells, and bash is itself written in C). C isn't really "prior" to shells. There was a shell in the first edition, and that predated C. But that's neither here nor there. We have what we have. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
