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

'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

er/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' -DPACKA

Re: Sourcing a script from a pipe is not reliable

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

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

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

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++)

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 scrip

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

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

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

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/local

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'

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

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'

programmable completion: completing filenames with default Readline behavior

estion). 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' -DPACKA

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/ __

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.