Re: Intriguing error with arithmetic evaluation
On 8/15/16 6:15 AM, L. A. Walsh wrote: > > > Chet Ramey wrote: >> The relevant change was probably the change in the set of commands to which >> `set -e' applies. The (( command (among others) was added to that list >> in bash-4.1. The change was the result of Posix changing the semantics >> of the errexit option and expanding its scope from simple commands to >> all commands. >> >> The (( command returns 1 if the expression evaluates to 0. When `level' is >> 0, level++ returns a 0 value, and (( returns a status of 1. >> > That doesn't explain why those not using posix mode should suffer the > arbitrary added incompatibility with previous code. > > POSIX was meant to describe existing code -- not cause incompatibilities with > old or current code. > > POSIX disbanded and the name has changed hands to be run by people > unassociated with the original POSIX charter -- who created a different > charter. Very little in this message is accurate. Your conspiracy-theory game is still strong, though. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Curious case statement error
On 8/13/16 3:59 PM, Eduardo Bustamante wrote: > Character ranges are locale-dependant. Check the values of LC_ALL and > LC_COLLATE. Under some locales, the [A-Z] range is actually AaBb..Z. That's > why it's better to use the character classes, i.e. [[:alpha:]], > [[:lower:]], [[:upper:]], etc. This is an old question. So old, in fact, that question E9 in the Bash FAQ covers it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Potential buffer under-run in shell_execve()
On 8/13/16 10:01 PM, John E. Malmberg wrote: > Hello, > > In Bash 4.3.42: > > In execute_cmd/shell_execve(), if HAVE_BASH_BANG_EXEC is defined, the macro > READ_SAMPLE_BUF has the potential to set sample_len to -1. > > #if defined (HAVE_HASH_BANG_EXEC) > READ_SAMPLE_BUF (command, sample, sample_len); > sample[sample_len - 1] = '\0'; > > This would cause sample[-2] to be set to 0. Most likely it would set part > of fd to 0, but all that depends on the compiler. Thanks for the report. Since this code path is taken on failure, and the child process exits immediately afterward, it's likely not dangerous. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Intriguing error with arithmetic evaluation
Chet Ramey wrote: On 8/15/16 6:15 AM, L. A. Walsh wrote: Chet Ramey wrote: The relevant change was probably the change in the set of commands to which `set -e' applies. The change was the result of Posix changing the semantics of the errexit option and expanding its scope from simple commands to all commands. That doesn't explain why those not using posix mode should suffer the arbitrary added incompatibility with previous code. POSIX was meant to describe existing code -- not cause incompatibilities with old or current code. POSIX disbanded and the name has changed hands to be run by people unassociated with the original POSIX charter -- who created a different charter. Very little in this message is accurate. Your conspiracy-theory game is still strong, though. If that's the case, then "what" are you claiming is the conspiracy which I am "proposing"? I see no conspiracy. Only an evolution of what was, to what is, with the main difference being that the original charter said POSIX was to be _descriptive_, whereas the new POSIX is being prescriptive -- no longer describing what exists so people can be compatible, which had been the original intent. Those fact are indisputable to anyone looking at the original charter and current behavior. Perhaps you can explain why bash's "normal mode" had to change? Anyone who has had a problem with how "-e" works has done so due to that change. If bash had remained compatible in non-POSIX mode, the issue for bash would not be present.
Re: Intriguing error with arithmetic evaluation
On Tue, Aug 16, 2016 at 09:16:50AM -0700, L. A. Walsh wrote: > Perhaps you can explain why bash's "normal mode" had to change? I don't have a "why", but I do note this on http://mywiki.wooledge.org/BashFAQ/105/Answers See the answer for "Exercise 2". I repeat, because it needs to be repeated every day for all of eternity, you should not use set -e. Just stop.
Re: Intriguing error with arithmetic evaluation
On 8/16/16 12:16 PM, L. A. Walsh wrote: The relevant change was probably the change in the set of commands to which `set -e' applies. The change was the result of Posix changing the semantics of the errexit option and expanding its scope from simple commands to all commands. >>> That doesn't explain why those not using posix mode should suffer the >>> arbitrary added incompatibility with previous code. >>> >>> POSIX was meant to describe existing code -- not cause incompatibilities >>> with old or current code. >>> >>> POSIX disbanded and the name has changed hands to be run by people >>> unassociated with the original POSIX charter -- who created a different >>> charter. >>> >> >> Very little in this message is accurate. >> Your conspiracy-theory game is still strong, though. >> > > If that's the case, then "what" are you claiming is the conspiracy which > I am "proposing"? The idea that Posix was once pure and forthright, and has subsequently become taken over by others and corrupted. This is the same group with the same charter. Some people have moved in and out, as is to be expected, over time, but the group's purpose has remained consistent. There are places where Posix, when faced with incompatible implementations, has invented functionality (e.g., `command'), but that happened from the beginning. `command', for instance, is in the first published version of the shell and tools standard, from 1992. > > I see no conspiracy. Only an evolution of what was, to what is, > with the main difference being that the original charter said POSIX > was to be _descriptive_, whereas the new POSIX is being prescriptive -- > no longer describing what exists so people can be compatible, which had > been the original intent. Those fact are indisputable to anyone looking > at the original charter and current behavior. You keep saying this, as if you expect it to become true if you repeat it enough times. > > Perhaps you can explain why bash's "normal mode" had to change? Bash is at its base a Posix shell implementation. There was no reason to be incompatible with Posix and historical (and other contemporary) shell implementations. In addition, it made `make' and other code that expected historical behavior from `set -e' fail in unexpected ways. Don't make the mistake -- again -- of thinking that because you didn't have a problem with it, nobody did. I got plenty of strongly worded messages about the old bash behavior, e.g.: "as a bash user I fault you for implementing some insane behavior instead of questioning the standard." > Anyone who has had a problem with how "-e" works has done so due > to that change. If bash had remained compatible in non-POSIX mode, > the issue for bash would not be present. Compatible with what? It wasn't compatible with historical or other contemporary shell implementations. The Posix WG acknowledged a defect in the standard, an incompatibility with historical and current shell implementations, and corrected it; and bash changed to match the standard. When the standard changed from saying "simple command" to "command", that includes all commands. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
