Just a heads up on something I hadn't noticed: Bash (and dash) treat
octal literals in printf precision inconsistently (using glibc -- not
sure if it's a bug or GNUism on that end or the shell):
$ bash -c 'printf "<%.010d> <%.*d>\n" 1 010 1'
<01> <0001>
Zsh is also inconsisten
On 5/5/14, 7:09 AM, Dan Douglas wrote:
> Just a heads up on something I hadn't noticed: Bash (and dash) treat
> octal literals in printf precision inconsistently (using glibc -- not
> sure if it's a bug or GNUism on that end or the shell):
>
> $ bash -c 'printf "<%.010d> <%.*d>\n" 1 010 1'
>
On 4/29/14, 3:25 PM, Pierre Gaston wrote:
> A couple of 4.3 bugs have surfaced on IRC, I'm not sure they are reported
> here, so just in case here they are
Thanks for the report. All of these will be fixed in the next release of
bash. The first is a general problem with any extglob pattern that
On 5/5/14, 2:11 AM, Jesper Nygårds wrote:
> Chet,
>
> Not that it is pressing in any way, but have you had any time to look at
> this?
Sorry, I haven't looked at it yet. I hope to get to it soon.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/3/14, 7:22 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> 'local -x VARIABLE' (without assignment of value) does not clear variable for
> subprocesses.
> It is regression in bash 4.3.
It's not actually a regression; it's a bug fix. It's worth
On 5/3/14, 10:59 PM, Linda Walsh wrote:
>
>
> Arfrever Frehtes Taifersar Arahesis wrote:
>> bash 4.2.47:
>> $ export VAR1=abc VAR2=abc
>> $ f() { local VAR1; local -x VAR2; bash -c 'declare -p VAR{1,2}'; }
>> $ f
>> bash: line 0: declare: VAR1: not found
>> bash: line 0: declare: VAR2: not found
On 05/05/2014 05:09 AM, Dan Douglas wrote:
> Just a heads up on something I hadn't noticed: Bash (and dash) treat
> octal literals in printf precision inconsistently (using glibc -- not
> sure if it's a bug or GNUism on that end or the shell):
Umm, there's no such thing as an octal precision print
> On 05/05/2014 05:09 AM, Dan Douglas wrote:
> > Just a heads up on something I hadn't noticed: Bash (and dash) treat
> > octal literals in printf precision inconsistently (using glibc -- not
> > sure if it's a bug or GNUism on that end or the shell):
>
> Umm, there's no such thing as an octal pre
On Monday, May 05, 2014 09:37:27 AM Eric Blake wrote:
> On 05/05/2014 05:09 AM, Dan Douglas wrote:
> > Just a heads up on something I hadn't noticed: Bash (and dash) treat
> > octal literals in printf precision inconsistently (using glibc -- not
> > sure if it's a bug or GNUism on that end or the s
2014-05-05 17:18 Chet Ramey napisał(a):
> On 5/3/14, 7:22 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> > 'local -x VARIABLE' (without assignment of value) does not clear variable
> > for subprocesses.
> > It is regression in bash 4.3.
>
> It's not actually a regression; it's a bug fix. It's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/5/14, 1:13 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> Behavior of bash 4.3 is inconsistent between non-subshell subprocesses and
> other places:
> bash 4.3.11:
>
> $ export VAR{1,2}=abc
> $ f() { local VAR1; local -x VAR2; echo "### Norm
2014-05-05 22:12 Chet Ramey napisał(a):
> > Ability to locally unset a variable also for subprocesses would be
> > preferable solution.
>
> OK. I'm not sure exactly what this means. Can you give me an example?
> How would you use this in a situation where `unset' or `declare +x' are
> unusable?
Chet Ramey wrote:
Yes. Once you assign a value to the local instances of the variables,
they are set.
Local variables inherit the exported status of the variable they are
shadowing to avoid surprises in the export environment. Believe it or
not, it's less surprising than letting a local varia
13 matches
Mail list logo
