Re: Bug: 'case' in command substitution not handled correctly

[Chet Ramey]

Bernd Eggink wrote:
> GNU bash, Version 4.0.17(1)-release (i686-pc-linux-gnu)
> 
> The shell doesn't recognize the closing parenthesis of a command
> substitution if a 'case' command is included and 'esac' is preceded by
> newline. Example:
> 
> x=$(case $a in
>> (1) echo one
>> esac
>> )
>>
> 

Try the attached patch.  A newline really is a shell meta-character.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.0-patched/parse.y 2009-03-08 21:24:47.0 -0400
--- parse.y 2009-04-15 22:27:56.0 -0400
***
*** 3355,3359 
  
/* Meta-characters that can introduce a reserved word.  Not perfect 
yet. */
!   if MBTEST((tflags & LEX_RESWDOK) == 0 && (tflags & LEX_CKCASE) && 
(tflags & LEX_INCOMMENT) == 0 && shellmeta(ch))
{
  /* Add this character. */
--- 3375,3379 
  
/* Meta-characters that can introduce a reserved word.  Not perfect 
yet. */
!   if MBTEST((tflags & LEX_RESWDOK) == 0 && (tflags & LEX_CKCASE) && 
(tflags & LEX_INCOMMENT) == 0 && (shellmeta(ch) || ch == '\n'))
{
  /* Add this character. */

Re: [a-f]* style globbing broken

[Chet Ramey]

seren...@exscape.org wrote:

> Bash Version: 4.0
> Patch Level: 17
> Release Status: release
> 
> Description:
>   When using [a-*] globbing options, the very last UPPERCASE letter is 
> not matched, however all other ones are.
> 
> Repeat-By:
>   mkdir test; cd test; for LETTER in {a..f}; do touch $LETTER; done
>   ls -1 [a-f]* | wc -l # returns 6, as expected
>   for LETTER in {A..F}; do touch $LETTER; done
>   ls -1 [a-f]* | wc -l # returns 11! If we return the wc pipe, we can see 
> that the output is "a A b B ... e E f" without the capital F.

Please read the Bash FAQ, question E9.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/

[a-f]* style globbing broken

[serenity]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-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  
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
 -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' 
-DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' 
-DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -O2 -pipe -mtune=nocona
uname output: Linux exscape.org 2.6.28-gentoo #2 SMP Sun Apr 5 18:28:35 CEST 
2009 x86_64 Intel(R) Pentium(R) Dual CPU E2200 @ 2.20GHz GenuineIntel GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.0
Patch Level: 17
Release Status: release

Description:
When using [a-*] globbing options, the very last UPPERCASE letter is 
not matched, however all other ones are.

Repeat-By:
mkdir test; cd test; for LETTER in {a..f}; do touch $LETTER; done
ls -1 [a-f]* | wc -l # returns 6, as expected
for LETTER in {A..F}; do touch $LETTER; done
ls -1 [a-f]* | wc -l # returns 11! If we return the wc pipe, we can see 
that the output is "a A b B ... e E f" without the capital F.

Bug: 'case' in command substitution not handled correctly

[Bernd Eggink]

GNU bash, Version 4.0.17(1)-release (i686-pc-linux-gnu)

The shell doesn't recognize the closing parenthesis of a command 
substitution if a 'case' command is included and 'esac' is preceded by 
newline. Example:


x=$(case $a in
> (1) echo one
> esac
> )
>

You can enter as many ')' as you like, the shell still wants another 
one. This variant works, however:


x=$(case $a in (1) echo one;esac
)

Regards,
Bernd

--
Bernd Eggink
http://sudrala.de

Re: Silent errors in process substitution

[Greg Wooledge]

On Wed, Apr 15, 2009 at 02:46:45PM +0200, Anakim Border wrote:
> is there any way to notice commands exiting with a non-zero status
> inside a process substitution?
> 
> For example:
> 
> $ cat <(exit 1)
> 
> ignores the exit status of "exit":

The whole point of the process substitution syntax is that it gives you
a no-frills, anonymous named pipe without forcing you to bother about
mundane details such as where in the file system to place it.

If you actually care about the process on the other side of the named
pipe, and how it exits, then you should forego the process substitution
syntax altogether, make your own named pipe, launch your own child
process to interact with it, and use the 'wait' builtin to collect its
exit status at the appropriate time.

Silent errors in process substitution

[Anakim Border]

Hi,

is there any way to notice commands exiting with a non-zero status
inside a process substitution?

For example:

$ cat <(exit 1)

ignores the exit status of "exit":

$ echo $?
0

I'm searching for something like "set -e" (doesn't work in this case)
to make the whole command fail.


I'm using bash 3.2.17.

Thanks,
  AB