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 do the formatting, it uses whatever
>>strftime uses. There is the usual problem of exported shell
>>variables finding their way into the environment searched by the
>>C library functions. This is why bash attempts to provide a
>>replacement for getenv().
>
>
> I'm not sure I understand entirely what this means. Do you mean that the
> undesired behavior described by me above is being acknowledged as a
> deficiency of Bash? Can it be fixed without great efforts?
No, I don't.
Do you understand that strftime() performs the equivalent of getenv()
to discover the value of $TZ? And that bash's table of shell variables
is different from the list `environ' points to?
Unless a system allows bash to provide a replacement for getenv() that
looks in the table of shell variables, C library functions that rely on
environment variables will not see changes made at the shell level.
Bash provides such a function, but some C library implementations use
private interfaces rather than public ones (probably to avoid problems
caused by such replacement).
I'm not really interested in reimplementing the C library. If the
implementation of strftime() prevents bash from providing it the correct
value for $TZ, so be it.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )
Live...Laugh...Love
Chet Ramey, ITS, CWRU [EMAIL PROTECTED] http://tiswww.tis.case.edu/~chet/
_______________________________________________
Bug-bash mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-bash
