Chet Ramey <[EMAIL PROTECTED]> wrote:
> I am considering manipulating the `environ' variable when bash's list
> of exported variables changes. That might be enough to make the libc
> getenv() work.
I can't quite tell what's going on in lib/sh/getenv.c, but could you
(if you don't already) use lib
Julian Mehnle wrote:
> Chet Ramey wrote:
>
>>Julian Mehnle wrote:
>>
>Description:
>The history timestamping feature of Bash 3.0 does not respect the
>TZ (timezone) environment variable. It erroneously always uses the
>system clock's configured timezone.
>>
>>[...]
>>
>>Do you und
Chet Ramey wrote:
> Julian Mehnle wrote:
> > > > Description:
> > > > The history timestamping feature of Bash 3.0 does not respect the
> > > > TZ (timezone) environment variable. It erroneously always uses the
> > > > system clock's configured timezone.
> [...]
>
> Do you understand that strftime
Julian Mehnle wrote:
> Chet Ramey wrote:
>
>>Julian Mehnle wrote:
>>
>>>Description:
>>>The history timestamping feature of Bash 3.0 does not respect the TZ
>>>(timezone) environment variable. It erroneously always uses the
>>>system clock's configured timezone.
>>
>>Since it calls strftime(3) to
Chet Ramey wrote:
> Julian Mehnle wrote:
> > Description:
> > The history timestamping feature of Bash 3.0 does not respect the TZ
> > (timezone) environment variable. It erroneously always uses the
> > system clock's configured timezone.
>
> Since it calls strftime(3) to do the formatting, it use
Julian Mehnle wrote:
> Description:
> The history timestamping feature of Bash 3.0 does not respect the TZ
> (timezone) environment variable. It erroneously always uses the system
> clock's configured timezone.
Since it calls strftime(3) to do the formatting, it uses whatever
strftime uses. The
