Re: [Issue 8 drafts 0001776]: find -newer any symlinks

[Don Cragun via austin-group-l at The Open Group]

Hi Stephane,
We missed the point you raised about the example when we resolved this issue 
during our 2023-11-20 conference call.  Since those changes have already been 
applied to Issue 8 draft 4 I will file a new bug to address this point in a 
later draft.

Thank you for pointing that we missed this.

Sincerely,
Don

> On Dec 14, 2023, at 10:54 AM, Stephane Chazelas via austin-group-l at The 
> Open Group  wrote:
> 
> 2023-11-20 17:30:32 +, Austin Group Bug Tracker via austin-group-l at The 
> Open Group:
> [...]
>> On page 2920 line 97596 section find (-newer), change:The
>> primary shall evaluate as true if the modification time of the current file
>> is more recent than the modification time of the file named by the pathname
>> file.to:The primary shall evaluate as true
>> if the modification time of the current file is more recent than the
>> modification time of the file named by the pathname file. If
>> file names a symbolic link, the modification time used shall be that
>> of the file referenced by the symbolic link if either the -H or
>> -L is specified; if neither -H nor -L is specified, it
>> is unspecified whether the modification time is that of the symbolic link
>> itself or of the file referenced by the symbolic link. In either case,  if
>> the referenced file does not exist, the modification time used shall be
>> that of the link itself. If file is a relative pathname, it shall be
>> resolved relative to the current working directory that was inherited by
>> find when it was invoked.
> [...]
> 
> Thanks, looks good.
> 
> What about the example:
> 
>> - fix the example at line 97747 to use -H, and maybe add a
>> "provided both file1 and file2 are accessible".
> 
> ?
> 
> -- 
> Stephane
> 

Re: pathnames with two leading slashes

[Don Cragun via austin-group-l at The Open Group]

Hi Cris,
Please find comments in-line below...

> On Jul 31, 2023, at 4:05 PM, Christoph Anton Mitterer via austin-group-l at 
> The Open Group  wrote:
> 
> Hey.
> 
> POSIX 4.13 Pathname Resolution says:
>> If a pathname begins with two successive  characters, the
>> first component following the leading  characters may be
>> interpreted in an implementation-defined manner, although more than
>> two leading  characters shall be treated as a single 
>> character.
> 
> I wondered what exactly this means.
> If the *first* component following the leading // is allowed to be
> interpreted in an implementation-defined manner, what would that mean
> for any remaining components? That they are not?
> 
> It doesn't seem to make too much sense to have the remaining components
> not in an implementation-defined manner if the first one already is, or
> does it?

On some systems when the initial POSIX standards were being created, a pathname 
that started with exactly two  characters was interpreted to be a 
specific directory on the server on the local network named by the first 
component.  On other systems, the leading // was treated exactly like / and 
just referred to the directory named named by the first component on the root 
directory on the local system.  After that directory (local or on the network) 
has been identified pathname resolution continues from that directory in the 
standard manner.  It is only the evaluation of the first component that is 
implementation-defined.

> 
> 
> Also, in POSIX a pathname component / filename cannot contain ,
> but would the above text mean that - since component may be interpreted
> in an implementation-defined manner - it could contain  and
> there was only one component at all?

No.  Each group of  characters separates components no matter what 
directory is identified by the first component.

> 
> And POSIX 3.271 Pathname says:
>> Multiple successive  characters are considered to be the same
>> as one , except for the case of exactly two leading 
>> characters. 
> 
> Would that only mean that the two leading es aren't collapsed
> into one, but any others are as in:
> ///foo///bar
> would be the same as:
> ///foo/bares.

Yes.

> 
> or would it mean that *no* collapsing takes place at all, that is the
> two pathnames from above would not be the same?

No.

> 
> Thanks
> Chris.
> 

Hope this helps,
Don

Re: [1003.1(2016/18)/Issue7+TC2 0001614]: XSH 3/mktime does not specify EINVAL and should

[Don Cragun via austin-group-l at The Open Group]

Robert & Geoff have been arguing about whether or not giving a struct tm to 
mktime() that specifies a time in the gap between standard time and daylight 
time is allowed to be treated as an error (assuming that the seconds since the 
Epoch would otherwise fit in a time_t).

