$(<...) fails with nested quoting.

Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACK

Re: $(<...) fails with nested quoting.

On 17/08/2020 04:03, Steven McBride wrote: Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR

Re: heredoc seems to parse contents even with the quoted delimiter in shell prompt

On 8/16/20 1:34 AM, Hyunho Cho wrote: > > if i use the same script in shell prompt then strange error messages appear > > > bash$ cat << "EOF" > this is a test comment > $(info $(foo ${bar))) > EOF > bash: command substitution: line 798: unexpected EOF while looking for > matching `}' > bash: c

Re: multi-line command history does not work when new terminal opened

On 8/16/20 2:39 AM, Hyunho Cho wrote: > Bash Version: 5.0 > Patch Level: 17 > Release Status: release > > > > > I have enabled the shell options for multi-line command history like this > > shopt -s lithist > shopt -s cmdhist

Re: $(<...) fails with nested quoting.

On Mon, Aug 17, 2020 at 3:53 PM Steven McBride wrote: > 'echo "$(<\"filename\")"' fails with No such file or directory > Quotes inside $() are independent from the ones outside. If you escape them, you get literal quotes as part of the filename. $ echo hello > '"filename"' $ echo "$(<\

Re: echo builtin doesn't handle end-of-options flag

On 8/16/20 12:20 PM, Eli Schwartz wrote: > >> Bash Version: 5.0 >> Patch Level: 18 >> Release Status: release >> > bash does accept -n, -e, -E in violation of POSIX, unless shopt -s shopt > -s xpg_echo is set, That's not a POSIX violation. -- ``The lyf so short, the craft so long to lerne.'' -

Re: echo builtin doesn't handle end-of-options flag

On 8/16/20 12:26 PM, Eli Schwartz wrote: > Err... > > "Implementations shall not support any options." Yes, that's why the -n/-E/-e aren't described as options -- that would turn on the special `--' processing -- but as first operands that enable special treatment. -- ``The lyf so short, the c

Re: echo builtin doesn't handle end-of-options flag

On 8/16/20 12:21 PM, Eric Blake wrote: > POSIX says this one is implementation-defined; so whether -n is treated as > an option or as a string to echo has to be documented by the implementation > (bash documents treating it as an option). It's not technically an option; it's a first operand that