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
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 g
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 inte
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 pad
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 '
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 bee
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
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 seem
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 reado
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
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 "declar
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
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
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 behavi
14 matches
Mail list logo