Robert is arguing that if (after adjusting other fields to
bring them into the ranges specified in ) mktime()
should return an error if tm_hour has a value that does not
occur on days when the timezone shifts.  Geoff is arguing
that when tm_hour has a value that does not occur on those
days, mktime() is required to adjust tm_hour (and any other
fields that might need to be adjusted for cases where the
shift isn't 1 hour) to a value that does yield a struct tm
containing values that time() could return.

I agree with Geoff.

If we accept Robert's argument, then it isn't just gaps in time caused by a 
timezone shift that would be affected. As an example, if I call time() on 
January 30, 2023 at noon, it will return a struct tm with tm_mon set to 11 (it 
has a normal range of 0-11) and tm_mday set to 29 (it has a normal range of 
1-31).  If I then add 1 to tm_mon and call mktime() with the resulting struct 
tm, I'm asking mktime to give me back a struct tm for noon on February 29, 
2023. This date does not exist (since 2023 is not a leap year). However, both 
tm_mon and tm_mday are in the ranges specified by .  So, if Robert is 
being consistent, he is insisting that mktime() should return an error because 
there is no February 29 in 2023.  Fortunately all existing implementations of 
mktime() adjust tm_mon and tm_mday to noon on March 1, 2023 instead of 
returning an error.  I sincerely hope that none of us would want an error in 
this case.

The standard (200x draft 2.1 P1311, L43850-43870 says:
The mktime() function shall convert the broken-down
time, expressed as local time, in the structure
pointed to by timeptr, into a time since the Epoch
value with the same encoding as that of the values
returned by time(). The original values of the
tm_wday and tm_yday components of the structure shall
be ignored, and the original values of the other
components shall not be restricted to the ranges
described in .

A positive or 0 value for tm_isdst shall cause
mktime() to presume initially that Daylight Saving
Time, respectively, is or is not in effect for the
specified time. A negative value for tm_isdst shall
cause mktime() to attempt to determine whether
Daylight Saving Time is in effect for the specified
time.

Local timezone information shall be set as though
mktime() called tzset().

The relationship between the tm structure (defined in
the  header) and the time in seconds since
the Epoch is that the result shall be as specified in
the expression given in the definition of seconds
since the Epoch (see XBD Section 4.17, on page 95)
corrected for timezone and any seasonal time
adjustments, where the names other than tm_yday in
the structure and in the expression correspond, and
the tm_yday value used in the expression is the day
of the year from 0 to 365 inclusive, calculated from
the other tm structure members specified in 
(excluding tm_wday).

Upon successful completion, the values of the tm_wday
and tm_yday components of the structure shall be set
appropriately, and the other components shall be set
to represent the specified time since the Epoch, but
with their values forced to the ranges indicated in
the  entry; the final value of tm_mday shall
not be set until tm_mon and tm_year are determined.

I see nothing above that says that mktime() should just
adjust tm_mday to a valid day within the range 1-31 and give
an error if that day doesn't exist in the calculated month.
The mktime() function is required to return a struct tm
containing adjustments corresponding to a time that time()
could return.  I see no reason to believe that just because
tm_hour was initially set to 1 means that it is in any way
exempt from being adjusted to yield a tm_hour value (and a
tm_isdst value) that are valid whether or not there was a
timezone shift.

 - Don

Re: stty default output/-a _POSIX_VDISABLE character "undef", contrasts with "" on all known implementations? Formatting loss->overinterpretation since Issue 6.

[Don Cragun via austin-group-l at The Open Group]

Hi наб,
Thank you for your work on this issue.  It has been filed as Austin Group 
Defect Tracker issue #1604.  See https://austingroupbugs.net/view.php?id=1604

Cheers,
Don

> On Sep 10, 2022, at 5:09 AM, наб via austin-group-l at The Open Group 
>  wrote:
> 
> Hi!
> 
> Issue 7 and Issue 8 Draft 2.1 say this (XCU, stty, STDOUT, last para.):
>  If control characters are written as part of the default output, or if
>  the −a option is specified, control characters shall be written as:
>"%s = %s;", , 
>  where  is either the character, or some visual representation of
>  the character if it is non-printable, or the string undef if the
>  character is disabled.
> 
> undef is italicised, and matches the argument to character-valued
> attributes like kill. On first glance, this makes sense.
> 
> However, every BSD release on the CSRG CDs since 3BSD,
> SysIII, and SysVr{1,2,3,4} ‒ that is, every historical system /with/ a
> disabling functionality ‒ as well as modern BSD, Illumos,
> and the GNU system, render this as "".
> 
> This is very curious! /I/ was very curious, at least.
> 
> XPG3 stty (same as XPG2's) does not define the output format
> (stty's primary purpose isn't to generate text,
> so that fits with the XPG's "don't rely on this format" clause).
> 
> The XPG3-XPG4 migration guide lists some changes,
> but none of them relevant here.
> 
> POSIX.2 Draft 11.2 (the only one extant on the internet :/) says:
>  If control characters are written as part of the default output,
>  or if the −a option is
>  specified, control characters shall be written as:
>"%s = %s;", , 
>  where value is either the character, or some visual representation
>  of the character if it is nonprintable,
>  or the string  if the character is disabled.
> 
> And  is monospace here!
> This is "correct": it matches every implementation.
> 
> XPG4.2/SUSv1 in its change history cites
>  Aligned with the ISO/IEC 9945-2: 1993 standard.
> for Issue 4 amd says:
>  If control characters are written as part of the default output,
>  or if the −a option is specified,
>  control characters will be written as:
>"%s = %s;", <-character name>, 
>  where value is either the character,
>  or some visual representation of the character if it is non-printable,
>  or the string  if the character is disabled.
> 
> With  in normal font
> (this matches the formatting of its own control-character-argument table,
> which has ^- and undef in normal font as well).
> 
> SUSv2/Issue 5 matches SUSv2 (except for the ^- in the table).
> Its FUTURE DIRECTIONS says something about interpretations of P1003.2b,
> but in draft 12 of that I didn't see anything relevant to this.
> 
> SUSv3/Issue 6 is the first one that formats this in the problematic way
> described: both undef in the control-character-argument table and in the
> STDOUT section are no-<> and italic:
>  If control characters are written as part of the default output,
>  or if the -a option is specified,
>  control characters shall be written as:
>"%s = %s;", , 
>  where  is either the character, or some visual representation
>  of the character if it is non-printable, or the string undef if the
>  character is disabled.
> 
> The only diff items for Issue 6 seem to be removing legacy items and
> fixing the description of nl and -nl in XCU/TC1/D6/37.
> 
> I only checked the HTML version, but the formatting and wording are the
> same for Issue 7 (HTML) and Issue 8 Draft 2.1 (PDF).
> 
> My naive interpretation of this is that, after loss of monospacing from
> POSIX.2 to SUSv1, at some point in Issue 6's creation, "" was
> taken to mean literal undef, i.e. italic undef, which is wrong,
> but makes sense since use of <>s is very common to mean
> "enclosed literal" or "literal symbol".
> 
> The fix would be to simply change italic undef on line 108235 (D2.1)
> to monospace  or bold .
> 
> Best,
> наб
> 
> Note: idk how well this mail will render on the Open Group webmail
>  interface due to its heavy use of ;
>  I've been pestering the contact box to fix "injecting the literal
>  mail text as HTML" but this appears to be impossible.

Re: [1003.1(2016/18)/Issue7+TC2 0001546]: BREs: reserve \? \+ and \|

[Don Cragun via austin-group-l at The Open Group]

Hey Chris,
Note that the definition of "escape sequence" is being added in section 9.1 
(titled" Regular Expression Definitions") in the Base Definitions Volume of the 
standard; not in Section 3 where definitions go that pertain to the entire 
standard.

Cheers,
Don

> On Apr 7, 2022, at 4:05 PM, Christoph Anton Mitterer via austin-group-l at 
> The Open Group  wrote:
> 
> Hey.
> 
> btw: It should not be forgotten, that this definition of escape
> sequence/character, escaped character is in principle only valid for
> the RE chapter. Except of course, something explicitly refers to that
> or - like with sed - extends the RE language.
> 
> Just wanted to point that out again, to be kept in mind,... when the
> same terms are used in other places of the standard.
> 
> 
> Apart from that,... thanks Goff and Robert for your efforts in this
> issue.
> 
> 
> Cheers,
> Chris.
> 
> 

Re: wait and stopped jobs

[Don Cragun via austin-group-l at The Open Group]

> On Feb 28, 2022, at 3:20 PM, Robert Elz via austin-group-l at The Open Group 
>  wrote:
> 
>Date:Mon, 28 Feb 2022 16:12:03 -0500
>From:"Garrett Wollman via austin-group-l at The Open Group" 
> 
>Message-ID:  <25117.15011.846137.211...@khavrinen.csail.mit.edu>
> 
>  ... ... ...

> It is worth pointing out though that testing this in interactive shells
> is somewhat of a weird case - it should probably be done in a script
> instead.   That's because of the effect of the (implicit) jobs command
> before each PS1 output, that should have reported the background job as
> stopped when the Ctl-Z was sent, before the wait command is issued.  Normally
> each status change gets just one result from wait() - and the one from
> jobs counts (that's why in interactive shells there's no need, and no
> point since it doesn't work, issuing wait commands for known already completed
> background jobs ... they already no longer exist).   How all this interacts
> with stopped jobs and wait(1) (as distinct from waitpid(2) (or (3)) seems
> to be wholly unspecified - hence running these tests in a script, where
> there's no PS1 and hence no implicit jobs command is a much more reliable
> test methodology.

The requirement for the shell to keep the exit status for a known terminated 
process until wait is called is in section 2.9.3.1 of the shell command 
language (202x D2.1 P2338, L75542-75560):

2.9.3.1 Asynchronous Lists
If a command is terminated by the control operator  ('&'), the shell 
shall execute
the command asynchronously in a subshell. This means that the shell shall not 
wait for the
command to finish before executing the next command.

The format for running a command in the background is:
command1 & [command2 & ... ]

... ... ...

When an element of an asynchronous list (the portion of the list ended by an 
,
such as command1, above) is started by the shell, the process ID of the last 
command in the
asynchronous list element shall become known in the current shell execution 
environment; see
Section 2.12. This process ID shall remain known until:
1. The command terminates and the application waits for the process ID.
2. Another asynchronous list is invoked before "$!" (corresponding to the 
previous
asynchronous list) is expanded in the current execution environment.

The implementation need not retain more than the {CHILD_MAX} most recent 
entries in its list
of known process IDs in the current shell execution environment.

> 
> kre
> 

Re: [1003.1(2016/18)/Issue7+TC2 0001558]: require [^...] in addition to [!...] for bracket expression negation

[Don Cragun via austin-group-l at The Open Group]

Chris,
No, I hadn't.  Thanks for pointing it out.  The enhancement request has been 
reopened.

Cheers,
Don

> On Feb 17, 2022, at 8:28 PM, Christoph Anton Mitterer via austin-group-l at 
> The Open Group  wrote:
> 
> Don,
> 
> On Fri, 2022-02-18 at 04:04 +, Austin Group Bug Tracker via austin-
> group-l at The Open Group wrote:
>>  (0005678) Don Cragun (manager) - 2022-02-18 04:04
>>  https://www.austingroupbugs.net/view.php?id=1558#c5678 
>> -
>> - 
>> Withdrawn at the request of the submitter in
>> https://www.austingroupbugs.net/view.php?id=1558#c5677. 
> 
> You had seen, that mirabilos who commented in 0005677 was *not* the
> submitter?
> 
> 
> Cheers,
> Chris.
> 
> 

Re: [Issue 8 drafts 0001532]: "stty -g" output should not have to be split

[Don Cragun via austin-group-l at The Open Group]

Hi Wayne,
I don't see this being a real problem.  The current output of stty -g on the 
system I'm using is about 225 bytes.  The minimum acceptable value for LINE_MAX 
in the current standard is 2048 (including the terminating  
character).  I'm not expecting terminal settings to need an additional 1800 
bytes to be represented in text form in the foreseeable future.

- Don

> On Feb 11, 2022, at 7:43 PM, Wayne Pollock via austin-group-l at The Open 
> Group  wrote:
> 
> This is probably a silly question, but how long can the output of stty -g be?
> Because as worded ("line of text") the output would be limited to less than
> LINE_MAX.  If that might be an issue the wording could be changed to something
> like "string of characters terminated by a newline".
> 
> -- 
> Wayne Pollock
> 
> On Thu, Feb 3, 2022, 2:06 PM Austin Group Bug Tracker via austin-group-l at 
> The Open Group  > wrote:
> 
> >
> 

Re: sed and delimiters that are also special characters to REs

[Don Cragun via austin-group-l at The Open Group]

> On Jan 13, 2022, at 10:07 PM, Oğuz via austin-group-l at The Open Group 
>  wrote:
> 
> On Thu, Jan 13, 2022 at 6:36 PM Christoph Anton Mitterer
>  wrote:
>> And where does it say that? I mean in the standard.
>> I.e. where does it say, that parsing is only allowed to happen in one
>> stage from left to right, especially not only with respect to an RE
>> itself, but also when an RE is embedded in a command with delimiters.
> 
> It is what makes sense.
> 
>> 
>> Where does it say, whether:
>> s.[.].X.
>> is:
>> a) s/[/]/
>>   followed by X.
>> 
>> or:
>> 
>> b) s/[.]/X/
> 
> It is clearly `a'. The second period is not preceded by a backslash.

It isn't that simple.  The string between the first and second delimiters in a 
substitute command has to be an RE (and "[" can't be the end of an RE; it is 
the start of a bracket expression).  Note also that  is not special 
inside a bracket expression.  When you find the first delimiter, you can't look 
for the second delimiter in the middle of a bracket expression and you can't 
look for the second delimiter in the middle of a subexpression ("\("..."\)").

> 
>> Then, with a delimiter that is also a special character, the special
>> character would no longer be usable as such.
> 
> Again, that's why any character other than backslash and newline can
> be used as the delimiter. The standard makes an exception for when the
> special sequence `\n' is used with the `y' command, but that's all.
> The point of custom delimiters is to save users from the escaping
> hell. I don't think anyone put further thought into it.
> 
>> btw: busybox sed, behaves as you say:
>> $ printf '%s\n' '.' | busybox sed 's.\..X.'
>> X
>> $ printf '%s\n' 'a' | busybox sed 's.\..X.'
>> a
> 
> So do Solaris sed and Unixware sed. On the other hand, all seds I tested do 
> this
> 
>$ echo a | sed 's1(.)1\11'
>a
> 
> except GNU sed; it prints 1 instead. The behavior varies widely with
> other special characters and sequences, so the best standard
> developers could do is to state that the results are unspecified when
> they are used as delimiters; OR, leave the text as is, which already
> implies that it is unspecified.
> 
I agree that the wording:
"If the character designated by c appears
 following a , then it shall be
 considered to be that literal character,
 which shall not terminate the RE."
on 202x_d2.1 P3134, L106088-106090 is ambiguous and needs to be clarified.  I 
believe that it means that the escaped delimiter character is treated as the 
literal character (not as a delimiter) and that the listeral character is still 
treated as a special character if that character is special at that point in an 
RE.  But, I agree that it could be interpreted to mean that it is not only not 
a delimiter, but also not special.

I don't think I have ever worried about this wording because I just never use a 
special character as a delimiter if I'm going to have to escape that character 
in an RE.

Re: sed and delimiters that are also special characters to REs

[Don Cragun via austin-group-l at The Open Group]

> On Jan 10, 2022, at 2:15 PM, Christoph Anton Mitterer via austin-group-l at 
> The Open Group  wrote:
> 
> Hey.
> 
> Maybe someone can help me with this (or point out that it's undefined -
> and perhaps should be):
> 
> I was looking into when BREs/EREs are used with delimiters (i.e. sed's
> s- and y-commands) that are also special characters with respect to the
> respective RE syntax.
> 
> 
> There were some things which I found a bit ambiguous:
> 
> 
> 
> 
> 1) In "Addresses in sed" it says vaguely:
> "preceded and followed by a delimiter, usually a )"
> (line 106071, et seq., in the draft)
> 
> ... merely indicating that other characters may be used, but e.g. not
> clearly excluding (or including) '\' or newline - which are explicitly
> excluded as delimiters for the s- and y-commands.
> 
Hi Chris,
About 16 lines later in 202x_d2.1, in the subsection
titled "Regular Expressions in sed" on lines
106087-106091 it says:

  * In a context address, the construction "\cREc",
where c is any character other than 
or , shall be identical to "/RE/". If
the character designated by c appears following
a , then it shall be considered to be
that literal character, which shall not terminate
the RE. For example, in the context address
"\xabc\xdefx", the second x stands for itself, so
that the RE is "abcxdef".

Doesn't this answer your questions?

Cheers,
Don

> 2) Now with respect to delimiters that are special characters in the RE
> (using BREs here), either by themselves, (like '.') or when escaped via
> a preceding '\', like '\('.
> 
> The documentation says merely:
> "Within the RE and the replacement, the RE delimiter itself can be used
> as a literal character if it is preceded by a ."
> (line 106204, et seq., in the draft)
> 
> Maybe I'm just blind, but I couldn't find answers to the following:
> 
> 
> 
> a) Is it defined, how the unescaping of delimiters vs. special
> characters happens?
> Consider the following example:
> s(\\((X(
> There are at least two ways to parse that:
> - splitting up into RE an replacement parts first by going through the
>  string and looking for any (non-escaped) delimiter (here '('),
>  removing the escapes for any others, so one would end up with:
>  RE='\('
>  replacement='X'
> - going from left to right unescaping both at once, which would lead
>  here to:
>  RE='\\'
>  followed by two delimiters ((, followed by an unknown flag and thus
>  an error
>  (which is what implementations seem to do)
> 
> 
> b) There doesn't seem to be any way (or mentioning of that) to fully
> use a special characters as delimiter
> Consider e.g.:
> s.\..X.
> which is used as:
> s/./X/
> but it seems impossible to get:
> s/\./X/
> when using '.' as delimiter.
> 
> Same for a character that gets only special when escaped with '\':
> s(\((X(
> which is used as:
> s/(/X/
> but it seems impossible to get:
> s/\(/X/
> when using '(' as delimiter.
> (I know the above lacks a closing '\)' and something within the
> subexpression ... but that could be easily added.)
> 
> I found that e.g GNU an BusyBox' sed allow the following workaround:
> s.[.].X.
> which seems used as:
> s/[.]/X/
> 
> But again, at least to me the standard seems to be ambiguous with
> respect to how this should be parsed.
> While the bracket expression itself is defined to take the '.'
> literally, it nowhere seems to say that this is even to be seen as a
> '.' for the RE and not as the next delimiter.
> 
> 
> c) The documentation uses the phrase "literal character" for the
>   delimiter when being escaped with a '\' at least in these places:
> "If the character designated by c appears following a , then
> it shall be considered to be that literal character, which shall not
> terminate the RE."
> (line 106088, et seq., in the draft)
> 
> and
> 
> "Within the RE and the replacement, the RE delimiter itself can be used
> as a literal character if it is preceded by a ."
> (line 106204, et seq., in the draft)
> 
> Maybe it's worth to clarify this, that it it means literal with respect
> to the command and not being a delimiter for that, but that the
> character may not be literal with respect to the RE.
> 
> E.g. AFAIU:
> s.\..X.
> would be the same as:
> s/./X/
> and '.' would be used as special character.
> 
> 
> 
> 
> Any insights with respect to whether and what POSIX mandates in these
> points would be appreciated.
> 
> 
> Thanks,
> Chris.
> 

Re: [1003.1(2016/18)/Issue7+TC2 0001440]: Calling `system("-some-tool")` fails (although it is a valid `sh` command)

[Don Cragun via austin-group-l at The Open Group]

The standard does specify exceptions to the Utility Syntax Guidelines in the 
OPTIONS section of each utility that needs an exception.  For example, if you 
look at the start of the OPTIONS section in the description of the c99 utility, 
you will find:
The c99 utility shall conform to XBD Section
12.2 (on page 199), except that:
 • Options can be interspersed with operands.
 • The order of specifying the −L, −l, and −R
   options, and the order of specifying −l
   options with respect to pathname operands is
   significant.
 • Conforming applications shall specify each
   option separately; that is, grouping option
   letters (for example, −cO) need not be
   recognized by all implementations.

 - Don

> On Nov 1, 2021, at 2:12 PM, Wayne Pollock via austin-group-l at The Open 
> Group  wrote:
> 
>> ...
>> For context, the example was . nohup should be, and as 
>> far as I know, is required to support invocations as
>> , treating that first <--> as the end of the options. The GNU 
>> extension that options and the end-of-options indicator can also follow 
>> operands is as far as I know not supported by POSIX in the first place 
>> (Utility Syntax Guideline 9: "All options should precede operands on the 
>> command line.") 
> 
> The POSIX utility "c99" (hopefully renamed in issue 8) does have options that
> follow operands.  So Guideline 9 you quoted needs to be fixed to say "except 
> as noted".
> There are other such utilities too, although I don't think any in POSIX/SUS.  
> (For example
> Gnu ps and tar.)
> 
>> and accordingly disabled in GNU utilities when invoked in POSIX mode, so in 
>> any POSIX utility, if the arguments start with sh -c --, I think the fact 
>> that sh can only be interpreted as an operand already means that -c and -- 
>> must also be interpreted as operands.
> 
> I agree that's how it should be, but I am not certain the standard is clear on
> this.  As a non-expert I will leave matters to you and the other experts.  I 
> just
> appreciate the opportunity to raise my concerns occasionally on this list.
> 
> -- 
> Wayne Pollock
> 

Re: Adding %n$ conversions to the printf utility (printf(1))

[Don Cragun via austin-group-l at The Open Group]

> On Sep 10, 2021, at 3:29 PM, Joerg Schilling via austin-group-l at The Open 
> Group  wrote:
> 
> "Stephane Chazelas via austin-group-l at The Open Group" 
>  wrote:
> 
>> 2021-09-10 22:46:26 +0100, Stephane Chazelas via austin-group-l at The Open 
>> Group:
>> [...]
>>> I've personally used the feature to reorder items in sets, so
>>> would object to precluding reusing arguments.
>> [...]
> 
> I agree...
> 
>> As mentioned on that mailing list and it's still undocumented,
>> -r can be used with print -f to disable reuse:
> 
> The problem, POSIX defines printf(1) to not handle options. So I don't think, 
> we could add that.
> 
> Jörg

I think you're confusing the requirements for printf and echo.  The standard 
echo is not allowed to accept options. The standard printf does not define any 
options, but allows them as implementation extensions.

- Don

Re: utilities and write errors

[Don Cragun via austin-group-l at The Open Group]

> On Jun 29, 2021, at 3:20 PM, tg...@mirbsd.org via austin-group-l at The Open 
> Group  wrote:
> 
>> ... ... ...
> 
> Ah, so you meant…
> 
>> "/tmp cd ~ >& /dev/zero"
> 
> … which was not clear from the punctuation salad you posted.
> 
>> "Violates POSIX on the parse level?!"  Eek! Next
> 
> It does: >& is parsed as > & by POSIX rules, TTBOMK.

No.  According to XCU Section 2.7.6 (Duplicating an Output File Descriptor) 
redirection operators of the form:
[n]>
closes file descriptor n if word is "-" and opens file descriptor n as a 
duplicate of the file descriptor specified by word if word is a string of 
digits.

If n is not specified, standard output is closed or made to be a duplicate of 
the file descriptor specified by word.

If word (in this case an empty string) is not a string of digits and word is 
not "-", the results are explicitly unspecified.

Cheers,
Don

> 
> bye,
> //mirabilos
>  ... ... ...

Re: utilities and write errors

[Don Cragun via austin-group-l at The Open Group]

> On Jun 27, 2021, at 2:33 PM, tg...@mirbsd.org wrote:
> 
> Don Cragun via austin-group-l at The Open Group dixit:
> 
>>  • When an unrecoverable error condition is
>>encountered, the utility shall exit with a
>>non-zero exit status.

Please do not cherry pick what you quote from my message!
The lead in to the above quote was:
   The following shall apply to each utility, unless
   otherwise stated:
... ... ...

When the CONSEQUENCES OF ERRORS section of the specification of the pwd utility 
says:
If an error is detected, output shall not be
written to standard output, a diagnostic message
shall be written to standard error, and the exit
status is not zero.
the standard clearly states OTHERWISE for the behavior of that utility.  When 
the standard states OTHERWISE, the requirements following "The following shall 
apply to each utility, UNLESS OTHERWISE STATED" do not apply.
> 
> Is “pwd >/dev/full” an “unrecoverable error condition” as regards
> the pwd utility?
> 
> I think not. It validated the current working directory and attempted
> to hand the information over; what the user does with it is the user’s
> fault.

Note also that without options, the pwd utility does not validate the current 
working directory unless the PWD environment variable is not present, does not 
contain an absolute pathname, or contains a component of the pathname that is 
"." or "..".  Under normal circumstances, the pwd utility is just supposed to 
copy the contents of the PWD environment variable to stdout.

And, if /dev/full is not an existing file that is writable or the name of a 
file that can be successfully created by the user invoking pwd, then the shell 
will report an error and not even try to invoke pwd.

> 
> More context: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990265
> and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990264 (though
> they are pretty much the same information).

The pwd utility CONSEQUENCES OF ERRORS quote from the standard is also noted in 
both of the above references.  And, I agree with Vincent in those references 
when he says that when using the pwd built-in utility "one would expect a 
diagnostic message (and I think that one should also get one for the other 
builtins)".

Sincerely,
Don

> 
> Thanks in advance,
> //mirabilos
> -- 
> Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
> gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
> reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
>   (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
> 

Re: utilities and write errors

[Don Cragun via austin-group-l at The Open Group]

Section 1.4 of the Commands and Utilities Volume of the standard (Utility 
Description Defaults) already does this in the CONSEQUENCES OF ERRORS section 
on P2303-2304, L74122-74151 in P1003.1-202x Draft 2 and on P2341-2342, 
L74540-74569 in P1003.1-2017.  Note especially:
The following shall apply to each utility, unless
otherwise stated:
... ... ...
• When an unrecoverable error condition is
  encountered, the utility shall exit with a
  non-zero exit status.
• A diagnostic message shall be written to
  standard error whenever an error condition
  occurs.

Cheers,
Don Cragun, IEEE PASC OR

> On Jun 24, 2021, at 12:18 PM, Vincent Lefevre via austin-group-l at The Open 
> Group  wrote:
> 
> Shouldn't POSIX require that when a utility cannot write its output
> (e.g. due to ENOSPC or EPIPE), it shall be regarded as an error, i.e.
> the exit status be non zero, with a diagnostic message if possible?
> 
> -- 
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> 

Re: Did I ever say how much I detest mantis...

[Don Cragun via austin-group-l at The Open Group]

Hi again,
The Section and Page Number sections have also been fixed.

 - Don

> On Aug 13, 2020, at 1:08 PM, Robert Elz via austin-group-l at The Open Group 
>  wrote:
> 
> When I first submitted issue 1389, I had forgotten to fill in
> the "Category" field (select "shell and Utilities" from the
> drop down menu.
> 
> So after getting the error because of that (that was fine) I
> used my browser's "back" button to return to the form, filled
> in the missing field, and submitted again.
> 
> I didn't notice that (for some unknowable reason) half the other
> fields had returned to their default values.Why?
> 
> In any case 1389 is supposed to be an Severity:"Objection" and
> Type:"Error".
> 
> Clearly my name is not "Your Name Here"!   (Seeing that value in that
> field should result in rejection of the submission - if that had happened
> I would almost certainly have noticed everything else that changed as well).
> 
> The section numbers were intended to be:
> 2.9.1.1 1.c (2.9.1.4 1.c in Issue8 Draft 1), 2.9.1.1 1.d, 2.9.1.1 1.e.i.a
> 
> And the page numbers
> 2367 (2335 in Issue8 draft 1)
> 
> For some unknown reason it retained the line numbers.
> 
> Can someone correct it please?
> 
> Thanks,
> 
> kre
> 

Re: Did I ever say how much I detest mantis...

[Don Cragun via austin-group-l at The Open Group]

Hi Robert,
The Severity, Type, and Name fields have all been corrected on bugid:1389 and 
all three bugs have been related to each other.

 - Don

> On Aug 13, 2020, at 1:08 PM, Robert Elz via austin-group-l at The Open Group 
>  wrote:
> 
> When I first submitted issue 1389, I had forgotten to fill in
> the "Category" field (select "shell and Utilities" from the
> drop down menu.
> 
> So after getting the error because of that (that was fine) I
> used my browser's "back" button to return to the form, filled
> in the missing field, and submitted again.
> 
> I didn't notice that (for some unknowable reason) half the other
> fields had returned to their default values.Why?
> 
> In any case 1389 is supposed to be an Severity:"Objection" and
> Type:"Error".
> 
> Clearly my name is not "Your Name Here"!   (Seeing that value in that
> field should result in rejection of the submission - if that had happened
> I would almost certainly have noticed everything else that changed as well).
> 
> The section numbers were intended to be:
> 2.9.1.1 1.c (2.9.1.4 1.c in Issue8 Draft 1), 2.9.1.1 1.d, 2.9.1.1 1.e.i.a
> 
> And the page numbers
> 2367 (2335 in Issue8 draft 1)
> 
> For some unknown reason it retained the line numbers.
> 
> Can someone correct it please?
> 
> Thanks,
> 
> kre
>