Re: bug-bash Digest, Vol 232, Issue 27

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

es 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'

Re: Sourcing a script from a pipe is not reliable

> 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 reliab

Re: Sourcing a script from a pipe is not reliable

". 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 cur

Re: Sourcing a script from a pipe is not reliable

, 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 > >

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; p

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

Re: Sourcing a script from a pipe is not reliable

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: >

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:

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:

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'

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'

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'

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'

Re: programmable completion: completing filenames with default Readline behavior

On Tue, Oct 1, 2013 at 1:59 PM, Chet Ramey chet.ra...@case.edu 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

Re: programmable completion: completing filenames with default Readline behavior

On Tue, Oct 1, 2013 at 1:35 PM, Chet Ramey chet.ra...@case.edu 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

programmable completion: completing filenames with default Readline behavior

, 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'

tmp file creation in bash provided scripts

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