Re: RFE: new syntax for command substitution to keep trailing newlines?
ah thank you On Sat, Jan 30, 2021, 13:51 Dennis Williamson wrote: > > > On Fri, Jan 29, 2021, 12:22 PM Alex fxmbsw7 Ratchev > wrote: > >> im sorry big time.. can you point me out how >> i just commented the #if and #endif s , thought thatd enable the code .. >> in >> parse and tab >> >> On Fri, Jan 29, 2021, 14:57 Chet Ramey wrote: >> >> > On 1/29/21 7:50 AM, Alex fxmbsw7 Ratchev wrote: >> > > is commenting the #(if|endif) lines right way ? >> > > >> > > cause.. it buggs still >> > >> > You have to uncomment the fix; that one's not live. >> > >> > -- >> > ``The lyf so short, the craft so long to lerne.'' - Chaucer >> > ``Ars longa, vita brevis'' - Hippocrates >> > Chet Ramey, UTech, CWRUc...@case.edu >> http://tiswww.cwru.edu/~chet/ >> > >> > > Those aren't comments. They are preprocessor directives. Leave the # where > they are. Just change the 0 to a 1. > > #if 0 > > Should be changed to > > #if 1 > > To enable that bit of code. > >>
Re: RFE: new syntax for command substitution to keep trailing newlines?
On 1/29/21 1:21 PM, Alex fxmbsw7 Ratchev wrote: im sorry big time.. can you point me out how i just commented the #if and #endif s , thought thatd enable the code .. in parse and tab Sorry, "commenting" code using #if 0 is a pretty common idiom. There are two places in parse_string_to_word_list() that have #if 0...#endif blocks. The first one is tagged with your name. Change the #if 0 to #if 1 in both blocks and see if that fixes the problem. It fixes the reproducer in https://lists.gnu.org/archive/html/bug-bash/2020-11/msg00077.html and https://lists.gnu.org/archive/html/bug-bash/2020-11/msg00079.html which is a distillation of your original example to something easily reproducible. -- ``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/
Are these bash.v.posix diffs still useful? They _seem_ dated...
Since this "https://tiswww.case.edu/php/chet/bash/POSIX"; doesn't seem to be version specific, I'm assuming these are in the latest bash version. I don't understand the benefit of the differences involving hashed-commands and recovery behavior. It seemed like these behaviors may have served a purpose at one time, but now seem more likely to create an unnecessary failure case. First behavior: How is it beneficial for bash to store a non-executable in the command-hash? And second, related behavior: Not searching for an alternative in the PATH if the old hashed value stops working. Is there a reason why the non-posix behavior should remain or might it be, perhaps, more desirable for the bash behavior to match the posix behavior?
here strings fold newlines on MacOS
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin18.7.0
Compiler: clang
Compilation CFLAGS: -DSSH_SOURCE_BASHRC
uname output: Darwin flounder.home.mati.ca 18.7.0 Darwin Kernel Version 18.7.0:
Tue Nov 10 00:07:31 PST 2020; root:xnu-4903.278.51~1/RELEASE_X86_64 x86_64
Machine Type: x86_64-apple-darwin18.7.0
Bash Version: 5.1
Patch Level: 0
Release Status: release
Description:
Here strings ('<<<') fold newlines into spaces on MacOS, but not on Linux,
leading to incompatibilites in bash code expected to work the same on both
platforms.
Repeat-By:
On Linux:
$ od -bc <<< $(echo -e "foo\nbar")
000 146 157 157 012 142 141 162 012
f o o \n b a r \n
010
On MacOS:
$ od -bc <<< $(echo -e "foo\nbar")
000 146 157 157 040 142 141 162 012
f o o b a r \n
010
Re: here strings fold newlines on MacOS
On 30/01/2021 22:44, Rich Lafferty wrote:
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin18.7.0
Compiler: clang
Compilation CFLAGS: -DSSH_SOURCE_BASHRC
uname output: Darwin flounder.home.mati.ca 18.7.0 Darwin Kernel Version 18.7.0:
Tue Nov 10 00:07:31 PST 2020; root:xnu-4903.278.51~1/RELEASE_X86_64 x86_64
Machine Type: x86_64-apple-darwin18.7.0
Bash Version: 5.1
Patch Level: 0
Release Status: release
Description:
Here strings ('<<<') fold newlines into spaces on MacOS, but not on Linux,
leading to incompatibilites in bash code expected to work the same on both
platforms.
Repeat-By:
On Linux:
$ od -bc <<< $(echo -e "foo\nbar")
000 146 157 157 012 142 141 162 012
f o o \n b a r \n
010
On MacOS:
$ od -bc <<< $(echo -e "foo\nbar")
000 146 157 157 040 142 141 162 012
f o o b a r \n
010
Are you certain that you're not testing /bin/bash (version 3.2.57) in
the case of macOS? I ask because the bug you describe is said to have
been addressed by the release of 4.4-beta [1].
z. Bash no longer splits the expansion of here-strings, as the
documentation has always said.
You can work around it by double quoting the command substitution.
[1] https://tiswww.case.edu/php/chet/bash/CHANGES
--
Kerin Millar
Re: here strings fold newlines on MacOS
> On Jan 30, 2021, at 9:28 PM, "" > wrote: > > Are you certain that you're not testing /bin/bash (version 3.2.57) in the > case of macOS? I ask because the bug you describe is said to have been > addressed by the release of 4.4-beta [1]. > > z. Bash no longer splits the expansion of here-strings, as the >documentation has always said. I can reproduce the OP's result with the system bash but not with 5.1 or 5.1 patch 4. % /bin/bash --version | head -n 1 GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18) % /bin/bash -c 'od -bc <<< $(echo -e "foo\nbar")' 000 146 157 157 040 142 141 162 012 f o o b a r \n 010 % work/destroot/opt/local/bin/bash --version | head -n 1 GNU bash, version 5.1.0(1)-release (x86_64-apple-darwin18.7.0) % work/destroot/opt/local/bin/bash -c 'od -bc <<< $(echo -e "foo\nbar")' 000 146 157 157 012 142 141 162 012 f o o \n b a r \n 010 % bash --version | head -n 1 GNU bash, version 5.1.4(1)-release (x86_64-apple-darwin18.7.0) % bash -c 'od -bc <<< $(echo -e "foo\nbar")' 000 146 157 157 012 142 141 162 012 f o o \n b a r \n 010 -- vq
