Re: bug-bash Digest, Vol 232, Issue 27
I have put together my own bash debugger (I like it better than the others I've seen), and wanted to have variable name auto completion in the 'read' built-in, just like it is in the base command line. Is there a reason that bash uses a readline that is differently configured in the 'read' builtin versus the full featured autocompletion available in readline at the command line? Would this be a difficult thing to implement? -- Jeremy
Re: Arithmetic evaluation of negative numbers with base prefix
Dear Chet
Many thanks for your impressively swift response. It is enlightening to see
how these expressions are parsed.
For the record, whilst I can now see how they are parsed, it feels
particularly unsatisfactory that the following two expressions yield the same
result when the variable i happens to have unwittingly been decremented below
zero (by bash arithmetic evaluation by the way - not by the output of some
external command):
echo $((3-10#${i}))
echo $((3+10#${i}))
As you indicate, this is caused by 10# being parsed as zero. That silent
assumption of zero effectively then also silently nullifies/swallows the
preceding operator.
Ilkka Virta's email helpfully pointed me to a somewhat related debate that
occurred about 11 months ago. I agree with your comment in this debate:
"There would be a good case for rejecting the '10#' because it's missing
the value."
It is this silently proceeding with a plausible (but undesirable) output in
such cases which is especially concerning.
In the meantime it would seem cautionary to advise against the pitfall of
using base# prefixed to variables (contrary to
mywiki.wooledge.org/ArithmeticExpression) unless you can be confident that
they will never be decremented below zero.
At the very least it would be helpful if the manual reflected that 10#
followed by anything other than a digit ([0-9a-zA-Z@_]) is parsed as zero, and
rlarified more completely the constraints of "number" for "n" in the "base#"
paragraph.
I cannot find anywhere else in the manual where the word "number", "numeric
value" or "integer" excludes values less than zero without explicitly stating
so. On the other hand phrases like "[if] ... number/numeric values less than
zero", "if ... [not] a number greater than [or equal to] zero" are used
repeatedly. In those cases "number" clearly doesn't exclude those less than
zero.
Jeremy Townshend
Arithmetic evaluation of negative numbers with base prefix
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-vEMnMR/bash-4.4.18=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux tower 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4
Patch Level: 19
Release Status: release
Description:
Unexpected and undocumented behaviour for arithmetic evaluation of
negative numbers when prefixed with the optional "base#" (e.g. 10#${i}). The
base prefix may be needed if the variable has a decimal integer value but might
be zero-padded, otherwise it is at risk of being misinterpreted as an octal.
Where the variable holds a negative value, results are as you would expect
(e.g. i=-1; echo $((10#${i})), returns -1) until you subtract (or unary minus)
the variable. This unexpected behaviour occurs even when numbers are used
directly (as in the first part of the Repeat-By section to simplify) but in
real world examples the number would be hidden in a variable requiring the
optional "base#" prefix to ensure correct interpretation of its value.
Repeat-By:
echo $((10#-1)) # -1 as expected
echo $((0-10#1)) # -1 as expected
echo $((0+10#-1)) # -1 as expected
echo $((0-10#-1)) # -1 UNEXPECTED. Would expect 1.
echo $((0--1))# 1 as expected
# Real world example:
i=001
echo $((3-10#${i})) # 2 as expected
i=$((10#${i}-2))# i's value decremented by 2 to -1
echo $((3-10#${i})) # 2 UNEXPECTED. Would expect 4.
echo $((3+10#${i})) # 2 as expected
# Certainly wouldn't expect the last two expressions to have the same
# result.
Re: Sourcing a script from a pipe is not reliable
Yes, exactly. It appears that "source" tries to read from /dev/stdin before anything is ready from the pipe and treats that as an EOF. You do not even need to sleep, you can just use "cat" instead of "echo" to produce the script and "source" fails reliably. This appears to have been fixed in bash 4.0 (though possibly it was actually fixed in readline 7.0) I now have 2 workarounds that seem to work (at least on the example system where the bug was found): 1) Add sleep to wait for input echo echo '$1' | (sleep 0; . /dev/stdin yes) 2) Use a here-is document . /dev/stdin yes <<'EOF' echo $1 EOF Thanks for your help. On Thu, Jan 10, 2019 at 12:01 AM don fong wrote: > interesting. it looks like somehow the ". /dev/stdin yes" side isn't > waiting for the "echo echo '$1'" side to write to the pipe. > > in theory, you should be able to delay the echo and it should still work... > > (sleep 1; echo echo '$1') | . /dev/stdin yes > > but on my mac, adding the sleep makes it fail reliably on the first > iteration. > > on my linux machine, it seems to succeed reliably even with the sleep - as > expected. > > > > > > > On Wed, Jan 9, 2019 at 10:54 PM Jeremy wrote: > >> Configuration Information [Automatically generated, do not change]: >> >> Machine: Mac >> >> OS: Darwin >> >> Compiler: gcc >> >> Compilation CFLAGS: Xcode >> >> uname output: Darwin Octo.local 15.6.0 Darwin Kernel Version 15.6.0: Thu >> Jun 21\ >> >> 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64 >> >> Machine Type: x86_64-Apple-Darwin >> >> >> Bash Version: 3.2 >> >> Patch Level: 48 >> >> Release Status: relase >> >> >> Although bashbug listed the Patch Level as 48 (and misspelled "release") >> the version string is >> >> 3.2.57(1)-release (x86_64-apple-darwin15) >> >> >> This is on MacOS 10.11.6. If there is a better place for me to report this >> bug, please let me know. >> >> Description: >> >> Sourcing a script from a pipe is not reliable. >> >> >> Repeat-By: >> >> This command line should run forever: >> >> >> i=0; while [ "_$(echo echo '$1' | . /dev/stdin yes)" = "_yes" ]; \ >> >> do echo -n .; ((i++)); done; printf "\n%s\n" $i >> >> >> When I run it, it usually terminates with $i much less than 1,000. >> >
Re: Sourcing a script from a pipe is not reliable
I appreciate the help, Martijn, and I suspect I will find your suggestions useful in the future, but they do not completely work for us in the present instance. We are, in part, trying to determine if our script may have lost its positional parameters because it was invoked by someone else using ". ourscript --options" in a shell that does not support that, so it does not help to know they could have done it better some other way. On Thu, Jan 10, 2019 at 3:29 PM Martijn Dekker wrote: > Op 10-01-19 om 22:52 schreef Jeremy: > > We are trying to determine if the current shell supports passing > positional > > arguments to a script sourced by dot (.), and we are trying to do it in a > > way that will work under pretty much any shell. If you can show me how > to > > do that with eval, then that would be great, even though in general I > hate > > to ship a script that uses eval. > > While not all shells support passing positional parameters to dot > scripts, it is very simple to make work for POSIX sh: shell functions > provide positional parameters, so wrap the dot command in one of those. > ... >
Re: Sourcing a script from a pipe is not reliable
A more reliable way to demonstrate the bug: cat <(echo echo '$1' 2) | . /dev/stdin yes Should output "yes 2", and does in bash 4.4.23, but in bash 3.2.57(1)-release it outputs nothing: the output of cat does not get sourced. Reminder, I'm seeking a workaround rather than a patch, to reliably test if the current shell supports passing positional parameters to a sourced script, without creating a temporary file. On Wed, Jan 9, 2019 at 8:11 PM Jeremy wrote: > Configuration Information [Automatically generated, do not change]: > > Machine: Mac > > OS: Darwin > > Compiler: gcc > > Compilation CFLAGS: Xcode > > uname output: Darwin Octo.local 15.6.0 Darwin Kernel Version 15.6.0: Thu > Jun 21\ > > 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64 > > Machine Type: x86_64-Apple-Darwin > > > Bash Version: 3.2 > > Patch Level: 48 > > Release Status: relase > > > Although bashbug listed the Patch Level as 48 (and misspelled "release") > the version string is > > 3.2.57(1)-release (x86_64-apple-darwin15) > > > This is on MacOS 10.11.6. If there is a better place for me to report this > bug, please let me know. > > Description: > > Sourcing a script from a pipe is not reliable. > > > Repeat-By: > > This command line should run forever: > > > i=0; while [ "_$(echo echo '$1' | . /dev/stdin yes)" = "_yes" ]; \ > > do echo -n .; ((i++)); done; printf "\n%s\n" $i > > > When I run it, it usually terminates with $i much less than 1,000. >
Re: Sourcing a script from a pipe is not reliable
On Thu, Jan 10, 2019 at 11:59 AM Chet Ramey wrote: > On 1/10/19 2:52 PM, Jeremy wrote: > >> This command line should run forever: > > >> i=0; while [ "_$(echo echo '$1' | . /dev/stdin yes)" = "_yes" ]; \ > > do echo -n .; ((i++)); done; printf "\n%s\n" $i > > >> When I run it, it usually terminates with $i much less than 1,000. > > > >... The thing is I do not have control over which > > versions of bash people use to run the script, so I need a workaround. > > > > ... > > I am not happy with the obvious workaround of sourcing a file instead of > > /dev/stdin. > > Have you considered reading stdin into a string (if it's one line) or an > array (if it's more) and using `eval' on it? That obviously works better > if it's one line, but could be made to work on multiple lines. > > We are trying to determine if the current shell supports passing positional arguments to a script sourced by dot (.), and we are trying to do it in a way that will work under pretty much any shell. If you can show me how to do that with eval, then that would be great, even though in general I hate to ship a script that uses eval. The best workaround I have come up with so far is to generate a more complex script that outputs either "yes" or "no" and then retry if it gets no output, but then I have to put a limit on retries to avoid a possible infinite loop and handle the case where the loop terminates without an answer. My hope is that if we understand the source of the bug we can create a more straightforward work around.
Re: Sourcing a script from a pipe is not reliable
On Thu, Jan 10, 2019 at 11:38 AM Chet Ramey wrote: > On 1/10/19 2:36 PM, Jeremy wrote: > > Agreed there is no likelihood of a patch to 3.2. However, this version of > > bash still has a significant presence in the wild and this bug is > breaking > > an installation script, so I am looking for a POSIX-compliant (and works > > under Cygwin) alternative that avoids this bug so the script can be > > modified. > > Have you tried a newer version of bash? > > This bug seems not to be in current versions of bash 4.x, but I have not made an exhaustive study. The thing is I do not have control over which versions of bash people use to run the script, so I need a workaround. I was hoping this was a known bug with a known cause and a known workaround that would continue to be very portable. Alternatively, if we can narrow down which versions of bash are affected, then we can consider doing a specific check for that. So far we have been able to limit this script to read operations so that it can run unprivileged on a read-only file system as it is read from a stream. That is why we are generating the script inline like this, and why I am not happy with the obvious workaround of sourcing a file instead of /dev/stdin.
Re: Sourcing a script from a pipe is not reliable
Agreed there is no likelihood of a patch to 3.2. However, this version of bash still has a significant presence in the wild and this bug is breaking an installation script, so I am looking for a POSIX-compliant (and works under Cygwin) alternative that avoids this bug so the script can be modified. As a step towards getting there, and out of plain curiosity, I would also like to know if this is due to a known bug and if so, what the underlying cause is and in what versions it has been fixed. On Wed, Jan 9, 2019 at 11:09 PM Eduardo Bustamante wrote: > On Wed, Jan 9, 2019 at 10:54 PM Jeremy wrote: > (...) > > 3.2.57(1)-release (x86_64-apple-darwin15) > > > > > > This is on MacOS 10.11.6. If there is a better place for me to report > this > > bug, please let me know. > > Have you tried the latest version? Bash 5.0 was just released: > https://lists.gnu.org/archive/html/bug-bash/2019-01/msg00063.html > > I don't think you'll be seeing any updates in the OS X provided > version of bash, so there's no point in even trying to back-port any > fixes to 3.2 > >
Sourcing a script from a pipe is not reliable
Configuration Information [Automatically generated, do not change]: Machine: Mac OS: Darwin Compiler: gcc Compilation CFLAGS: Xcode uname output: Darwin Octo.local 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 21\ 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64 Machine Type: x86_64-Apple-Darwin Bash Version: 3.2 Patch Level: 48 Release Status: relase Although bashbug listed the Patch Level as 48 (and misspelled "release") the version string is 3.2.57(1)-release (x86_64-apple-darwin15) This is on MacOS 10.11.6. If there is a better place for me to report this bug, please let me know. Description: Sourcing a script from a pipe is not reliable. Repeat-By: This command line should run forever: i=0; while [ "_$(echo echo '$1' | . /dev/stdin yes)" = "_yes" ]; \ do echo -n .; ((i++)); done; printf "\n%s\n" $i When I run it, it usually terminates with $i much less than 1,000.
Sourcing a script from a pipe is not reliable
Configuration Information [Automatically generated, do not change]: Machine: Mac OS: Darwin Compiler: gcc Compilation CFLAGS: Xcode uname output: Darwin Octo.local 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 21\ 20:07:40 PDT 2018; root:xnu-3248.73.11~1/RELEASE_X86_64 x86_64 Machine Type: x86_64-Apple-Darwin Bash Version: 3.2 Patch Level: 48 Release Status: relase Description: Sourcing a script from a pipe is not reliable. Repeat-By: This command line should run forever: i=0; while [ "_$(echo echo '$1' | . /dev/stdin yes)" = "_yes" ]; \ do echo -n .; ((i++)); done; printf "\n%s\n" $i When I run it, it usually terminates with $i much less than 1,000.
trap - inconsistent behaviour
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-vEMnMR/bash-4.4.18=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname output: Linux tower 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4
Patch Level: 19
Release Status: release
Description:
The behaviour of the "trap" builtin command changes merely by printing
the
list of commands associated with each signal (trap command issued
without
arguments).
Repeat-By:
Case 1: In a fresh terminal emulator issue the following:
( trap 'echo trapped >&2' HUP; { sleep 10 & sleepPID=$!; wait
$sleepPID; } > >( sleep 1; kill -HUP $BASHPID; cat ) )
Case 2: Then in a fresh terminal emulator issue the following:
( trap 'echo trapped >&2' HUP; { sleep 10 & sleepPID=$!; wait
$sleepPID; } > >( trap; sleep 1; kill -HUP $BASHPID; cat ) )
Expected outcome: either the trap is triggered in both cases or in
neither
since the only difference is the additional trap command with no
arguments
(for printing the list of commands associated with each signal). That
is, in
this case, "trapped" is expected to be printed in both cases or in
neither
case.
Actual outcome: the trap is not triggered in the first instance but is
triggered in the second.
Real use case: where zenity --progress --auto-kill is issuing the kill
-HUP
as a result of the cancel button being pressed.
Heap buffer overread in get_exitstat
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: afl-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fsanitize=address -Wno-parentheses -Wno-format-security uname output: Linux jefeus-vm 4.9.0-4-686-pae #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) i686 GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.4 Patch Level: 19 Release Status: release Description: When calling bash -e (where is a file conaining the string "exit -"), a heap buffer overread of size 1 in builtins/common.c:505 occurs. This is presumably caused by the absence of a check if a number follows the "-" sign. Repeat-By: In order to get bash to run with the compiler flags mentioned above, one must add the --without-bash-malloc or else bash segfaults on startup.
Heap buffer overread in token_is_assignment
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: afl-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fsanitize=address -Wno-parentheses -Wno-format-security uname output: Linux jefeus-vm 4.9.0-4-686-pae #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) i686 GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.4 Patch Level: 19 Release Status: release Description: When calling bash -e (where is the attached file) a heap buffer overread occurs in token_is_assignment at parse.y:4657 (It may be interesting to note that the attached file consists of an arbitrary character, an ampersand and 496 "=" signs whereby 496=2^9-16). Below is a detailed backtrace of this bug: = ==22011==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4b02570 at pc 0x00575be1 bp 0xbfe86508 sp 0xbfe864fc READ of size 1 at 0xb4b02570 thread T0 #0 0x575be0 in token_is_assignment parse.y:4657 #1 0x575be0 in read_token_word parse.y:4961 #2 0x555d6a in read_token parse.y:3296 #3 0x55c226 in yylex parse.y:2675 #4 0x55c226 in yyparse /home/jefeus/bash/y.tab.c:1834 #5 0x536820 in parse_command /home/jefeus/bash/eval.c:261 #6 0x536820 in read_command /home/jefeus/bash/eval.c:305 #7 0x537684 in reader_loop /home/jefeus/bash/eval.c:149 #8 0x52d44c in main /home/jefeus/bash/shell.c:792 #9 0xb6ffc455 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18455) #10 0x533cef (/home/jefeus/bash/bash+0x62cef) 0xb4b02570 is located 0 bytes to the right of 496-byte region [0xb4b02380,0xb4b02570) allocated by thread T0 here: #0 0xb72a9e74 in malloc (/usr/lib/i386-linux-gnu/libasan.so.4+0xdee74) #1 0x7d8bd0 in xrealloc /home/jefeus/bash/xmalloc.c:133 SUMMARY: AddressSanitizer: heap-buffer-overflow parse.y:4657 in token_is_assignment Shadow bytes around the buggy address: 0x36960450: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x36960460: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x36960470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x36960480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x36960490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x369604a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa 0x369604b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x369604c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x369604d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x369604e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x369604f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==22011==ABORTING Repeat-By: In order to get bash to run with the compiler flags mentioned above, one must add the --without-bash-malloc or else bash segfaults on startup. A&
Heap buffer overread in extract_delimited_string
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: afl-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fsanitize=address -Wno-parentheses -Wno-format-security uname output: Linux jefeus-vm 4.9.0-4-686-pae #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) i686 GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.4 Patch Level: 19 Release Status: release Description: When calling bash -e (where is the attached file) a heap buffer overread occurs in extract_delimited_string at subst.c:1335. Below is a detailed backtrace of this bug: = ==7523==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb53018f5 at pc 0x00611484 bp 0xbfdb7018 sp 0xbfdb700c READ of size 1 at 0xb53018f5 thread T0 #0 0x611483 in extract_delimited_string /home/jefeus/bash/subst.c:1335 #1 0x64174a in extract_arithmetic_subst /home/jefeus/bash/subst.c:1255 #2 0x64174a in param_expand /home/jefeus/bash/subst.c:8867 #3 0x649260 in expand_word_internal /home/jefeus/bash/subst.c:9315 #4 0x66122c in call_expand_word_internal /home/jefeus/bash/subst.c:3614 #5 0x66122c in expand_string_internal /home/jefeus/bash/subst.c:3649 #6 0x66122c in expand_string_leave_quoted /home/jefeus/bash/subst.c:3777 #7 0x66122c in expand_string /home/jefeus/bash/subst.c:3825 #8 0x738c51 in write_here_document /home/jefeus/bash/redir.c:394 #9 0x738c51 in here_document_to_fd /home/jefeus/bash/redir.c:478 #10 0x738c51 in do_redirection_internal /home/jefeus/bash/redir.c:972 #11 0x73f5c0 in do_redirections /home/jefeus/bash/redir.c:234 #12 0x498823 in execute_null_command /home/jefeus/bash/execute_cmd.c:3899 #13 0x498823 in execute_simple_command /home/jefeus/bash/execute_cmd.c:4173 #14 0x54c7ed in execute_command_internal /home/jefeus/bash/execute_cmd.c:807 #15 0x54c7ed in execute_command /home/jefeus/bash/execute_cmd.c:405 #16 0x4b5ba4 in reader_loop /home/jefeus/bash/eval.c:180 #17 0x4ab44c in main /home/jefeus/bash/shell.c:792 #18 0xb6f31455 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18455) #19 0x4b1cef (/home/jefeus/bash/bash+0x62cef) 0xb53018f5 is located 0 bytes to the right of 5-byte region [0xb53018f0,0xb53018f5) allocated by thread T0 here: #0 0xb71dee74 in malloc (/usr/lib/i386-linux-gnu/libasan.so.4+0xdee74) #1 0x756aea in xmalloc /home/jefeus/bash/xmalloc.c:112 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/jefeus/bash/subst.c:1335 in extract_delimited_string Shadow bytes around the buggy address: 0x36a602c0: fa fa 00 00 fa fa 04 fa fa fa 04 fa fa fa 04 fa 0x36a602d0: fa fa 03 fa fa fa 04 fa fa fa 04 fa fa fa 00 00 0x36a602e0: fa fa 00 06 fa fa 02 fa fa fa fa fa fa fa fa fa 0x36a602f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x36a60300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x36a60310: fa fa fa fa fa fa fa fa fa fa fa fa fa fa[05]fa 0x36a60320: fa fa 00 05 fa fa fd fa fa fa 00 fa fa fa fd fa 0x36a60330: fa fa 00 fa fa fa 06 fa fa fa 02 fa fa fa 00 00 0x36a60340: fa fa fd fa fa fa 00 fa fa fa 05 fa fa fa fd fa 0x36a60350: fa fa 00 03 fa fa 00 fa fa fa 05 fa fa fa 02 fa 0x36a60360: fa fa fd fa fa fa 00 03 fa fa 00 03 fa fa fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==7523==ABORTING Repeat-By: In order to get bash to run with the compiler flags mentioned above, one must add the --without-bash-malloc or else bash segfaults on startup. It might be worth the effort to include the configure options in the bashbug configure information, as it may contain vital information as is the case here. <<� $[`
Re: programmable completion: completing filenames with default Readline behavior
On Tue, Oct 1, 2013 at 1:59 PM, Chet Ramey wrote: > On 10/1/13 4:55 PM, Jeremy Lin wrote: > >> Thanks, I actually ended up with the same solution (for Bash 4.0 and above, >> where 'compopt' is available, anyway). I just set '+o default' at the top of >> the >> completion function and then set '-o default' as needed. Unfortunately, for >> earlier versions of Bash, the workaround I mentioned previously seems to be >> about as good as it gets. > > Earlier versions of bash are pretty old; bash-4.0 came out almost five > years ago. I know what you mean, but for one reason or another, there are still a fair number of people stuck on RHEL/CentOS 5.x, and hence using 3.2. Hopefully there will be far fewer such people within the next few years... >> In future versions of Bash, it would be nice if the default Readline >> completion >> could be invoked explicitly, rather than requiring this 'compopt' workaround. > > What syntax would you suggest for doing that? It may require inventing a > new way for completion functions to interact with their calling environment. If COMPREPLY could be something other than an array, that might be used to indicate that some other behavior is desired. For example, perhaps COMPREPLY='complete-filename' could produce the behavior you currently get with '-o default' and COMPREPLY=(), but without needing to set '-o default', of course. I'm not sure how cleanly this would fit into the current scheme of things, but it's just an idea. Jeremy
Re: programmable completion: completing filenames with default Readline behavior
On Tue, Oct 1, 2013 at 1:35 PM, Chet Ramey wrote: > On 9/27/13 3:57 AM, Jeremy Lin wrote: >> I'm writing a completion where, in some cases, I'd like to use >> COMPREPLY=() to indicate that no more arguments to a command are >> expected, but in other cases, I'd like to offer the default Readline >> behavior for filename completions. >> >> So, if I have a directory 'foo', I'd like the shell to first complete >> with 'foo/' and then offer to complete files under 'foo'. But if I do >> something like COMPREPLY=($(compgen -f -- "$cur")), then I simply get >> a completion of 'foo' (with a space appended). >> >> I know I can pass "-o default" to get Readline's default filename >> completion when COMPREPLY is empty, but then that seems to preclude >> using COMPREPLY=() to deny completions. > > The `compopt' builtin was intended to add this kind of dynamism to > programmable completion shell functions. You can install a completion > without -o default and turn it on using compopt when the completion > function is executed. It appears to be lightly used, so there are > probably some usability improvements to be made there. For instance, I > think that options, once set using compopt, remain set and need to be > manually disabled. I'm waiting for some more reports from people using > it before I decide how (or whether) to change it. > > Chet Thanks, I actually ended up with the same solution (for Bash 4.0 and above, where 'compopt' is available, anyway). I just set '+o default' at the top of the completion function and then set '-o default' as needed. Unfortunately, for earlier versions of Bash, the workaround I mentioned previously seems to be about as good as it gets. In future versions of Bash, it would be nice if the default Readline completion could be invoked explicitly, rather than requiring this 'compopt' workaround. Jeremy
programmable completion: completing filenames with default Readline behavior
I'm writing a completion where, in some cases, I'd like to use
COMPREPLY=() to indicate that no more arguments to a command are
expected, but in other cases, I'd like to offer the default Readline
behavior for filename completions.
So, if I have a directory 'foo', I'd like the shell to first complete
with 'foo/' and then offer to complete files under 'foo'. But if I do
something like COMPREPLY=($(compgen -f -- "$cur")), then I simply get
a completion of 'foo' (with a space appended).
I know I can pass "-o default" to get Readline's default filename
completion when COMPREPLY is empty, but then that seems to preclude
using COMPREPLY=() to deny completions.
I've tried a number of different workarounds, none of which I was
completely happy with (or I probably wouldn't be asking this
question). The closest I got was setting "-o default", and then using
COMPREPLY=("") to semi-deny completion, and COMPREPLY=() to get
filename completion.
Can anyone offer a better approach?
Thanks,
Jeremy
Bash interprets $! as an event
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../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux figment 2.6.32-24-server #38-Ubuntu SMP Mon Jul 5 10:29:32 UTC 2010 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.1 Patch Level: 5 Release Status: release Description: Event-catching seems to be catching cases it shouldn't. In particular, $! is caught as an event. Repeat-By: This command fails as follows: > nicku...@woking:~$ sleep 5 & PID=$!; echo "pid is $PID" > bash: !: event not found Adding quotation marks doesn't help: > nicku...@woking:~$ sleep 5 & PID="$!"; echo "pid is $PID" > bash: !": event not found As a workaround, adding whitespace after the ! fixes it: > nicku...@woking:~$ sleep 5 & PID=$! ; echo "pid is $PID" > [1] 1614 > pid is 1614 or > nicku...@woking:~$ sleep 5 & PID="$! "; echo "pid is $PID" > [3] 2048 > pid is 2048
tmp file creation in bash provided scripts
I noticed bashbug attempts creating temp file first with mktemp, and then falls back to tempfile, and then to just using its own $TMPDIR/bbug.$$. A malicious user could attempt prepulating bogus files to make it so that mktemp and tempfile fail, and create many symlinks covering your PID range for the $TMPDIR/bbug.$$ to point to your important files. I see bashbug.sh does remove the temp file name is chose and then overwrites it. It has a comment: # this is raceable unless (hopefully) we used mktemp(1) or tempfile(1) Maybe as a third choice use the temp file creation from your configure script as an idea. Use umask 077 and create directory then user can't place symlinks in it. Jeremy C. Reed technical support & remote administration http://www.pugetsoundtechnology.com/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Gegen das Vergessen
In den fruehen Abendstunden des 13. Februar 1945 gegen 21:41 Uhr heulten die Sirenen der Lazarettstadt Dresden das erste mal auf. Die Bewohner der Elbmetropole machten sich zu der Zeit noch keine Sorgen, da Dresden als Stadt ohne Bewaffnung und ohne militaerischen Nutzen bekannt war und von ca. 1,2 Millionen Frauen, Kindern und Greisen bewohnt wurde. Gegen 22:09 Uhr gab der Rundfunk durch, daß die alliierten Bomberverbaende ihren Kurs geaendert haben und nun auf Dresden zufliegen. Kurz darauf befanden sich 244 britische Bomber am Himmel der deutschen Kulturstadt. Drei Stunden nach dieser ersten Angriffswelle - es befanden sich bereits alle verfuegbaren Rettungsmannschaften, Sanitaeter und Feuerwehmaenner in Dresden - verdunkelten weitere 500 Bomber den Himmel. Am naechsten Tag folgte die letzte Angriffswelle mit erneut 300 US-B-17-Bombern. Zwischen 12:12 Uhr und 12:21 Uhr warfen diese 783 Tonnen Bomben ab. - Das entspricht mehr als 85 Tonnen pro Minute. Nach dem Abwerfen setzten die US-Bomber zum Tiefflug an und beschossen Fluechtende mit ihren Bordwaffen. In diesen drei Angriffsschlaegen, die insgesamt 14 Stunden andauerten, warfen die "Befreier" 650.000 Brandbomben und 200.000 Sprengbomben ab, welche einen Feuersturm von ueber 1000 Grad in der Stadt erzeugten. Obwohl Dresden weder Flugabwehr, noch Ruestungsindustrie oder aehnliche kriegswichtige Ziele besass wurden weit mehr als 350.000 unschuldige deutsche Zivilisten in diesen zwei Tagen kaltbluetig ermordet. Keiner der schuldigen Alliierten wurde jemals fuer dieses brutale Kriegsverbrechen auch nur angeklagt und die Massenmedien und die bundesdeutsche Regierung schweigen diese Taten tot und sehen es nicht als noetig an den Opfern zu gedenken.! ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
