Re: $() does not handle nesting with case - parser precedence?
On Sat, Jun 27, 2015 at 2:48 PM, Nathan Neulinger 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-redhat-linux-gnu' > -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE > -DRECYCLES_PIDS -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -O2 -g > -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches > -m64 -mtune=generic > uname output: Linux skyhawk.home.neulinger.org 3.19.3-200.fc21.x86_64 #1 > SMP Thu Mar 26 21:39:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-redhat-linux-gnu > > Bash Version: 4.3 > Patch Level: 39 > Release Status: release > > Description: > > If $() includes a case statement nested within it, the parser is > not matching ) as closing the case, > but rather the $(. This behavior is different between bash and > other shells. ksh/busybox > both process this without error, but I do not know which is > officially "correct". > > Test Case: > --- > testing=$( > echo test | while read line; do > case $line in > test) echo saw test ;; > *) echo other ;; > esac > done > ) > > echo result: $testing > -- > > Expected output: > > result: saw test > > Actual output: > > parse-bug.sh: line 6: syntax error near unexpected token `;;' > parse-bug.sh: line 6: ` test) echo saw test ;;' > > > Workaround: Use (test) instead of test) in the nested code > > > Repeat-By: > Run script with that syntax. > > > > -- > > Nathan Neulinger nn...@neulinger.org > Neulinger Consulting (573) 612-1412 > > You can use the full syntax of case by surrounding the cases with both opening and closing parentheses: testing=$( echo test | while read line; do case $line in (test) echo saw test ;; (*) echo other ;; esac done ) POSIX shows the opening parentheses as optional, but does not describe their use or when they might be necessary. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04 -- Visit serverfault.com to get your system administration questions answered.
Re: $() does not handle nesting with case - parser precedence?
Yeah. I noted that as workaround in the report... I figured if posix was vague on this matching other shells might be better behavior. On Jun 28, 2015 2:57 PM, "Dennis Williamson" wrote: > > > On Sat, Jun 27, 2015 at 2:48 PM, Nathan Neulinger > 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-redhat-linux-gnu' >> -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' >> -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE >> -DRECYCLES_PIDS -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -O2 -g >> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches >> -m64 -mtune=generic >> uname output: Linux skyhawk.home.neulinger.org 3.19.3-200.fc21.x86_64 #1 >> SMP Thu Mar 26 21:39:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >> Machine Type: x86_64-redhat-linux-gnu >> >> Bash Version: 4.3 >> Patch Level: 39 >> Release Status: release >> >> Description: >> >> If $() includes a case statement nested within it, the parser is >> not matching ) as closing the case, >> but rather the $(. This behavior is different between bash and >> other shells. ksh/busybox >> both process this without error, but I do not know which is >> officially "correct". >> >> Test Case: >> --- >> testing=$( >> echo test | while read line; do >> case $line in >> test) echo saw test ;; >> *) echo other ;; >> esac >> done >> ) >> >> echo result: $testing >> -- >> >> Expected output: >> >> result: saw test >> >> Actual output: >> >> parse-bug.sh: line 6: syntax error near unexpected token `;;' >> parse-bug.sh: line 6: ` test) echo saw test ;;' >> >> >> Workaround: Use (test) instead of test) in the nested code >> >> >> Repeat-By: >> Run script with that syntax. >> >> >> >> -- >> >> Nathan Neulinger nn...@neulinger.org >> Neulinger Consulting (573) 612-1412 >> >> > > You can use the full syntax of case by surrounding the cases with both > opening and closing parentheses: > > testing=$( > echo test | while read line; do > case $line in > (test) echo saw test ;; > (*) echo other ;; > esac > done > ) > > POSIX shows the opening parentheses as optional, but does not describe > their use or when they might be necessary. > > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_04 > > -- > Visit serverfault.com to get your system administration questions > answered. >
Weird background crashing bug
I noticed it when I tried to branch an xterm off into multiple sessions and mistyped its name: `xter m&` So after experimenting with a ton of different scenarios I've come to this conclusion: * both xterm and gnome-terminal crash * a nested bash session also crashes returning me back to the previous shell where the wd is ~ * does *not* crash in TTY, nor in nested session *within* TTY. * only happens when two or more (but not less) directories deep into home (~), for example, "~/Videos/movies/" or "~/Pictures/vacation/2009". *Running a non-existent command in the background while two or more directories deep into home (~) causes bash to crash, but only when in a terminal emulator* Why does this happen? -- Braden Best bradentb...@gmail.com (505) 692 0947
Re: Weird background crashing bug
Re-send: I noticed it when I tried to branch an xterm off into multiple sessions and mistyped its name: `xter m&` So after experimenting with a ton of different scenarios I've come to this conclusion: * both xterm and gnome-terminal crash * a nested bash session also crashes returning me back to the previous shell where the wd is ~ * does *not* crash in TTY, nor in nested session *within* TTY. * only happens when two or more (but not less) directories deep into home (~), for example, "~/Videos/movies/" or "~/Pictures/vacation/2009". *Running a non-existent command in the background while two or more directories deep into home (~) causes bash to crash, but only when in a terminal emulator* Why does this happen? Addendum: *The version number of Bash.* $ bash --version 4.3.11(1)-release (x86_64-pc-linux-gnu) *The hardware and operating system.* Aspire-XC-603G Ubuntu 14.04.1 LTS *The compiler used to compile Bash.* can't find that information. `info bash | grep gcc` gives me nothing *A description of the bug behaviour.* Described Above *A short script or ‘recipe’ which exercises the bug and may be used to reproduce it. *$ mkdir dir1 $ mkdir dir1/dir2 $ cd dir1/dir2 $ nonexistentcommand & Using it as a script won't cause a crash. The crash only happens in interactive mode. On Sun, Jun 28, 2015 at 8:40 PM, Braden Best wrote: > I noticed it when I tried to branch an xterm off into multiple sessions > and mistyped its name: > > `xter m&` > > So after experimenting with a ton of different scenarios I've come to this > conclusion: > > * both xterm and gnome-terminal crash > > * a nested bash session also crashes returning me back to the previous > shell where the wd is ~ > > * does *not* crash in TTY, nor in nested session *within* TTY. > > * only happens when two or more (but not less) directories deep into home > (~), for example, "~/Videos/movies/" or "~/Pictures/vacation/2009". > > *Running a non-existent command in the background while two or more > directories deep into home (~) causes bash to crash, but only when in a > terminal emulator* > > Why does this happen? > > -- > Braden Best > bradentb...@gmail.com > (505) 692 0947 > -- Braden Best bradentb...@gmail.com (505) 692 0947
Re: Weird background crashing bug
On Mon, Jun 29, 2015 at 5:54 AM, Braden Best wrote: > Re-send: > > > I noticed it when I tried to branch an xterm off into multiple sessions > and mistyped its name: > > `xter m&` > > So after experimenting with a ton of different scenarios I've come to this > conclusion: > > * both xterm and gnome-terminal crash > > * a nested bash session also crashes returning me back to the previous > shell where the wd is ~ > > * does *not* crash in TTY, nor in nested session *within* TTY. > > * only happens when two or more (but not less) directories deep into home > (~), for example, "~/Videos/movies/" or "~/Pictures/vacation/2009". > > *Running a non-existent command in the background while two or more > directories deep into home (~) causes bash to crash, but only when in a > terminal emulator* > > Why does this happen? > > Addendum: > > *The version number of Bash.* > $ bash --version > 4.3.11(1)-release (x86_64-pc-linux-gnu) > > *The hardware and operating system.* > Aspire-XC-603G > Ubuntu 14.04.1 LTS > > *The compiler used to compile Bash.* > can't find that information. `info bash | grep gcc` gives me nothing > > *A description of the bug behaviour.* > Described Above > > > *A short script or ‘recipe’ which exercises the bug and may be used to > reproduce it. *$ mkdir dir1 > $ mkdir dir1/dir2 > $ cd dir1/dir2 > $ nonexistentcommand & > > Using it as a script won't cause a crash. The crash only happens in > interactive mode. > > > On Sun, Jun 28, 2015 at 8:40 PM, Braden Best > wrote: > >> I noticed it when I tried to branch an xterm off into multiple sessions >> and mistyped its name: >> >> `xter m&` >> >> So after experimenting with a ton of different scenarios I've come to >> this conclusion: >> >> * both xterm and gnome-terminal crash >> >> * a nested bash session also crashes returning me back to the previous >> shell where the wd is ~ >> >> * does *not* crash in TTY, nor in nested session *within* TTY. >> >> * only happens when two or more (but not less) directories deep into home >> (~), for example, "~/Videos/movies/" or "~/Pictures/vacation/2009". >> >> *Running a non-existent command in the background while two or more >> directories deep into home (~) causes bash to crash, but only when in a >> terminal emulator* >> >> Why does this happen? >> >> -- >> Braden Best >> bradentb...@gmail.com >> (505) 692 0947 >> > > > > -- > Braden Best > bradentb...@gmail.com > (505) 692 0947 > I don't seem to be able to reproduce with 4.3.30(1)-release, just in case, can you try it after running: PS1='$ ' PROMPT_COMMAND=''; unset -f command_not_found_handle
