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

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

Re: pathnames with two leading slashes

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

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

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

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

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

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

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,

Re: wait and stopped jobs

> 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> > >

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

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

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

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

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

> 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

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

> 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 >

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

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

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

> 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

Re: utilities and write errors

> 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

Re: utilities and write errors

> 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

Re: utilities and write errors

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

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

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 >

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

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