Re: shopt -u compat* (re)sets BASH_COMPAT to 51
* On 2/13/22 10:50 PM, Chet Ramey wrote: > H. So what you're proposing is that `shopt -u compat43' if compat43 is > not set should not reset the compatibility level to the current version. > OK. > > I think we could do this by interrogating $BASH_COMPAT after unsetting the > appropriate compat_NN option. > > Or maybe leaving shell_compatibility_level alone if it's > 44 (the last > compat_NN option) and <= DEFAULT_COMPATIBILITY_LEVEL (the current version) > instead of unconditionally setting it to DEFAULT_COMPATIBILITY_LEVEL. But > then you'd be required to unset BASH_COMPAT to get back to the current > compatibility level, which is supported now but not required. The easiest way to do this would be to check if the old value matches the new one and in case both were unset, just do nothing. However, looking at the source, I understand that this is not easily possible, since the old value is overwritten in toggle_shopts() immediately and only the new mode passed to the registered set_func fptr. I'd refactor this to also give it the old value and just turn set_compatibility_value() into a no-op if (!old_val) && (!new_val). Mihai OpenPGP_signature Description: OpenPGP digital signature
Re: shopt -u compat* (re)sets BASH_COMPAT to 51
On 2/14/22 4:30 AM, Mihai Moldovan wrote: Or maybe leaving shell_compatibility_level alone if it's > 44 (the last compat_NN option) and <= DEFAULT_COMPATIBILITY_LEVEL (the current version) instead of unconditionally setting it to DEFAULT_COMPATIBILITY_LEVEL. But then you'd be required to unset BASH_COMPAT to get back to the current compatibility level, which is supported now but not required. The easiest way to do this would be to check if the old value matches the new one and in case both were unset, just do nothing. It's easier than that. Since the compatNN options and the compatibility level are separate, it's easier to just make it a no-op if the current compatibility level is outside the range of the compatNN options. That's basically what I said above. -- ``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: Sus behaviour when cmd string ends with single backslash
vzvz...@gmail.com writes: The mentioned bug is indeed fixed by this change. However, in case of another edge case following new behaviour is observable: $ bash -c 'echo \' \ $ # backslash appears on output It's an interesting case, since the command that Bash is executing is e-c-h-o-space-backslash with no character at all after the backslash. The manual page says A non-quoted backslash (\) is the escape character. It preserves the literal value of the next character that follows, with the exception of . If a \ pair appears, and the backslash is not it- self quoted, the \ is treated as a line continuation (that is, it is removed from the input stream and effectively ignored). Which doesn't seem to consider this case at all. The two a-priori plausable behaviors are for the backslash to be taken literally (which is what happens) or for it to vanish as some sort of incomplete escape construct. So you could plausibly say that the behavior of a backslash before "end of file" isn't defined. Dale As you cited, a non-quoted backslash preserves the literal value of the next character. Therefore, backslash cannot be literally taken. The next character is "nothing" (or EOF), so if we take the documentation literally :), the backslash should preserve this "nothing" (or EOF). This would comply with the definition very well. Zoltan
Re: Sus behaviour when cmd string ends with single backslash
On 2/13/22 3:15 PM, vzvz...@gmail.com wrote: Bash Version: 5.0 Patch Level: 17 Release Status: release Description: Background -- Commit a0c0a00fc419b7bc08202a79134fcd5bc0427071 (bash-4.4) introduced a change in parse.y with following documentation in the change logs: parse.y - shell_getc: if bash is reading input from a string that ends with an unquoted backslash, add another backslash instead of a newline, since the backslash and newline will disappear in normal processing. Fixes bug with `bash -c 'eval \\; echo y' ' skipping the eval command and setting incorrect exit status, and `bash -ic 'eval \\; echo y' ' seeing EOF on empty line and exiting before the echo. Keep track of backslash state with last_was_backslash; set in char reading loop. Fixes bug reported by Eduardo A. Bustamante López The new code in parse.y /* Don't add a newline to a string that ends with a backslash if we're going to be removing quoted newlines, since that will eat the backslash. Add another backslash instead (will be removed by word expansion). */ if (bash_input.type == st_string && expanding_alias() == 0 && last_was_backslash && c == EOF && remove_quoted_newline) shell_input_line[shell_input_line_len] = '\\'; else shell_input_line[shell_input_line_len] = '\n'; shell_input_line[shell_input_line_len + 1] = '\0'; This specific change is also there in commit 0385211bb5cb01e0259c64ec2c5cc6337d4e215c on a development branch. Observed vs. expected behaviour --- The mentioned bug is indeed fixed by this change. However, in case of another edge case following new behaviour is observable: $ bash -c 'echo \' \ $ # backslash appears on output I think the behavior of a word consisting only of a backslash is officially unspecified. It's not a quote character -- there's nothing to quote -- so it's not removed by quote removal. In general, I think it's better to err on the side of preserving output here. Existing shell behavior varies, so you can't really count on anything. -- ``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: Sus behaviour when cmd string ends with single backslash
i like the currently showed behavior of '\' parsed as arg no need to error .. if u meant that, .. On Mon, Feb 14, 2022 at 11:17 PM Chet Ramey wrote: > On 2/13/22 3:15 PM, vzvz...@gmail.com wrote: > > > Bash Version: 5.0 > > Patch Level: 17 > > Release Status: release > > > > Description: > > > > Background > > -- > > > > Commit a0c0a00fc419b7bc08202a79134fcd5bc0427071 (bash-4.4) introduced a > change in parse.y with following documentation in the change logs: > > > > parse.y > > - shell_getc: if bash is reading input from a string that ends > with an > > unquoted backslash, add another backslash instead of a newline, > since > > the backslash and newline will disappear in normal processing. > Fixes > > bug with `bash -c 'eval \\; echo y' ' skipping the eval command > and > > setting incorrect exit status, and `bash -ic 'eval \\; echo y' ' > > seeing EOF on empty line and exiting before the echo. Keep > track of > > backslash state with last_was_backslash; set in char reading > loop. > > Fixes bug reported by Eduardo A. Bustamante López < > dual...@gmail.com> > > > > The new code in parse.y > > > > /* Don't add a newline to a string that ends with a backslash if > we're > >going to be removing quoted newlines, since that will eat the > >backslash. Add another backslash instead (will be removed by > >word expansion). */ > > if (bash_input.type == st_string && expanding_alias() == 0 && > last_was_backslash && c == EOF && remove_quoted_newline) > > shell_input_line[shell_input_line_len] = '\\'; > > else > > shell_input_line[shell_input_line_len] = '\n'; > > shell_input_line[shell_input_line_len + 1] = '\0'; > > > > > > This specific change is also there in commit > 0385211bb5cb01e0259c64ec2c5cc6337d4e215c on a development branch. > > > > Observed vs. expected behaviour > > --- > > > > The mentioned bug is indeed fixed by this change. However, in case of > another edge case following new behaviour is observable: > > > > $ bash -c 'echo \' > > \ > > $ # backslash appears on output > > I think the behavior of a word consisting only of a backslash is officially > unspecified. > > It's not a quote character -- there's nothing to quote -- so it's not > removed by quote removal. > > In general, I think it's better to err on the side of preserving output > here. > > Existing shell behavior varies, so you can't really count on anything. > > -- > ``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/ > >
