local failure
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 laurent-HP-Notebook 4.15.0-65-generic #74-Ubuntu SMP
Tue Sep 17 17:06:04 UTC 2019 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:
[Detailed description of the problem, suggestion, or complaint.]
Repeat-By:
function somethingThatFails {
return 1
}
function aFunction {
local aVar="$(somethingThatFails)" || { echo "is expected to go there";
return 1; }
}
function anotherFunction {
local aVar
aVar="$(somethingThatFails)" || { echo "does go there"; return 1; }
}
aFunction
anotherFunction
Re: local failure
On Thu, May 28, 2020 at 08:02:18AM +0100, Laurent Picquet wrote:
> function aFunction {
> local aVar="$(somethingThatFails)" || { echo "is expected to go there";
> return 1; }
> }
"local" is a command with its own separate exit status. It masks
the exit status of the command substitution.
Run the two commands separately.
local aVar
aVar=$(foo) || diestuff
https://mywiki.wooledge.org/BashPitfalls#pf27
Could we have GLOBIGNORE ignore . and .. in subdirectories, too?
Let's say I want to glob just the files with names starting with dots, but not the ubiquitous dot and dot-dot entries, which are seldom a useful result of a glob. That can be done with something like ..?* .[!.]* or .!(|.) with extglob. Both are still a bit annoying to type, and it would be nice to just have .* do this directly. GLOBIGNORE seems like it could help, but it appears the automatic hiding of . and .. only works with globs without a path element: .* doesn't generate them, but ./.* does. I could add GLOBIGNORE=.:..:*/.:*/.. to catch them also in subdirectories, but then of course that doesn't work for sub-sub-directories, etc. Could it be possible to extend GLOBIGNORE or some other option to have globs like foo/.* not generate . and .. as the final part of the path regardless of the level they are in? When given explicitly, without a glob in the final part of the path, they should probably still be allowed, even if the word was otherwise a glob. (e.g. if something like foo/*/. happened to be useful in some case.) -- Ilkka Virta / itvi...@iki.fi
Seg fault on "echo ~nosuchuser"
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -Wno-parentheses -Wno-format-security uname output: Linux bomb20 5.4.0-31-generic #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 16 Release Status: release Description: bash crashes with a segmentation fault on the command: echo ~nosuchuser (This assumes there is no user named "nosuchuser". If there is, pick a different name). It's likely this isn't a bug in bash itself, but I haven't been able to figure out what's going on. I see this problem on copies of bash 5.0.16 and 5.0.17 built from sourced on Ubuntu 20.04 LTS. It does *not* occur with the /bin/bash GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu) provided by the distribution. I haven't verified how far back this goes. I built another copy of bash 5.0.16 from source with "CFLAGS=-g". When I reproduce the seg fault under gdb, I got the following traceback: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x7777eddb in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 (gdb) where #0 0x7777eddb in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 #1 0x777721c8 in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 #2 0x77773009 in ?? () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 #3 0x777883e7 in _nss_systemd_getpwnam_r () from /lib/x86_64-linux-gnu/libnss_systemd.so.2 #4 0x77e53f03 in __getpwnam_r (name=name@entry=0x55722368 "nosuchuser", resbuf=resbuf@entry=0x77f5e140 , buffer=0x55777808 "systemd-coredump", buflen=buflen@entry=1024, result=result@entry=0x7fffddb0) at ../nss/getXXbyYY_r.c:315 #5 0x77e537ec in getpwnam (name=0x55722368 "nosuchuser") at ../nss/getXXbyYY.c:134 #6 0x55663dc9 in tilde_expand_word (filename=0x5571dba8 "~nosuchuser") at ./tilde.c:386 #7 0x55663a73 in tilde_expand (string=0x5571d493 "") at ./tilde.c:234 #8 0x55598456 in bash_tilde_expand (s=0x5571d488 "~nosuchuser", assign_p=0) at general.c:1196 #9 0x555d773c in expand_word_internal (word=0x5571ffe8, quoted=0, isexp=0, contains_dollar_at=0x7fffe018, expanded_something=0x7fffe014) at subst.c:9963 #10 0x555daccd in shell_expand_word_list (tlist=0x5571d4e8, eflags=31) at subst.c:11339 #11 0x555db047 in expand_word_list_internal (list=0x55722448, eflags=31) at subst.c:11463 #12 0x555da09f in expand_words (list=0x55722448) at subst.c:10983 #13 0x555a5692 in execute_simple_command (simple_command=0x557225c8, pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x5571fd88) at execute_cmd.c:4323 #14 0x5559ee36 in execute_command_internal (command=0x55721288, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x5571fd88) at execute_cmd.c:842 #15 0x5559e3bf in execute_command (command=0x55721288) at execute_cmd.c:394 #16 0x55586e21 in reader_loop () at eval.c:175 #17 0x555846cf in main (argc=1, argv=0x7fffe498, env=0x7fffe4a8) at shell.c:805 If I understand this correctly, it died in getpwnam(). The call appears to be valid; it should simply return a null pointer. Other tests indicate that getpwnam() works correctly. (Dereferencing the null pointer could of course cause a seg fault, but the application doesn't get a chance to do that.) Repeat-By: Given that there is no user account called "nosuchuser", either: echo ~nosuchuser or bash -c 'echo ~nosuchuser'
Re: local failure
It's a subtle point. See this paragraph in the bash manual page: If there is a command name left after expansion, execution proceeds as described below. Otherwise, the command exits. If one of the expansions contained a command substitution, the exit status of the command is the exit status of the last command substitution performed. If there were no command substitutions, the command exits with a status of zero. In one of your examples, a "local" command is generated using a command substitution, so the exit status is that of the local command. In the other, only an assignment is done, which is not a command, so the exit status is that of the last command substitution. Dale
Re: Seg fault on "echo ~nosuchuser"
On Thu, May 28, 2020 at 03:12:47PM -0700, Keith Thompson wrote: > I see this problem on copies of bash 5.0.16 and 5.0.17 built from > sourced on Ubuntu 20.04 LTS. It does *not* occur with the /bin/bash > GNU bash, version 5.0.16(1)-release (x86_64-pc-linux-gnu) > provided by the distribution. I haven't verified how far > back this goes. For what it's worth, I cannot reproduce this on Bash 5.0.17 compiled with musl 1.2.0 or glibc 2.28 on Debian 10, GCC 8.3.0. musl: ~$ bash --version GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) ... ~$ bash -c 'echo ~nosuchuser' ~nosuchuser glibc: bash-5.0$ ldd --version ldd (Debian GLIBC 2.28-10) 2.28 ... bash-5.0$ ./bash --version GNU bash, version 5.0.17(2)-release (x86_64-pc-linux-gnu) ... bash-5.0$ ./bash -c 'echo ~nosuchuser' ~nosuchuser Eric
