Re: Odd DST Problem (solved)
"Richard" <aapex@att.net> wrote in message
news:d1zJh.143854$5j1.680@bgtnsc04-news.ops.worldnet.att.net...[color=blue]
> On a re-booted 5.0.5 with /etc/TIMEZONE TZ set to
> 'CST6CDT5,M3.2.0/2:00:00,M11.1.0/2:00:00' everything is fine *except* when
> running a shell command from within Foxbase. Then, within the child
> process running the command, the Unix time reverts to CST. I've confirmed
> that the correct TZ environment variable is exported to the child process,
> which is spawned as 'sh -c command'. Spawning a similar child process
> from another script works properly, so the problem only occurs when run
> from within Foxbase.
>
> Possible clue: on a fully patched 5.0.7 system, the same shell command
> from within Foxbase works properly, with the correct time *except* if the
> TZ variable is set to override the default DST values (i.e., set the same
> as the 5.0.5 system). Then, the same problem appears, with the time
> reverting to CST in the child process when run from within Foxbase.
>
> Any ideas on what is happening, and how it might be corrected?
>
> --
> Richard Seeder
>
>[/color]
Well, I was wrong that the correct TZ variable was exported (*slaps the
forehead*). Didn't notice it before, but Foxbase takes the TZ variable and
converts it to Xenix format by replacing the first comma with a semicolon
before re-exporting it prior to executing a shell command. The date
function then does not recognize the format and reverts to the default!
Re: Odd DST Problem (solved)
Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
| "Richard" <aapex@att.net> wrote in message
| news:d1zJh.143854$5j1.680@bgtnsc04-news.ops.worldnet.att.net...
| > On a re-booted 5.0.5 with /etc/TIMEZONE TZ set to
| > 'CST6CDT5,M3.2.0/2:00:00,M11.1.0/2:00:00' everything is fine *except* when
| > running a shell command from within Foxbase. Then, within the child
| > process running the command, the Unix time reverts to CST. I've confirmed
| > that the correct TZ environment variable is exported to the child process,
| > which is spawned as 'sh -c command'. Spawning a similar child process
| > from another script works properly, so the problem only occurs when run
| > from within Foxbase.
| >
| > Possible clue: on a fully patched 5.0.7 system, the same shell command
| > from within Foxbase works properly, with the correct time *except* if the
| > TZ variable is set to override the default DST values (i.e., set the same
| > as the 5.0.5 system). Then, the same problem appears, with the time
| > reverting to CST in the child process when run from within Foxbase.
| >
| > Any ideas on what is happening, and how it might be corrected?
|
| Well, I was wrong that the correct TZ variable was exported (*slaps the
| forehead*). Didn't notice it before, but Foxbase takes the TZ variable and
| converts it to Xenix format by replacing the first comma with a semicolon
| before re-exporting it prior to executing a shell command. The date
| function then does not recognize the format and reverts to the default!
What is "Xenix format"?
Why in the world should Foxbase convert an environment variable?
--
JP
==> [url]http://www.frappr.com/cusm[/url] <==
Re: Odd DST Problem (solved)
"Jean-Pierre Radley" <jpr@jpr.com> wrote in message
news:20070316230448.GA24391@jpradley.jpr.com...[color=blue]
> Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
> | "Richard" <aapex@att.net> wrote in message
> | news:d1zJh.143854$5j1.680@bgtnsc04-news.ops.worldnet.att.net...
> | > On a re-booted 5.0.5 with /etc/TIMEZONE TZ set to
> | > 'CST6CDT5,M3.2.0/2:00:00,M11.1.0/2:00:00' everything is fine *except*
> when
> | > running a shell command from within Foxbase. Then, within the child
> | > process running the command, the Unix time reverts to CST. I've
> confirmed
> | > that the correct TZ environment variable is exported to the child
> process,
> | > which is spawned as 'sh -c command'. Spawning a similar child process
> | > from another script works properly, so the problem only occurs when
> run
> | > from within Foxbase.
> | >
> | > Possible clue: on a fully patched 5.0.7 system, the same shell command
> | > from within Foxbase works properly, with the correct time *except* if
> the
> | > TZ variable is set to override the default DST values (i.e., set the
> same
> | > as the 5.0.5 system). Then, the same problem appears, with the time
> | > reverting to CST in the child process when run from within Foxbase.
> | >
> | > Any ideas on what is happening, and how it might be corrected?
> |
> | Well, I was wrong that the correct TZ variable was exported (*slaps the
> | forehead*). Didn't notice it before, but Foxbase takes the TZ variable
> and
> | converts it to Xenix format by replacing the first comma with a
> semicolon
> | before re-exporting it prior to executing a shell command. The date
> | function then does not recognize the format and reverts to the default!
>
> What is "Xenix format"?
>
> Why in the world should Foxbase convert an environment variable?
>
> --
> JP
> ==> [url]http://www.frappr.com/cusm[/url] <==[/color]
Hi, JP,
man environ and damned if I know.
--
Richard
Re: Odd DST Problem (solved)
Richard wrote:[color=blue]
>
> "Jean-Pierre Radley" <jpr@jpr.com> wrote in message
> news:20070316230448.GA24391@jpradley.jpr.com...[color=green]
> > Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
> > | "Richard" <aapex@att.net> wrote in message
> > | news:d1zJh.143854$5j1.680@bgtnsc04-news.ops.worldnet.att.net...
> > | > On a re-booted 5.0.5 with /etc/TIMEZONE TZ set to
> > | > 'CST6CDT5,M3.2.0/2:00:00,M11.1.0/2:00:00' everything is fine *except*
> > when
> > | > running a shell command from within Foxbase. Then, within the child
> > | > process running the command, the Unix time reverts to CST. I've
> > confirmed
> > | > that the correct TZ environment variable is exported to the child
> > process,
> > | > which is spawned as 'sh -c command'. Spawning a similar child process
> > | > from another script works properly, so the problem only occurs when
> > run
> > | > from within Foxbase.
> > | >
> > | > Possible clue: on a fully patched 5.0.7 system, the same shell command
> > | > from within Foxbase works properly, with the correct time *except* if
> > the
> > | > TZ variable is set to override the default DST values (i.e., set the
> > same
> > | > as the 5.0.5 system). Then, the same problem appears, with the time
> > | > reverting to CST in the child process when run from within Foxbase.
> > | >
> > | > Any ideas on what is happening, and how it might be corrected?
> > |
> > | Well, I was wrong that the correct TZ variable was exported (*slaps the
> > | forehead*). Didn't notice it before, but Foxbase takes the TZ variable
> > and
> > | converts it to Xenix format by replacing the first comma with a
> > semicolon
> > | before re-exporting it prior to executing a shell command. The date
> > | function then does not recognize the format and reverts to the default!
> >
> > What is "Xenix format"?
> >
> > Why in the world should Foxbase convert an environment variable?
> >
> > --
> > JP
> > ==> [url]http://www.frappr.com/cusm[/url] <==[/color]
>
> Hi, JP,
>
> man environ and damned if I know.
>
> --
> Richard[/color]
Richard,
What fix have you developed to overcome this problem?
As a guess, I would add an explicit line in the called shell script
that reads the TZ value from /etc/TIMEZONE to overwrite the FoxBASE
exported value.
Re: Odd DST Problem (solved)
"Steve M. Fabac, Jr." <smfabac@att.net> wrote in message
news:46014B54.6FF1A9A@att.net...[color=blue]
> Richard wrote:[color=green]
>>
>> "Jean-Pierre Radley" <jpr@jpr.com> wrote in message
>> news:20070316230448.GA24391@jpradley.jpr.com...[color=darkred]
>> > Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
>> > | "Richard" <aapex@att.net> wrote in message
>> > | news:d1zJh.143854$5j1.680@bgtnsc04-news.ops.worldnet.att.net...
>> > | > On a re-booted 5.0.5 with /etc/TIMEZONE TZ set to
>> > | > 'CST6CDT5,M3.2.0/2:00:00,M11.1.0/2:00:00' everything is fine
>> > *except*
>> > when
>> > | > running a shell command from within Foxbase. Then, within the
>> > child
>> > | > process running the command, the Unix time reverts to CST. I've
>> > confirmed
>> > | > that the correct TZ environment variable is exported to the child
>> > process,
>> > | > which is spawned as 'sh -c command'. Spawning a similar child
>> > process
>> > | > from another script works properly, so the problem only occurs when
>> > run
>> > | > from within Foxbase.
>> > | >
>> > | > Possible clue: on a fully patched 5.0.7 system, the same shell
>> > command
>> > | > from within Foxbase works properly, with the correct time *except*
>> > if
>> > the
>> > | > TZ variable is set to override the default DST values (i.e., set
>> > the
>> > same
>> > | > as the 5.0.5 system). Then, the same problem appears, with the
>> > time
>> > | > reverting to CST in the child process when run from within Foxbase.
>> > | >
>> > | > Any ideas on what is happening, and how it might be corrected?
>> > |
>> > | Well, I was wrong that the correct TZ variable was exported (*slaps
>> > the
>> > | forehead*). Didn't notice it before, but Foxbase takes the TZ
>> > variable
>> > and
>> > | converts it to Xenix format by replacing the first comma with a
>> > semicolon
>> > | before re-exporting it prior to executing a shell command. The date
>> > | function then does not recognize the format and reverts to the
>> > default!
>> >
>> > What is "Xenix format"?
>> >
>> > Why in the world should Foxbase convert an environment variable?
>> >
>> > --
>> > JP
>> > ==> [url]http://www.frappr.com/cusm[/url] <==[/color]
>>
>> Hi, JP,
>>
>> man environ and damned if I know.
>>
>> --
>> Richard[/color]
>
> Richard,
>
> What fix have you developed to overcome this problem?
>
> As a guess, I would add an explicit line in the called shell script
> that reads the TZ value from /etc/TIMEZONE to overwrite the FoxBASE
> exported value.[/color]
Steve,
Yes, that's exactly what I did. I cannot find any indication in the
documentation of why it would change the TZ format.
--
Richard
Re: Odd DST Problem (solved)
In article <5ywMh.417$f56.2@bgtnsc05-news.ops.worldnet.att.net>,
Richard <aapex@att.net> wrote:[color=blue]
>"Steve M. Fabac, Jr." <smfabac@att.net> wrote in message
>news:46014B54.6FF1A9A@att.net...[color=green]
>> Richard,
>>
>> What fix have you developed to overcome this problem?
>>
>> As a guess, I would add an explicit line in the called shell script
>> that reads the TZ value from /etc/TIMEZONE to overwrite the FoxBASE
>> exported value.[/color]
>
>Steve,
>
>Yes, that's exactly what I did. I cannot find any indication in the
>documentation of why it would change the TZ format.[/color]
The exec system call converts the TZ value to XENIX format
when exec'ing a XENIX binary.
John
--
John DuBois [email]spcecdt@armory.com[/email] KC6QKZ/AE [url]http://www.armory.com/~spcecdt/[/url]
Re: Odd DST Problem (solved)
John DuBois wrote:
[color=blue]
> In article <5ywMh.417$f56.2@bgtnsc05-news.ops.worldnet.att.net>,
> Richard <aapex@att.net> wrote:[color=green]
> >"Steve M. Fabac, Jr." <smfabac@att.net> wrote in message
> >news:46014B54.6FF1A9A@att.net...[color=darkred]
> >> Richard,
> >>
> >> What fix have you developed to overcome this problem?
> >>
> >> As a guess, I would add an explicit line in the called shell script
> >> that reads the TZ value from /etc/TIMEZONE to overwrite the FoxBASE
> >> exported value.[/color]
> >
> >Steve,
> >
> >Yes, that's exactly what I did. I cannot find any indication in the
> >documentation of why it would change the TZ format.[/color]
>
> The exec system call converts the TZ value to XENIX format
> when exec'ing a XENIX binary.[/color]
Is that documented anywhere? (both the fact that it does; and what is
meant by "XENIX format" of a TZ value vs. OSR5's "modern" ancient
format?)
I vaguely remember when this was implemented...
Anyway, shouldn't the exec() system call from a XENIX binary, when
invoking a UNIX binary, mangle $TZ in the opposite direction?
[color=blue]
>Bela<[/color]
Re: Odd DST Problem (solved)
"Bela Lubkin" <filbo@armory.com> wrote in message
news:200703261557.aa22645@deepthought.armory.com...[color=blue]
> John DuBois wrote:
>[color=green]
>> In article <5ywMh.417$f56.2@bgtnsc05-news.ops.worldnet.att.net>,
>> Richard <aapex@att.net> wrote:[color=darkred]
>> >"Steve M. Fabac, Jr." <smfabac@att.net> wrote in message
>> >news:46014B54.6FF1A9A@att.net...
>> >> Richard,
>> >>
>> >> What fix have you developed to overcome this problem?
>> >>
>> >> As a guess, I would add an explicit line in the called shell script
>> >> that reads the TZ value from /etc/TIMEZONE to overwrite the FoxBASE
>> >> exported value.
>> >
>> >Steve,
>> >
>> >Yes, that's exactly what I did. I cannot find any indication in the
>> >documentation of why it would change the TZ format.[/color]
>>
>> The exec system call converts the TZ value to XENIX format
>> when exec'ing a XENIX binary.[/color]
>
> Is that documented anywhere? (both the fact that it does; and what is
> meant by "XENIX format" of a TZ value vs. OSR5's "modern" ancient
> format?)
>
> I vaguely remember when this was implemented...
>
> Anyway, shouldn't the exec() system call from a XENIX binary, when
> invoking a UNIX binary, mangle $TZ in the opposite direction?
>[color=green]
>>Bela<[/color][/color]
One would think so, but it doesn't. Displaying the TZ variable within the
called script shows the "XENIX" format, and running just the "date" binary
confirms the behavior. This, of course, was never a problem when TZ was in
the simple "CST5CDT" format. Software geriatrics certainly presents some
interesting problems.
--
Richard Seeder
