Silent errors in process substitution
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
Re: Silent errors in process substitution
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.
Bug: 'case' in command substitution not handled correctly
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
[a-f]* style globbing broken
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.
Re: Bug: 'case' in command substitution not handled correctly
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. */
