[1003.1(2016)/Issue7+TC2 0001253]: clarify that "alternative time" means tm_isdst is positive
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1253 == Reported By:eggert Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1253 Category: Base Definitions and Headers Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Paul Eggert Organization: UCLA User Reference: https://mm.icann.org/pipermail/tz/2019-June/028043.html Section:8.3 Other Environment Variables - TZ Page Number:approximately 180 (sorry, don't have PDF) Line Number:approximately 5950 (sorry, don't have PDF) Interp Status: --- Final Accepted Text: == Date Submitted: 2019-06-03 16:36 UTC Last Modified: 2019-07-01 19:53 UTC == Summary:clarify that "alternative time" means tm_isdst is positive == Relationships ID Summary -- related to 0001252 Extend TZ to allow times outside 00-24 ... == -- (0004460) shware_systems (reporter) - 2019-07-01 19:53 http://austingroupbugs.net/view.php?id=1253#c4460 -- Alternative time is more accurate, technically, for the intent of the standard but to me is better termed as legislated time to distinguish it from alternative representation. The reason Daylight Saving is a misnomer is it is specific to how the US defines the procedure for changing clock settings and it doesn't take into account some region may decide they want to use something besides an hour forward to adjust the clock when the period begins. For the Irish case, given the mathematics are the same, it doesn't matter that the statute calls STD time "winter time". This is more a matter of setting the TZ variable to reflect that's how they prefer to call it, e.g. IWT-1IST instead of something like IST-1IDT to match how the standard calls it; where I=Irish, W=Winter, S=Standard, D=Daylight, and T=Time for the acronyms, and matching on these to determine if tm_isdst should be zero, for winter time, or positive. If anything the text could be more explicit that when tm_isdst is zero this refers to applying the offset from UTC using the value appropriate to the STD field, as expected to reflect contiguous seconds since the epoch at that point on the globe as solar time, with DST reflecting that there may be a missing or extra hour (or other period) in that contiguity due to a region adopting savings time of some type for the start and stop time of year provided. Whatever the difference in solar time was to local solar midnight when s-s-t-e was zero is effectively their standard time, for purposes of applying it to the TZ variable as a difference from UTC 12:00AM as the epoch's solar midnight, however it's referred to in other documents. This allows regions below the equator to define their legislated time as a period straddling day zero of a year, as their summer season begins with the December solstice, without conflicting with outside that period they go back to observing solar time. Issue History Date ModifiedUsername FieldChange == 2019-06-03 16:36 eggert New Issue 2019-06-03 16:36 eggert Name => Paul Eggert 2019-06-03 16:36 eggert Organization => UCLA 2019-06-03 16:36 eggert User Reference=> https://mm.icann.org/pipermail/tz/2019-June/028043.html 2019-06-03 16:36 eggert Section => 8.3 Other Environment Variables - TZ 2019-06-03 16:36 eggert Page Number => approximately 180 (sorry, don't have PDF) 2019-06-03 16:36 eggert Line Number => approximately 5950 (sorry, don't have PDF) 2019-06-03 18:13 Guy Harris Note Added: 0004403 2019-06-03 18:14 Guy Harris Note Added: 0004404 2019-06-03 18:15 Guy Harris Note Edited: 0004403 2019-06-03 18:15 Guy
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
On 01/07/2019 10:36, Geoff Clare wrote:
Harald van Dijk wrote, on 30 Jun 2019:
On 28/06/2019 09:38, Geoff Clare wrote:
Harald van Dijk wrote, on 27 Jun 2019:
On 27/06/2019 10:04, Geoff Clare wrote:
In particular, XRAT's explanation of it is "Conforming applications
are required to quote or escape the shell special characters
(sometimes called metacharacters). If used without this protection,
syntax errors can result or implementation extensions can be triggered."
The fact that this mentions syntax errors implies that the statement
in 2.13.1 was intended only to apply to patterns that are used directly
in shell commands.
Syntax errors are not limited to shell syntax errors.
I would think this means
find . -name '('
is allowed to immediately exit with
find: error: invalid pattern
If you interpret the standard as allowing find to treat that as an invalid
pattern, the error is allowed behaviour courtesy of XCU 1.4 CONSEQUENCES
OF ERRORS, but it's not a syntax error. So the fact that XRAT specifically
talks about syntax errors is an indication that there was no intention to
allow find to treat '(' as an invalid pattern.
Syntax is not just shell syntax. In this hypothetical find
implementation, it can be an error in the syntax of the command, or an
error in the syntax of patterns, depending on whether find first
determines that -name needs a pattern, commits to parsing a pattern, and
reports the failure, or whether it first determines that '(' cannot be a
pattern, then determines that -name needs a pattern, and reports that.
POSIX does not even limit the concept of "syntax errors" to errors in the
syntax, see e.g. the "shift" command:
If the n operand is invalid or is greater than "$#", this may be considered a
syntax error and a non-interactive shell may exit; [...]
The point of this text is to allow something that would not normally
be considered to be a syntax error to be handled as if it was one.
Although it words it by saying "may be considered" rather than "may be
treated as if it was", this is clearly an explicit exception to the
usual rule of what constitutes a syntax error.
It is utterly pointless. The only difference in handling of syntax
errors, per 2.8.1 Consequences of Shell Errors, is that the handling of
"Shell language syntax error" requires a shell diagnostic message, but
the handling of "Special built-in utility error", whether utility syntax
error or otherwise, does not. Clearly, this does not constitute a shell
language syntax error and no shell diagnostic message is required
(although a utility diagnostic message should be printed), and other
than that, it is irrelevant whether the error is considered a syntax
error. Given that it is then called a syntax error anyway, the only
conclusion I can draw from that is that the people responsible for this
wording do not care to limit syntax errors to errors in the syntax.
There's another example in the trap command description:
If the trap name [XSI] [Option Start] or number [Option End] is invalid, a
non-zero exit status shall be returned; otherwise, zero shall be returned. For
both interactive and non-interactive shells, invalid signal names [XSI] [Option
Start] or numbers [Option End] shall not be considered a syntax error and do
not cause the shell to abort.
If these would already not be considered syntax errors by the mere fact
that they are not errors in the syntax, there would be no need for
explicit language that they must not be considered syntax errors.
Less important, under the current wording, backslash escapes the next
character, it does not quote it. The requirements of quoting and escaping
are the same, so perhaps it is okay to change the terminology.
Escaping is a form of quoting. There are numerous places where the
standard uses "unquoted" to mean that a character is neither quoted
with single- or double-quotes nor escaped with a backslash.
Escaping can be a form of quoting, sure. 2.2.1 Escape Character (Backslash)
is part of 2.2 Quoting, after all. Not all escaping is quoting though. I
went over all uses of the word "unquoted" in Shell Command Language. Every
single one refers to shell quoting, and in the few cases where other levels
of backslash removal also apply, the standard does not refer to that as
quoting.
The current text in 2.13.1 and .3 uses "unquoted" in both senses:
L76212: "A character shall escape the following character."
L76222: "When unquoted and outside a bracket expression, the following
three characters shall have special meaning ..."
L76235: "special characters can be escaped to remove their special
meaning by preceding them with a character."
L76288: "it is unspecified whether other unquoted pattern matching
characters within the same slash-delimited component of the pattern
retain their special meanings..."
Obviously those two uses of "unquoted" are intended to include the
escaping described on L76212 and L76235, not
[1003.1(2016)/Issue7+TC2 0001251]: ex(1): formatting issues in command arguments
The following issue has been RESOLVED. == http://austingroupbugs.net/view.php?id=1251 == Reported By:mohd_akram Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1251 Category: Shell and Utilities Type: Error Severity: Editorial Priority: normal Status: Resolved Name: Mohamed Akram Organization: User Reference: Section:ex Page Number:2713-2733 Line Number:88687-89455 Interp Status: --- Final Accepted Text:http://austingroupbugs.net/view.php?id=1251#c4457 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2019-05-16 22:29 UTC Last Modified: 2019-07-01 15:58 UTC == Summary:ex(1): formatting issues in command arguments == Issue History Date ModifiedUsername FieldChange == 2019-05-16 22:29 mohd_akram New Issue 2019-05-16 22:29 mohd_akram Name => Mohamed Akram 2019-05-16 22:29 mohd_akram Section => ex 2019-05-16 22:29 mohd_akram Page Number => 2713-2733 2019-05-16 22:29 mohd_akram Line Number => 88687-89455 2019-05-17 11:06 geoffclare Note Added: 0004399 2019-06-20 13:51 mohd_akram Issue Monitored: mohd_akram 2019-06-28 11:04 geoffclare Note Added: 0004457 2019-07-01 15:57 geoffclare Note Edited: 0004457 2019-07-01 15:58 geoffclare Interp Status => --- 2019-07-01 15:58 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1251#c4457 2019-07-01 15:58 geoffclare Status New => Resolved 2019-07-01 15:58 geoffclare Resolution Open => Accepted As Marked ==
Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash doesn't have two meaning wrt pattern matching
Harald van Dijk wrote, on 30 Jun 2019:
>
> On 28/06/2019 09:38, Geoff Clare wrote:
> >Harald van Dijk wrote, on 27 Jun 2019:
> >>
> >>On 27/06/2019 10:04, Geoff Clare wrote:
> >
> >In particular, XRAT's explanation of it is "Conforming applications
> >are required to quote or escape the shell special characters
> >(sometimes called metacharacters). If used without this protection,
> >syntax errors can result or implementation extensions can be triggered."
> >The fact that this mentions syntax errors implies that the statement
> >in 2.13.1 was intended only to apply to patterns that are used directly
> >in shell commands.
>
> Syntax errors are not limited to shell syntax errors.
>
> I would think this means
>
> find . -name '('
>
> is allowed to immediately exit with
>
> find: error: invalid pattern
If you interpret the standard as allowing find to treat that as an invalid
pattern, the error is allowed behaviour courtesy of XCU 1.4 CONSEQUENCES
OF ERRORS, but it's not a syntax error. So the fact that XRAT specifically
talks about syntax errors is an indication that there was no intention to
allow find to treat '(' as an invalid pattern.
> POSIX does not even limit the concept of "syntax errors" to errors in the
> syntax, see e.g. the "shift" command:
>
> >If the n operand is invalid or is greater than "$#", this may be considered
> >a syntax error and a non-interactive shell may exit; [...]
>
The point of this text is to allow something that would not normally
be considered to be a syntax error to be handled as if it was one.
Although it words it by saying "may be considered" rather than "may be
treated as if it was", this is clearly an explicit exception to the
usual rule of what constitutes a syntax error.
> >>Less important, under the current wording, backslash escapes the next
> >>character, it does not quote it. The requirements of quoting and escaping
> >>are the same, so perhaps it is okay to change the terminology.
> >
> >Escaping is a form of quoting. There are numerous places where the
> >standard uses "unquoted" to mean that a character is neither quoted
> >with single- or double-quotes nor escaped with a backslash.
>
> Escaping can be a form of quoting, sure. 2.2.1 Escape Character (Backslash)
> is part of 2.2 Quoting, after all. Not all escaping is quoting though. I
> went over all uses of the word "unquoted" in Shell Command Language. Every
> single one refers to shell quoting, and in the few cases where other levels
> of backslash removal also apply, the standard does not refer to that as
> quoting.
The current text in 2.13.1 and .3 uses "unquoted" in both senses:
L76212: "A character shall escape the following character."
L76222: "When unquoted and outside a bracket expression, the following
three characters shall have special meaning ..."
L76235: "special characters can be escaped to remove their special
meaning by preceding them with a character."
L76288: "it is unspecified whether other unquoted pattern matching
characters within the same slash-delimited component of the pattern
retain their special meanings..."
Obviously those two uses of "unquoted" are intended to include the
escaping described on L76212 and L76235, not just shell
quoting.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
