Re: declare -g var should return a nonzero return code when it fails

2013-11-02 Thread Chet Ramey
On 11/1/13, 12:37 AM, Peggy Russell wrote:
> Hi,
> 
> "declare -g var" should return a nonzero return code when it fails.
> 
> Declaring a local variable as global in a function, has a exit status of 0, 
> but the operation was not successful (see test_error).  "help declare" and
> the bash man page indicate the exit status will indicate success or failure.

There is a problem here, and the problem that causes the spurious error
message from test_error has been fixed in bash-4.3. However, I don't think
you completely understand what bash scoping is, or what makes a variable
set or unset.

First, using declare without assigning a value creates a variable
"placeholder".  The variable exists as more-or-less invisible, but is not
considered set until it is assigned a value.  Therefore, declare -g var
just creates a placeholder at the global scope if there is no existing
global variable with that name.  If there is such a variable, it's a
no-op.  The `redeclare local variable as global' comment is just incorrect.

Second, declaring a variable, even a placeholder, at the global scope does
nothing to a variable with the same name at the local scope.  Bash's
scoping rules mean that it will use a local variable instead of a global
variable if there is a local variable declared in the currently-executing
function.  That's why the assignments of "data2" and "data3" affect the
local variable and disappear when the function returns.

> The "declare -g var", did not just fail with a return code of 0, but it
> also removed the variable from the environment. Isn't that grounds for
> a nonzero return code... 

That's a bug in bash-4.2.  The correct output is

test_success: rc [0]
declare -- var="data1"
== test_success: [data1]

./x2: line 27: declare: var: not found

test_error: rc [0]
declare -- var="data2"
test_error: rc [0]
declare -- var="data2"
declare -- var="data3"
== test_error: []


Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Re: The default value of TIMEFORMAT is incorrectly formatted

2013-11-02 Thread Chet Ramey
On 11/1/13, 5:54 PM, Seungbeom Kim wrote:
> 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  
> -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 
> -Wformat -Werror=format-security -Wall
> uname output: Linux cardinal3.stanford.edu 3.8.0-31-generic #46-Ubuntu SMP 
> Tue Sep 10 20:03:44 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
> 
> Bash Version: 4.2
> Patch Level: 45
> Release Status: release
> 
> Description:
>   The default value of TIMEFORMAT is incorrectly formatted:
>   it is shown as   $'\nreal\t%3lR\nuser\t%3lU\nsys%3lS' in the man page,
>   but it should be $'\nreal\t%3lR\nuser\t%3lU\nsys\t%3lS'.

Thanks for the report.  This has already been fixed for bash-4.3.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Re: The default value of TIMEFORMAT is incorrectly formatted

2013-11-02 Thread Geir Hauge
2013/11/2 Chet Ramey 

> On 11/1/13, 5:54 PM, Seungbeom Kim wrote:
> > Description:
> >   The default value of TIMEFORMAT is incorrectly formatted:
> >   it is shown as   $'\nreal\t%3lR\nuser\t%3lU\nsys%3lS' in the man
> page,
> >   but it should be $'\nreal\t%3lR\nuser\t%3lU\nsys\t%3lS'.
>
> Thanks for the report.  This has already been fixed for bash-4.3.
>

I reported this a while back too, and it is changed in the latest devel
branch, but it appears you introduced a different typo:

$'\nreal\t%3lR\nuser\t%3lU\nsys\tt%3lS'

-- 
Geir Hauge