Hello,
the formal POSIX shell grammar for yacc symbol "simple_command" accepts
commands which can be loosely summarized as:
three parts, each optional, in order:
variable assignments and redirections mixed togethercommand namecommand
arguments and redirections mixed together
It seems to me, the
|http://austingroupbugs.net/view.php?id=1008
| (0003335) geoffclare (manager) - 2016-08-11 15:23
| http://austingroupbugs.net/view.php?id=1008#c3335
|--
|http://austingroupbugs.net/view.php?id=1008#c3326 was edited during
On 2016-08-12 13:16:09 +1000, Bruce Evans wrote:
> On Thu, 11 Aug 2016, Austin Group Bug Tracker wrote:
> > --
> > (0003344) Vincent Lefevre (reporter) - 2016-08-11 20:41
> > http://austingroupbugs.net/view.php?id=1066#c3344
> > --
Mark Galeck wrote, on 12 Aug 2016:
>
> the formal POSIX shell grammar for yacc symbol "simple_command" accepts
> commands which can be loosely summarized as:
> three parts, each optional, in order:
> variable assignments and redirections mixed together
> command name
> command arguments and redir
Thank you! Robert Elz also already explained the whole thing.
In fact, I myself decided it would be better to put output redirections first -
the reason being, that is what happens at the system level, even before the
command is execve'd, even before that the output file(s) are opened for
writi
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.18//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:STANDARD
DTSTART:20161106T02
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
END:STANDARD
BE
Bruce Evans wrote:
> The behaviour is undefined if the year is < 1970 or the value [of a
> time_t] is negative. Thus there are no POSIX applications that
> deal with dates before 25 Nov 1932, and breaking the non-POSIX ones
> that do is not a problem for POSIX.
This is a missinterpretation, not
Vincent Lefevre wrote:
> Note that we were talking about binary compatibility, not just
> POSIX conformance. The behavior is undefined *by POSIX*. But an
> implementation may define the behavior with negative time_t. In
> such a case, the binary compatibility would be broken by a change
> of beha
All
These are the minutes from this weeks call. I have also posted the previous 2
weeks minutes to the document register
The next call is next week
regards
Andrew
Minutes of the 11th August 2016 Teleconference Austin-776 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 12
Joerg Schilling wrote, on 12 Aug 2016:
>
> Bruce Evans wrote:
>
> > The behaviour is undefined if the year is < 1970 or the value [of a
> > time_t] is negative. Thus there are no POSIX applications that
> > deal with dates before 25 Nov 1932, and breaking the non-POSIX ones
> > that do is not a
Joerg Schilling wrote, on 12 Aug 2016:
>
> Geoff Clare wrote:
>
> > > This is a missinterpretation, note that POSIX requires that Jan 1 1970
> > > 00:00
> > > work in any timenoze of the world.
> > >
> > > As a result, negative time_t vaules are required.
> >
> > Please point to the parts of t
Geoff Clare wrote:
> > This is a missinterpretation, note that POSIX requires that Jan 1 1970 00:00
> > work in any timenoze of the world.
> >
> > As a result, negative time_t vaules are required.
>
> Please point to the parts of the standard that you believe require this.
> If there really are
Geoff Clare wrote:
> > There is e.g. some text in the standard for sccs related programs.
>
> There is no requirement that the SCCS utilities are implemented in C,
> and if they are implemented in C there is no requirement that they
> use the time_t type internally.
SCCS is implemented in C sinc
As epoch is defined relative to UTC/GMT, he has a partial point that Jan 1,
1970 00:00 on the International Date Line would need negative 12*3600 seconds
to represent it as the "actual time of day" of XBD 4.15, if midnight GMT
assigned as (time_t) 0. To keep all values positive would mean midni
Shware Systems wrote:
>
> As epoch is defined relative to UTC/GMT, he has a partial point that Jan 1,
> 1970 00:00 on the International Date Line would need negative 12*3600 seconds
> to represent it as the "actual time of day" of XBD 4.15, if midnight GMT
> assigned as (time_t) 0. To keep all
Joerg Schilling wrote:
> Shware Systems wrote:
>
> >
> > As epoch is defined relative to UTC/GMT, he has a partial point that Jan 1,
> > 1970 00:00 on the International Date Line would need negative 12*3600
> > seconds to represent it as the "actual time of day" of XBD 4.15, if
> > midnight G
Joerg Schilling wrote, on 12 Aug 2016:
>
> Geoff Clare wrote:
>
> > > There is e.g. some text in the standard for sccs related programs.
> >
> > There is no requirement that the SCCS utilities are implemented in C,
> > and if they are implemented in C there is no requirement that they
> > use th
17 matches
Mail list logo
