Re: status on $[arith] for eval arith vsl $((arith))??
Linda Walsh writes: > - YESTERDAY=$(date -r $((`date +%s` - 86400 )) +%d/%m/%Y This fails around autumn DST transition (assuming s/-r /-d @/). YESTERDAY=$(date -d '12:00 yesterday' +%d/%m/%Y) Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: inconsistency with "readonly" and scope
On 4/11/12 4:12 PM, dethrophes wrote: > I've also noticed weird behavior with "declare -gr" the r sometimes seems > to override the g, but not specific to functions It seems to be specific > either to the source file or to the compound statement. I haven't been able > to figure out exactly whats going on there. I haven't been able to > reproduce it in a simple example. this is most readily noticeable with set > -o nounset An example would help. The above is supposed to create a global readonly variable. I suspect that you see the `global' as being `overridden' because it's being created in a subshell environment. 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: inconsistency with "readonly" and scope
On 4/11/12 2:50 PM, Greg Wooledge wrote: > "declare" when used in a function acts like "local", and creates a variable > with scope local to that function. So does "declare -r". But "readonly", > which is otherwise the same as "declare -r", creates variables with global > scope. > > Is this intended? Yes. `readonly' is part of Posix, and behaves as Posix specifies. `declare' is not, and can do what it likes. 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/
small fix for lib/sh/snprintf.c
Hi, we are running Bash 3.2.38 on Solaris 10 where asprintf() isn't available. Thus code in snprintf.c is used. There is a problem with following command: bash -c 'printf "x%10.0fx\n" 123' x000123x Where correct output should be: x 123x It seems that '0' after '.' enables zero padding. Please see proposed patch bellow: --- bash-3.2.48/lib/sh/snprintf.c Tue Dec 12 12:10:18 2006 +++ bash-3.2.48/lib/sh/snprintf.c Thu Apr 12 08:55:44 2012 @@ -1277,6 +1277,8 @@ data->flags |= PF_ALTFORM; continue; case '0': + if (data->flags & PF_DOT) + continue; data->flags |= PF_ZEROPAD; data->pad = '0'; continue; The same code seems to be also in Bash 4.1 so I guess the problem is still there. Any comments? Thanks, Petr
Re: small fix for lib/sh/snprintf.c
Petr Sumbera wrote: Hi, we are running Bash 3.2.38 on Solaris 10 where asprintf() isn't available. Thus code in snprintf.c is used. There is a problem with following command: bash -c 'printf "x%10.0fx\n" 123' x000123x Where correct output should be: x 123x It seems that '0' after '.' enables zero padding. Please see proposed patch bellow: --- bash-3.2.48/lib/sh/snprintf.c Tue Dec 12 12:10:18 2006 +++ bash-3.2.48/lib/sh/snprintf.c Thu Apr 12 08:55:44 2012 @@ -1277,6 +1277,8 @@ data->flags |= PF_ALTFORM; continue; case '0': + if (data->flags & PF_DOT) + continue; data->flags |= PF_ZEROPAD; data->pad = '0'; continue; The same code seems to be also in Bash 4.1 so I guess the problem is still there. Same code is in bash-4.2.24, the latest currently
Re: inconsistency with "readonly" and scope
Am 12.04.2012 14:27, schrieb Chet Ramey: On 4/11/12 4:12 PM, dethrophes wrote: I've also noticed weird behavior with "declare -gr" the r sometimes seems to override the g, but not specific to functions It seems to be specific either to the source file or to the compound statement. I haven't been able to figure out exactly whats going on there. I haven't been able to reproduce it in a simple example. this is most readily noticeable with set -o nounset An example would help. The above is supposed to create a global readonly variable. I suspect that you see the `global' as being `overridden' because it's being created in a subshell environment. Chet I only see the problem in large complex cases, I've tried to reproduce a simple example a couple of times but without success. no its not a subshell problem, I avoid subshells as much as possible. also when I expereimented with the problem a couple of times I discovered the following- declare -g works declare -gr doesn't work my current workaround is I've just stopped using the readonly attribute which works. or just stopped using declare altogether. or do something like this var=x typeset -r var I've also seen some strange behavior with declare in a conditional sourced global context. it only seems to happen when the code size is 1s+ lines long. I think this is exasperated by the fact that i source my files inside conditional statements. the result is that I now even in a global context set the global flag. any ideas what could be causing it would help me try to figure out how to test for it. Sorry about the weak description but I've been working around it now for months waiting for it to make sense and I'm no closer to figuring out whats going on. the problem is so erratic it has to be some sort of partial lost context or something. can you give me any tips on how to debug it if I can reproduce it again? is their an easy way to track the validity of a variable?
Re: inconsistency with "readonly" and scope
On 4/12/2012 2:16 PM, dethrophes wrote:
Am 12.04.2012 14:27, schrieb Chet Ramey:
On 4/11/12 4:12 PM, dethrophes wrote:
I've also noticed weird behavior with "declare -gr" the r sometimes seems
to override the g, but not specific to functions It seems to be specific
either to the source file or to the compound statement. I haven't been able
to figure out exactly whats going on there. I haven't been able to
reproduce it in a simple example. this is most readily noticeable with set
-o nounset
An example would help. The above is supposed to create a global readonly
variable. I suspect that you see the `global' as being `overridden'
because it's being created in a subshell environment.
Chet
It took me a second to reproduce it, but here it is:
--
#! /bin/bash
A()
{
typeset v1=Hello
B
echo "IN B:$v1"
}
B()
{
typeset -r v1=Goodbye
:
}
typeset -r v1=abc
A
echo "v1:$v1"
--
This is 4.0.35(1).
The v1 that's set to abc is the global one.
A defines a local copy that's not readonly and B defines one that is. When I
run it I get:
950 > ./foo.sh
./foo.sh: line 5: typeset: v1: readonly variable
./foo.sh: line 13: typeset: v1: readonly variable
IN B:abc
v1:abc
This means that the typeset failed is both A and B and the references in the
routines fell back to the global instance of v1.
Does this help?
I only see the problem in large complex cases, I've tried to reproduce a
simple example a couple of times but without success.
no its not a subshell problem, I avoid subshells as much as possible.
also when I expereimented with the problem a couple of times I discovered the
following-
declare -g works
declare -gr doesn't work
my current workaround is I've just stopped using the readonly attribute which
works. or just stopped using declare altogether.
or do something like this
var=x
typeset -r var
I've also seen some strange behavior with
declare in a conditional sourced global context. it only seems to happen when
the code size is 1s+ lines long.
I think this is exasperated by the fact that i source my files inside
conditional statements. the result is that I now even in a global context set
the global flag.
any ideas what could be causing it would help me try to figure out how to test
for it.
Sorry about the weak description but I've been working around it now for
months waiting for it to make sense and I'm no closer to figuring out whats
going on.
the problem is so erratic it has to be some sort of partial lost context or
something.
can you give me any tips on how to debug it if I can reproduce it again? is
their an easy way to track the validity of a variable?
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
Re: inconsistency with "readonly" and scope
Am 12.04.2012 22:11, schrieb Steven W. Orr:
On 4/12/2012 2:16 PM, dethrophes wrote:
Am 12.04.2012 14:27, schrieb Chet Ramey:
On 4/11/12 4:12 PM, dethrophes wrote:
I've also noticed weird behavior with "declare -gr" the r sometimes
seems
to override the g, but not specific to functions It seems to be
specific
either to the source file or to the compound statement. I haven't
been able
to figure out exactly whats going on there. I haven't been able to
reproduce it in a simple example. this is most readily noticeable
with set
-o nounset
An example would help. The above is supposed to create a global
readonly
variable. I suspect that you see the `global' as being `overridden'
because it's being created in a subshell environment.
Chet
It took me a second to reproduce it, but here it is:
--
#! /bin/bash
A()
{
typeset v1=Hello
B
echo "IN B:$v1"
}
B()
{
typeset -r v1=Goodbye
:
}
typeset -r v1=abc
A
echo "v1:$v1"
--
This is 4.0.35(1).
The v1 that's set to abc is the global one.
A defines a local copy that's not readonly and B defines one that is.
When I run it I get:
950 > ./foo.sh
./foo.sh: line 5: typeset: v1: readonly variable
./foo.sh: line 13: typeset: v1: readonly variable
IN B:abc
v1:abc
This means that the typeset failed is both A and B and the references
in the routines fell back to the global instance of v1.
Does this help?
I only see the problem in large complex cases, I've tried to reproduce a
simple example a couple of times but without success.
no its not a subshell problem, I avoid subshells as much as possible.
also when I expereimented with the problem a couple of times I
discovered the
following-
declare -g works
declare -gr doesn't work
my current workaround is I've just stopped using the readonly
attribute which
works. or just stopped using declare altogether.
or do something like this
var=x
typeset -r var
I've also seen some strange behavior with
declare in a conditional sourced global context. it only seems to
happen when
the code size is 1s+ lines long.
I think this is exasperated by the fact that i source my files inside
conditional statements. the result is that I now even in a global
context set
the global flag.
any ideas what could be causing it would help me try to figure out
how to test
for it.
Sorry about the weak description but I've been working around it now for
months waiting for it to make sense and I'm no closer to figuring out
whats
going on.
the problem is so erratic it has to be some sort of partial lost
context or
something.
can you give me any tips on how to debug it if I can reproduce it
again? is
their an easy way to track the validity of a variable?
I don't think it helps me but thanks for the try.
I would say zhats correct behavior. the code in the functions is only
executed when you call the functions. So the first executed readonly
variable is preserved.
Anyway my problem isn't with how readonly is preserved, its with how
when I set readonly the variable seems to have a limited context even if
I declare it explicitly global.
Re: inconsistency with "readonly" and scope
On 4/12/12 4:21 PM, dethrophes wrote: > I don't think it helps me but thanks for the try. > I would say zhats correct behavior. the code in the functions is only > executed when you call the functions. So the first executed readonly > variable is preserved. > Anyway my problem isn't with how readonly is preserved, its with how when I > set readonly the variable seems to have a limited context even if I declare > it explicitly global. Simple variables or associative arrays? If it's associative arrays with compound assignments, look at http://lists.gnu.org/archive/html/help-bash/2012-04/msg0.html -- ``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: inconsistency with "readonly" and scope
On 4/12/2012 4:21 PM, dethrophes wrote:
Am 12.04.2012 22:11, schrieb Steven W. Orr:
On 4/12/2012 2:16 PM, dethrophes wrote:
Am 12.04.2012 14:27, schrieb Chet Ramey:
On 4/11/12 4:12 PM, dethrophes wrote:
I've also noticed weird behavior with "declare -gr" the r sometimes seems
to override the g, but not specific to functions It seems to be specific
either to the source file or to the compound statement. I haven't been able
to figure out exactly whats going on there. I haven't been able to
reproduce it in a simple example. this is most readily noticeable with set
-o nounset
An example would help. The above is supposed to create a global readonly
variable. I suspect that you see the `global' as being `overridden'
because it's being created in a subshell environment.
Chet
It took me a second to reproduce it, but here it is:
--
#! /bin/bash
A()
{
typeset v1=Hello
B
echo "IN B:$v1"
}
B()
{
typeset -r v1=Goodbye
:
}
typeset -r v1=abc
A
echo "v1:$v1"
--
This is 4.0.35(1).
The v1 that's set to abc is the global one.
A defines a local copy that's not readonly and B defines one that is. When I
run it I get:
950 > ./foo.sh
./foo.sh: line 5: typeset: v1: readonly variable
./foo.sh: line 13: typeset: v1: readonly variable
IN B:abc
v1:abc
This means that the typeset failed is both A and B and the references in the
routines fell back to the global instance of v1.
Does this help?
I only see the problem in large complex cases, I've tried to reproduce a
simple example a couple of times but without success.
no its not a subshell problem, I avoid subshells as much as possible.
also when I expereimented with the problem a couple of times I discovered the
following-
declare -g works
declare -gr doesn't work
my current workaround is I've just stopped using the readonly attribute which
works. or just stopped using declare altogether.
or do something like this
var=x
typeset -r var
I've also seen some strange behavior with
declare in a conditional sourced global context. it only seems to happen when
the code size is 1s+ lines long.
I think this is exasperated by the fact that i source my files inside
conditional statements. the result is that I now even in a global context set
the global flag.
any ideas what could be causing it would help me try to figure out how to test
for it.
Sorry about the weak description but I've been working around it now for
months waiting for it to make sense and I'm no closer to figuring out whats
going on.
the problem is so erratic it has to be some sort of partial lost context or
something.
can you give me any tips on how to debug it if I can reproduce it again? is
their an easy way to track the validity of a variable?
I don't think it helps me but thanks for the try.
I would say zhats correct behavior. the code in the functions is only executed
when you call the functions. So the first executed readonly variable is
preserved.
Anyway my problem isn't with how readonly is preserved, its with how when I
set readonly the variable seems to have a limited context even if I declare it
explicitly global.
Ok, but do I have a point? I get your problem, but it seems like having a
global variable that is allowed to be reinstantiated in an inner (albeit
dynamic) scope should behave the same regardless of whether the global is
readonly. Inside A, I don't get why I can't create a new variable whose
failure (or success) depends on whether a previous outer scope variable exists
as readonly.
Note that if v1 at the global scope is not readonly, the one in A *is*
readonly, and the one in B is not, then there's no problem.
To me, this begs the question of whether all mainline code should be placed
into a containing 'main' function so as to prevent this problem from
occurring. Even if I do this, it still leaves me vulnerable to readonly
variables that are sourced in before main is defined.
[I hope that didn't come off as a rant. ;-)]
--
Time flies like the wind. Fruit flies like a banana. Stranger things have .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net
Re: inconsistency with "readonly" and scope
Am 12.04.2012 22:38, schrieb Steven W. Orr:
On 4/12/2012 4:21 PM, dethrophes wrote:
Am 12.04.2012 22:11, schrieb Steven W. Orr:
On 4/12/2012 2:16 PM, dethrophes wrote:
Am 12.04.2012 14:27, schrieb Chet Ramey:
On 4/11/12 4:12 PM, dethrophes wrote:
I've also noticed weird behavior with "declare -gr" the r
sometimes seems
to override the g, but not specific to functions It seems to be
specific
either to the source file or to the compound statement. I haven't
been able
to figure out exactly whats going on there. I haven't been able to
reproduce it in a simple example. this is most readily noticeable
with set
-o nounset
An example would help. The above is supposed to create a global
readonly
variable. I suspect that you see the `global' as being `overridden'
because it's being created in a subshell environment.
Chet
It took me a second to reproduce it, but here it is:
--
#! /bin/bash
A()
{
typeset v1=Hello
B
echo "IN B:$v1"
}
B()
{
typeset -r v1=Goodbye
:
}
typeset -r v1=abc
A
echo "v1:$v1"
--
This is 4.0.35(1).
The v1 that's set to abc is the global one.
A defines a local copy that's not readonly and B defines one that
is. When I
run it I get:
950 > ./foo.sh
./foo.sh: line 5: typeset: v1: readonly variable
./foo.sh: line 13: typeset: v1: readonly variable
IN B:abc
v1:abc
This means that the typeset failed is both A and B and the
references in the
routines fell back to the global instance of v1.
Does this help?
I only see the problem in large complex cases, I've tried to
reproduce a
simple example a couple of times but without success.
no its not a subshell problem, I avoid subshells as much as possible.
also when I expereimented with the problem a couple of times I
discovered the
following-
declare -g works
declare -gr doesn't work
my current workaround is I've just stopped using the readonly
attribute which
works. or just stopped using declare altogether.
or do something like this
var=x
typeset -r var
I've also seen some strange behavior with
declare in a conditional sourced global context. it only seems to
happen when
the code size is 1s+ lines long.
I think this is exasperated by the fact that i source my files inside
conditional statements. the result is that I now even in a global
context set
the global flag.
any ideas what could be causing it would help me try to figure out
how to test
for it.
Sorry about the weak description but I've been working around it
now for
months waiting for it to make sense and I'm no closer to figuring
out whats
going on.
the problem is so erratic it has to be some sort of partial lost
context or
something.
can you give me any tips on how to debug it if I can reproduce it
again? is
their an easy way to track the validity of a variable?
I don't think it helps me but thanks for the try.
I would say zhats correct behavior. the code in the functions is only
executed
when you call the functions. So the first executed readonly variable is
preserved.
Anyway my problem isn't with how readonly is preserved, its with how
when I
set readonly the variable seems to have a limited context even if I
declare it
explicitly global.
Ok, but do I have a point? I get your problem, but it seems like
having a global variable that is allowed to be reinstantiated in an
inner (albeit dynamic) scope should behave the same regardless of
whether the global is readonly. Inside A, I don't get why I can't
create a new variable whose failure (or success) depends on whether a
previous outer scope variable exists as readonly.
Note that if v1 at the global scope is not readonly, the one in A *is*
readonly, and the one in B is not, then there's no problem.
To me, this begs the question of whether all mainline code should be
placed into a containing 'main' function so as to prevent this problem
from occurring. Even if I do this, it still leaves me vulnerable to
readonly variables that are sourced in before main is defined.
[I hope that didn't come off as a rant. ;-)]
have you tried local?
I'm not sure if it'll make a difference.
I don't agree that typeset/declare should be able to override/redefine a
readonly variable it would defeat the purpose in a way.
however local arguably should allow you to do it.
Re: small fix for lib/sh/snprintf.c
On 4/12/12 12:25 PM, Petr Sumbera wrote:
> Hi,
>
> we are running Bash 3.2.38 on Solaris 10 where asprintf() isn't available.
> Thus code in snprintf.c is used.
>
> There is a problem with following command:
>
> bash -c 'printf "x%10.0fx\n" 123'
> x000123x
>
> Where correct output should be:
> x 123x
>
> It seems that '0' after '.' enables zero padding. Please see proposed patch
> bellow:
>
> --- bash-3.2.48/lib/sh/snprintf.c Tue Dec 12 12:10:18 2006
> +++ bash-3.2.48/lib/sh/snprintf.c Thu Apr 12 08:55:44 2012
> @@ -1277,6 +1277,8 @@
> data->flags |= PF_ALTFORM;
> continue;
> case '0':
> + if (data->flags & PF_DOT)
> + continue;
> data->flags |= PF_ZEROPAD;
> data->pad = '0';
> continue;
>
> The same code seems to be also in Bash 4.1 so I guess the problem is still
> there.
>
> Any comments?
Thanks for the report. Try this slightly improved patch; yours (and the
original code) doesn't treat a precision specifier beginning with a `0'
correctly. (And the test has to use `printf -v' to exercise the right
code in bash-4.0 and later.)
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/
*** ../bash-4.2-patched/lib/sh/snprintf.c 2010-05-30 18:34:52.0 -0400
--- lib/sh/snprintf.c 2012-04-12 20:12:56.0 -0400
***
*** 1296,1303
data->flags |= PF_ALTFORM;
continue;
- case '0':
- data->flags |= PF_ZEROPAD;
- data->pad = '0';
- continue;
case '*':
if (data->flags & PF_DOT)
--- 1289,1292
***
*** 1330,1333
--- 1319,1329
continue;
+ case '0':
+ if ((data->flags & PF_DOT) == 0)
+ {
+ data->flags |= PF_ZEROPAD;
+ data->pad = '0';
+ continue;
+ }
case '1': case '2': case '3':
case '4': case '5': case '6':
Re: inconsistency with "readonly" and scope
On 4/12/12 4:11 PM, Steven W. Orr wrote:
> It took me a second to reproduce it, but here it is:
>
> --
> #! /bin/bash
>
> A()
> {
> typeset v1=Hello
>
> B
> echo "IN B:$v1"
> }
>
> B()
> {
> typeset -r v1=Goodbye
>
> :
> }
> typeset -r v1=abc
> A
> echo "v1:$v1"
> --
>
> This is 4.0.35(1).
>
> The v1 that's set to abc is the global one.
> A defines a local copy that's not readonly and B defines one that is. When
> I run it I get:
>
> 950 > ./foo.sh
> ./foo.sh: line 5: typeset: v1: readonly variable
> ./foo.sh: line 13: typeset: v1: readonly variable
> IN B:abc
> v1:abc
>
> This means that the typeset failed is both A and B and the references in
> the routines fell back to the global instance of v1.
This is intended. Bash doesn't allow a local copy of a variable to
override a readonly global one. This can be a potential security hole,
especially if the readonly variable is exported, assuming that the
person/script/agent that set the variable readonly really didn't intend
for it to be modified for a reason.
However, the code allows a local variable to override a different
function's readonly local variable with the reasoning that the security
hole is not as great. If you don't like the global behavior, you can work
around it by having a function declare all your variables as local and
relying on dynamic scoping to treat them as essentially global.
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: inconsistency with "readonly" and scope
On 4/12/12 4:43 PM, dethrophes wrote: > have you tried local? > I'm not sure if it'll make a difference. It won't. > I don't agree that typeset/declare should be able to override/redefine a > readonly variable it would defeat the purpose in a way. I described the (hybrid/compromise) bash behavior in the previous message. 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/
