On Mar 13, 8:01 am, "Richard" wrote:
> 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

Isn't that Foxbase old Xenix code? The extended format for TZ was
introduced for the 1987 changes in daylight savings time. If memory
serves Xenix either was never updated to handle that or its TZ had
some other format.

Part of MP5 to 5.0.7 was some library changes incorporating the new
and historic TZ rules. So that's probably why it's working there in
the absence of an explicit TZ. No such patch was made for 5.0.5.

--RLR

"ThreeStar" wrote in message
news:1173802907.920672.158560@n33g2000cwc.googlegr oups.com...
> On Mar 13, 8:01 am, "Richard" wrote:
>> 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
>
> Isn't that Foxbase old Xenix code? The extended format for TZ was
> introduced for the 1987 changes in daylight savings time. If memory
> serves Xenix either was never updated to handle that or its TZ had
> some other format.
>
> Part of MP5 to 5.0.7 was some library changes incorporating the new
> and historic TZ rules. So that's probably why it's working there in
> the absence of an explicit TZ. No such patch was made for 5.0.5.
>
> --RLR
>

Doesn't explain why it does not work with the TZ change in 5.0.7. Remember,
this is a shell command that is being executed, not Foxbase code (in which,
the date functions work correctly).

"Richard" 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?
>
> --
> Richard Seeder
>
>

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!

Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
| "Richard" 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
==> http://www.frappr.com/cusm <==

"Jean-Pierre Radley" wrote in message
news:20070316230448.GA24391@jpradley.jpr.com...
> Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
> | "Richard" 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
> ==> http://www.frappr.com/cusm <==

Hi, JP,

man environ and damned if I know.

--
Richard

Richard wrote:
>
> "Jean-Pierre Radley" wrote in message
> news:20070316230448.GA24391@jpradley.jpr.com...
> > Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
> > | "Richard" 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
> > ==> http://www.frappr.com/cusm <==
>
> Hi, JP,
>
> man environ and damned if I know.
>
> --
> Richard

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 M. Fabac, Jr." wrote in message
news:46014B54.6FF1A9A@att.net...
> Richard wrote:
>>
>> "Jean-Pierre Radley" wrote in message
>> news:20070316230448.GA24391@jpradley.jpr.com...
>> > Richard typed (on Fri, Mar 16, 2007 at 09:27:35PM +0000):
>> > | "Richard" 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
>> > ==> http://www.frappr.com/cusm <==
>>
>> Hi, JP,
>>
>> man environ and damned if I know.
>>
>> --
>> Richard
>
> 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.

--
Richard

In article <5ywMh.417$f56.2@bgtnsc05-news.ops.worldnet.att.net>,
Richard wrote:
>"Steve M. Fabac, Jr." 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.

The exec system call converts the TZ value to XENIX format
when exec'ing a XENIX binary.

John
--
John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

John DuBois wrote:

> In article <5ywMh.417$f56.2@bgtnsc05-news.ops.worldnet.att.net>,
> Richard wrote:
> >"Steve M. Fabac, Jr." 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.
>
> The exec system call converts the TZ value to XENIX format
> when exec'ing a XENIX binary.

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?

>Bela<

"Bela Lubkin" wrote in message
news:200703261557.aa22645@deepthought.armory.com.. .
> John DuBois wrote:
>
>> In article <5ywMh.417$f56.2@bgtnsc05-news.ops.worldnet.att.net>,
>> Richard wrote:
>> >"Steve M. Fabac, Jr." 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.
>>
>> The exec system call converts the TZ value to XENIX format
>> when exec'ing a XENIX binary.
>
> 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?
>
>>Bela<

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