$(<...) 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' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/build/bash-N2nMjo/bash-4.4.18=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux tau5vbub1 4.15.0-112-generic #113-Ubuntu SMP Thu Jul
9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4
Patch Level: 20
Release Status: release
Description:
'echo "$(<\"filename\")"' fails with No such file or directory
error.
'echo "$(cat \"filename\")"' also fails no such file or directory
error.
'echo "$(cat fn
w1 w2
~ 20>echo $(echo $(<"fn")
w1 w2
~ 22>echo "$(echo "$(<\"fn\")"
-bash: "fn": No such file or directory
Running "strace" shows that quote marks are not removed in
the failing case:
echo "$(> [pid 3708] openat(AT_FDCWD, "fn", O_RDONLY) = 3
[pid 3708] read(3, "some text\n", 128) = 10
[pid 3708] write(1, "some text\n", 10
[pid 3707] <... read resumed> "some text\n", 128) = 10
[pid 3708] <... write resumed> ) = 10
echo "$(<\"fn\")":
[pid 779] dup2(4, 1) = 1
[pid 779] close(4) = 0
[pid 779] close(3) = 0
[pid 779] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
>> [pid 779] openat(AT_FDCWD, "\"fn\"", O_RDONLY) = -1 ENOENT
(No such file or di
[pid 779] openat(AT_FDCWD, "/usr/share/locale/locale.alias",
O_RDONLY|O_CLOEXE
[pid 779] fstat(3, {st_mode=S_IFREG|0644, st_size=2995, ...}) = 0
Repeat-By:
echo w1 w2 > filename
echo "$(<\"filename\")"
Fix:
[Description of how to fix the problem. If you don't know a
fix for the problem, don't include this section.]
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='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-N2nMjo/bash-4.4.18=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux tau5vbub1 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 20 Release Status: release Description: 'echo "$(<\"filename\")"' fails with No such file or directory error. 'echo "$(cat \"filename\")"' also fails no such file or directory error. 'echo "$( Only in the last case. There is no bug here. The quoting is because in my original case 'filename' was a variable that could contained a filename with spaces in it. "$(<"$filename")" For an explanation, see https://mywiki.wooledge.org/CommandSubstitution. -- Kerin Millar
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: command substitution: line 799: syntax error: unexpected end of file
Thanks for the report. The shell is trying to find the end of the command
to figure out how to store it in the history. When you're parsing a here-
document, you need to leave the newlines in the history instead of maybe
adding a semicolon. That code just needs to be more aware of when it can
not parse due to being in the body of a here-document.
Chet
--
``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: 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 > > and it works well in current terminal > > bash$ history > 8651 echo history test 1 > 8652 echo history test 2 > 8653 echo history test 3 > 8654 cat << EOF > 111 > 222 # multi-line command history works well > 333 > EOF > > 8655 history > > --- > > if i opened new terminal then the multi-line commands all changed to > single lines like this > > bash$ history > 7819 echo history test 1 > 7820 echo history test 2 > 7821 echo history test 3 > 7822 cat << EOF > 7823 111 # the multi-line > commands changed to single lines > 7824 222 > 7825 333 > 7826 EOF > 7827 history When you enable `lithist', each line of a multi-line command is saved to the history list with a trailing newline, and written to the history file as a separate line. With the traditional readline history file format, that makes each line a separate history entry unless the application uses a delimiter to logically separate commands. With bash, that delimiter is the timestamp that is controlled by HISTTIMEFORMAT. Here are a couple of messages that explain the issue in detail: https://lists.gnu.org/archive/html/bug-bash/2016-09/msg00112.html https://lists.gnu.org/archive/html/bug-bash/2017-06/msg00119.html -- ``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: $(<...) 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 "$(<\"filename\")" hello $ echo another > 'name with spaces' $ echo "$(<"name with spaces")" another I've been led to understand this isn't so with backticks, though.
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.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ signature.asc Description: OpenPGP digital signature
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 craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ signature.asc Description: OpenPGP digital signature
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 is treated specially. -- ``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/
