Re: language inconsistency(wart) & RFE

On 10/17/15, Linda Walsh wrote: > Ok, thinking this from a different way. > > shopt -s implicit_vars_local > or > shopt -s localize_func_implicit_vars whatever... > > Right now, in a function, you *can* use local in a function > to make a local var. Thing is, both 'declare' and 'typeset' also

language inconsistency(wart) & RFE

Ok, thinking this from a different way. shopt -s implicit_vars_local or shopt -s localize_func_implicit_vars whatever... Right now, in a function, you *can* use local in a function to make a local var. Thing is, both 'declare' and 'typeset' also make a *local* var in a function, unless the

problem with @A and arrays

${array[@]@A} splits the values. $ a=("ab" "c d"); printf "<%s>" "${a[@]@A}" <-a><[1]="c> diff --git a/subst.c b/subst.c index 2a7366f..d7258b8 100644 --- a/subst.c +++ b/subst.c @@ -4796,18 +4796,26 @@ array_var_assignment (v, itype, quoted) { char *ret, *val, flags[MAX_ATTRIBUTES];

Design question(s), re: why use of tmp-files or named-pipes(/dev/fd/N) instead of plain pipes?

In another note about different implementations associated with the pattern "[read[array]] LVALUE [< $(]+ RVALUE [)]?"... I gave a rough syntax for how I initially thought process substitution might have been implemented before I got that it used named pipes (like /dev/fd/99, for example). repea

Re: why must bash zap last search string just because we hit ^C?

On Fri, Oct 16, 2015 at 1:50 PM, Chet Ramey wrote: > On 10/16/15 3:19 AM, 積丹尼 Dan Jacobson wrote: > > Type ^Racb^C^R^R > > (Search backwards for abc, then hit ^C, then try searching backwards > > some more using the last search string.) > > > > My problem is why must bash zap the memory of abc ju

Re: updating shopt compat settings to include current version

On 16 Oct 2015 14:26, Chet Ramey wrote: > On 10/16/15 11:37 AM, Chet Ramey wrote: > > unset BASH_COMPAT > > shopt -u compat31 compat32 compat40 compat41 > > shopt -s compat42 2>/dev/null || : > > > > to set shell_compatibility_level to 42 on bash versions >= bash-4.2. > > > > (this needs the atta

Re: why must bash zap last search string just because we hit ^C?

On 10/16/15 3:19 AM, 積丹尼 Dan Jacobson wrote: > Type ^Racb^C^R^R > (Search backwards for abc, then hit ^C, then try searching backwards > some more using the last search string.) > > My problem is why must bash zap the memory of abc just because we hit ^C? ^C rudely aborts the entire operation. W

Re: updating shopt compat settings to include current version

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/16/15 11:37 AM, Chet Ramey wrote: > unset BASH_COMPAT > shopt -u compat31 compat32 compat40 compat41 > shopt -s compat42 2>/dev/null || : > > to set shell_compatibility_level to 42 on bash versions >= bash-4.2. > > (this needs the attached pat

Re: updating shopt compat settings to include current version

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/15 5:30 PM, Mike Frysinger wrote: > that assumes that behavior changes only once between versions. pretty su re > we've seen changes where bash-3.2 did one thing, bash-4.3 did something e lse, > and versions in between did yet another thing.

why must bash zap last search string just because we hit ^C?

Type ^Racb^C^R^R (Search backwards for abc, then hit ^C, then try searching backwards some more using the last search string.) My problem is why must bash zap the memory of abc just because we hit ^C?