net/if.h not connected to anything else in the spec

Hi, after some (moderate) digging, it seems like the interfaces documented in net/if.h are not related to anything else defined in POSIX. To recap, the routines declared there provide a mapping between network interface names and numeric indexes. However, I couldn't find any other interface w

RE: Should POSIX/SUS advise against MSG_OOB in recognition of RFC 6093?

> -Original Message- > From: Danny Niu > Subject: Should POSIX/SUS advise against MSG_OOB in recognition of RFC 6093? > > RFC 6093 "On the Implementation of the TCP Urgent Mechanism" > surveys the then existing implementations of TCP "URG" flag and use and > recommends that new applicati

RE: [Issue 8 drafts 0001349]: Where to obtain ISO/IEC standards (footnote)

> -Original Message- > From: Quentin Rameau > Sent: Monday, July 20, 2020 0:23 > To: austin-group-l@opengroup.org > Subject: Re: [Issue 8 drafts 0001349]: Where to obtain ISO/IEC standards > (footnote) > > Hello, > > > ==

RE: Why does %#x omit the 0x prefix for a zero value?

Yes, but the same logic (0 being unambiguous in all radices) equally applies to 1. From: shwaresyst Sent: Monday, July 6, 2020 18:35 To: Schwarz, Konrad (CT RDA IOT SES-DE) ; austin-group-l@opengroup.org Subject: RE: Why does %#x omit the 0x prefix for a zero value? The necessity for "0

Why does %#x omit the 0x prefix for a zero value?

Sorry, this isn't really a POSIX or a standards question, but does anyone know why this was defined this way? Was it just codification of "historical practice" (i.e., a non-fatal bug)? While we're at it: when print formatting integers, are there any disadvantages of using a precision specific

RE: LC_CTYPE=UTF-8

> -Original Message- > From: Ingo Schwarze > Sent: Thursday, June 25, 2020 21:25 > To: Alan Coopersmith > Cc: Hans Åberg ; Austin Group > > Subject: Re: LC_CTYPE=UTF-8 > > Hi Alan, > > Alan Coopersmith wrote on Thu, Jun 25, 2020 at 12:13:33PM -0700: > > On 6/25/20 8:31 AM, Ingo Schwar

RE: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format

> -Original Message- > From: Larry Dwyer > The purpose of the POSIX locale is mandatory so that a conformance suite can > be developed for the purpose of testing and branding a > manufacturer's system for POSIX conformance (period). Hmm, isn't it also so that applications can make more a

RE: aliases in command substitutions

Please ignore, superseded by subsequent discussion. > -Original Message- > From: Schwarz, Konrad (CT RDA IOT SES-DE) > Sent: Tuesday, April 21, 2020 10:18 > To: Robert Elz > Cc: austin-group-l@opengroup.org > Subject: RE: aliases in command substitutions > >

RE: aliases in command substitutions

> -Original Message- > From: Robert Elz > Sent: Monday, April 20, 2020 15:35 > To: Schwarz, Konrad (CT RDA IOT SES-DE) > Cc: austin-group-l@opengroup.org > Subject: Re: aliases in command substitutions > > Date:Mon, 20 Apr 2020 07:12:03 +0000 >

RE: aliases in command substitutions

> -Original Message- > From: Robert Elz > Sent: Sunday, April 19, 2020 23:04 > To: austin-group-l@opengroup.org > On the other hand, if we avoid that "not including the alias substitution" > While I am here, one more variation. If I change that unquoted command to be > >

RE: Weird possibility with async processes, $!, and long running scripts

> -Original Message- > From: Robert Elz > Sent: Sunday, March 15, 2020 13:47 > To: shwaresyst > Cc: austin-group-l@opengroup.org > Subject: Re: Weird possibility with async processes, $!, and long running > scripts > > Date:Sun, 15 Mar 2020 11:39:27 + (UTC) > From:

RE: [1003.1(2004)/Issue 6 0000267]: time (keyword)

> From: Nick Stoughton > Sent: Tuesday, February 25, 2020 00:27 > To: Chris F.A. Johnson Cc: austin-group-l@opengroup.org > Subject: Re: [1003.1(2004)/Issue 6 267]: time (keyword) > > If we are bicycle-shedding around a name for a new utility, > I like the idea of using the currently res

RE: [1003.1(2008)/Issue 7 0000252]: dot should follow Utility Syntax Guidelines

> -Original Message- > From: Robert Elz > Sent: Tuesday, February 4, 2020 1:56 PM > To: Steffen Nurpmeso > Cc: austin-group-l@opengroup.org > Subject: Re: [1003.1(2008)/Issue 7 252]: dot should follow Utility Syntax > Guidelines > > What I am at the very least unclear about, is tha

RE: A question on file flags after fork

> -Original Message- > From: Ronald F. Guilmette > Sent: Tuesday, January 14, 2020 8:16 AM > To: austin-group-l@opengroup.org > Subject: Re: A question on file flags after fork > > In message , > Shware Systems

RE: system() and pthread_atfork()

> -Original Message- > From: Robert Elz > Sent: Tuesday, January 14, 2020 11:35 AM > To: Schwarz, Konrad (CT RDA IOT SES-DE) > Cc: nate.karst...@garmin.com; austin-group-l@opengroup.org > Subject: Re: system() and pthread_atfork() > | The point I was trying to m

RE: system() and pthread_atfork()

> -Original Message- > From: Robert Elz > Sent: Monday, January 13, 2020 1:43 PM > To: Schwarz, Konrad (CT RDA IOT SES-DE) > Cc: nate.karst...@garmin.com; austin-group-l@opengroup.org > Subject: Re: system() and pthread_atfork() > > Date:Mon, 13

RE: system() and pthread_atfork()

> -Original Message- > From: Karstens, Nate > Sent: Sunday, January 12, 2020 11:52 AM > To: 'austin-group-l@opengroup.org' > Subject: Re: system() and pthread_atfork() Going back to the original problem, > We are running Linux on an embedded system. The platform can > change the IP addr

RE: system() and pthread_atfork()

> -Original Message- > From: Matthew Dempsky > Sent: Friday, January 3, 2020 2:27 AM > To: Schwarz, Konrad (CT RDA IOT SES-DE) > Cc: Karstens, Nate ; austin-group-l@opengroup.org > Subject: Re: system() and pthread_atfork() > > On Thu, Jan 2, 2020 at

RE: system() and pthread_atfork()

> -Original Message- > From: Karstens, Nate > Sent: Thursday, December 19, 2019 12:26 AM > To: austin-group-l@opengroup.org > Subject: system() and pthread_atfork() > > The current definition of system() does not define if the pthread_atfork() > handlers are called. We ran into a >

RE: Are BSDs evidently more fault tolerant than (say) SysV and Linux?

Well, SUN obviously felt different, witness the switch from SunOS (BSD-derived) to Solaris (Sys V). I think that Sys V substantially fixed the signal model and shared library support, at least. > -Original Message- > From: Danny Niu > Sent: Tuesday, November 26, 2019 2:32 AM > To: Aust

RE: What is this out-of-scope thing called Record IO?

> From: Donn Terry > Sent: Friday, November 1, 2019 3:37 PM > To: Scott Lurndal > Cc: Danny Niu ; Austin Group Mailing List > > Subject: Re: What is this out-of-scope thing called Record IO? > That's correct. At the time the spec was written most OSs (and there were a > lot more different on

RE: [1003.1(2013)/Issue7+TC1 0001045]: Issues with "cd -"

> -Original Message- > From: Austin Group Bug Tracker > Sent: Wednesday, October 23, 2019 3:58 PM > To: austin-group-l@opengroup.org > Subject: [1003.1(2013)/Issue7+TC1 0001045]: Issues with "cd -" > > > The following issue has a resolution that has been APPLIED. > ==

RE: [1003.1(2013)/Issue7+TC1 0001052]: ${#var} should be decimal I presume.

> -Original Message- > From: Austin Group Bug Tracker > Sent: Wednesday, October 23, 2019 4:02 PM > To: austin-group-l@opengroup.org > Subject: [1003.1(2013)/Issue7+TC1 0001052]: ${#var} should be decimal I > presume. > > > The following issue has a resolution that has been APPLIED. > =

RE: More issues with pattern matching

> -Original Message- > From: Harald van Dijk > Sent: Thursday, September 26, 2019 4:39 PM > To: austin-group-l@opengroup.org > Cc: austin-group-l@opengroup.org > Subject: Re: More issues with pattern matching > > On 26/09/2019 13:13, Robert Elz wrote: > > So, if we have > > > > [[:

RE: More issues with pattern matching

> -Original Message- > From: Robert Elz > So, is [[:"alpha":]] required to be treated the same as [[:alpha:]] , not > allowed to be treated the same, > explicitly unspecified, or simply never considered (previously) ? An argument for requiring [[:"alpha":]] to be the same as [[:alpha:]]

editorial mistake in c99 man page: table reference wrong

Hi, I am unfortunately failing in submitting a bug report via Aardvark (perhaps cookies), but anyhow: In https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html#tag_20_11_13_04, penultimate paragraph, The getconf utility can be used to get flags for the threaded programming

RE: Arrays

> -Original Message- > From: Stephane Chazelas > Sent: Thursday, May 30, 2019 10:14 PM > To: Steven Penny > Cc: austin-group-l@opengroup.org > Subject: Re: Arrays > > In there, instead, a list was stored in a *scalar* variable and split (and > globbed) upon expansion when unquoted as i

RE: Lifecycle of process CPU time clock

> -Original Message- > From: Yann Droneaud > Sent: Wednesday, March 20, 2019 4:58 PM > To: Schwarz, Konrad (CT RDA IOT SES-DE) ; > austin-group-l@opengroup.org > Subject: Re: Lifecycle of process CPU time clock > > As CPU clocks are per process and per threads

RE: Lifecycle of process CPU time clock

> -Original Message- > From: Yann Droneaud > Sent: Tuesday, March 19, 2019 9:56 PM > To: austin-group-l@opengroup.org > Subject: Lifecycle of process CPU time clock > > Hi, > > I have some questions/concerns regarding the lifecycle of a clockid_t > returned by clock_getcpuclock() for a

RE: C11/C17 fopen() "wx" and "exclusive access"

> -Original Message- > From: Geoff Clare > Sent: Wednesday, March 13, 2019 4:28 PM > To: austin-group-l@opengroup.org > Subject: C11/C17 fopen() "wx" and "exclusive access" > > C11 introduced an "x" character on the end of fopen() mode arguments that > begin with "w", with the following

RE: [1003.1(2016)/Issue7+TC2 0001184]: strftime %C padding character unspecified

> > I believe that it is intended that '-' be included in %C, %Y, and %G > > for negative years, even without the '+' flag or a field width, > > although that is perhaps another area that deserves some > > clarification. I believe that the "if and only if" in the description > > of the '+' flag do

RE: pthread_spin_lock_t static initialization

> -Original Message- > From: Yann Droneaud > Sent: Monday, February 4, 2019 6:11 PM > To: austin-group-l@opengroup.org > Subject: pthread_spin_lock_t static initialization > > I've recently made use of POSIX thread's spin locks and found there was no > static initializer for them in the

RE: bc Suggestions

> -Original Message- > From: Gavin Howard > Sent: Monday, January 28, 2019 7:54 PM > To: austin-group-l@opengroup.org > Subject: Re: bc Suggestions > > On Thu, Jan 10, 2019 at 4:19 PM Gavin Howard wrote: > If users sometimes start bc to do number conversions, then what the Open > Group

RE: In defence of compound aliases

> -Original Message > From: Robert Elz > Sent: Tuesday, January 15, 2019 1:56 AM > To: Martijn Dekker > Cc: austin-group-l@opengroup.org > Subject: Re: In defence of compound aliases > > Date:Mon, 14 Jan 2019 16:24:24 +0100 > From:Martijn Dekker > Message-ID:

RE: Alias implementations being invalidated by proposed new wording?

> -Original Message- > Expressly making it defined that > alias foo='whatever \ ' > which does end in a space (but otherwise is the exact same thing as the > previous one) also does not expand aliases in the following > word > seems redundant to me. Since several shells (but not al

RE: [1003.1(2016)/Issue7+TC2 0001197]: Omission from 1108: LONG_MIN must be <= -2147483648

> -Original Message- > From: Austin Group Bug Tracker [mailto:nore...@msnkbrown.net] > Sent: Monday, July 30, 2018 9:19 PM > To: austin-group-l@opengroup.org > Summary:Omission from 1108: LONG_MIN must be <= > -2147483648 > Description: > In the resolution to 1108, N

RE: About issue 0001108 and abs(INT_MIN)

> -Original Message- > From: Joerg Schilling [mailto:joerg.schill...@fokus.fraunhofer.de] > Sent: Thursday, July 19, 2018 4:53 PM > To: vincent-o...@vinc17.net; austin-group-l@opengroup.org > Subject: Re: About issue 0001108 and abs(INT_MIN) > > Vincent Lefevre wrote: > > > The proble

RE: Historic perror() (was: perror() changes the orientation of stderr to byte-oriented mode if stderr is not oriented yet.)

> -Original Message- > From: Joerg Schilling [mailto:joerg.schill...@fokus.fraunhofer.de] > Sent: Friday, June 29, 2018 12:46 PM > To: g...@opengroup.org; austin-group-l@opengroup.org > Subject: Re: Historic perror() (was: perror() changes the orientation > of stderr to byte-oriented mode

RE: can [[:digit:]] match something other than 0123456789?

> -Original Message- > From: Stephane Chazelas [mailto:stephane.chaze...@gmail.com] > Sent: Sunday, May 20, 2018 10:43 PM > To: Geoff Clare > Cc: austin-group-l@opengroup.org > Subject: Re: can [[:digit:]] match something other than 0123456789? > > Note that having [x-y] be based on colla

RE: Minutes of the 17th May 2018 Teleconference

> -Original Message- > From: Andrew Josey [mailto:ajo...@opengroup.org] > Sent: Friday, May 18, 2018 1:36 PM > On page 2491 line 80125 section awk change: > \\ | Two characters. | In the lexical > token ERE, >|

RE: Should shell quoting within glob bracket patterns be effective?

> -Original Message- > From: Robert Elz [mailto:k...@munnari.oz.au] > Put that reasoning into the argument in the previous message, instead > of the ${ version and I think it becomes clearer how the current text > allows the '-' inside "a-c" to be treated literally, as the string is > pa

RE: Proper way to use an updating FILE on a tty?

> On Tue, Oct 10, 2017 at 7:46 AM, Schwarz, Konrad > > > wrote: > > > > > POSIX FILE streams opened for update need either a fflush() or a > > > file positioning function when switching from writing to reading, > > > and a file positioning function when s

Proper way to use an updating FILE on a tty?

POSIX FILE streams opened for update need either a fflush() or a file positioning function when switching from writing to reading, and a file positioning function when switching from reading to writing. The Newlib C library as used in Cygwin fails with perror() reporting "Illegal seek" when fsee

RE: FYI: ksh88 (/usr/xpg4/bin/sh) is not actually POSIX compliant

> -Original Message- > From: Martijn Dekker [mailto:mart...@inlv.org] > Subject: Re: FYI: ksh88 (/usr/xpg4/bin/sh) is not actually POSIX compliant > > Op 30-09-17 om 17:35 schreef Alan Coopersmith: > >> Where/how would I report Solaris bugs? > > > > Customers with support contracts can rep

RE: FYI: ksh88 (/usr/xpg4/bin/sh) is not actually POSIX compliant

> -Original Message- > From: Chet Ramey [mailto:chet.ra...@case.edu] > On 10/4/17 8:32 AM, Joerg Schilling wrote: > > >> The portion about "local variables" in the quoted text means that the > >> presence of the `typeset' command doesn't make a variable local: > >> there are no local varia

fscanf white space does not include carraige return

Hi, fscanf states that white space characters are skipped, and lists the white space characters. This list does not include carriage return. The POSIX definition of white space

RE: sh(1): is roundtripping of the positional parameter stack possible? (Was: Re: Shell parameter expansions involving '#")

> -Original Message- > From: Stephane Chazelas [mailto:stephane.chaze...@gmail.com] > To: Robert Elz > Cc: Steffen Nurpmeso; austin-group-l@opengroup.org > Subject: Re: sh(1): is roundtripping of the positional parameter stack > Here, I'd fire awk and quote more than one arg at a time: >

RE: using printf for ssize_t values

> -Original Message- > From: Eric Blake [mailto:ebl...@redhat.com] > Sent: Tuesday, January 10, 2017 7:17 PM > To: shwares...@aol.com; austin-group-l@opengroup.org > Subject: Re: using printf for ssize_t values > > On 01/10/2017 11:28 AM, shwares...@aol.com wrote: > > It looks like ssize_t

RE: using printf for ssize_t values

What is the actual rationale for ssize_t? On what machines is ssize_t different from ptrdiff_t? > -Original Message- > From: Eric Blake [mailto:ebl...@redhat.com] > Sent: Tuesday, January 10, 2017 4:17 PM > To: Austin Group > Subject: using printf for ssize_t values > > The C standard d

RE: when does PATH search stop?

> -Original Message- > From: Joerg Schilling [mailto:joerg.schill...@fokus.fraunhofer.de] > > > Modern shells tend to open the file and to check whether it > contains > > > an excutable header for a wrong architecture. > > > > Well, that is what POSIX requires, so the "modern shells" you ci

RE: when does PATH search stop?

> -Original Message- > From: Joerg Schilling [mailto:joerg.schill...@fokus.fraunhofer.de] > Sent: Thursday, November 24, 2016 1:05 PM > To: Schwarz, Konrad (CT RDA ITP SES-DE); g...@opengroup.org; austin- > grou...@opengroup.org > Subject: Re: when does PATH search s

RE: when does PATH search stop?

> -Original Message- > From: Schwarz, Konrad (CT RDA ITP SES-DE) > Sent: Thursday, November 24, 2016 12:26 PM > To: 'Geoff Clare'; austin-group-l@opengroup.org > Subject: RE: when does PATH search stop? > > > -Original Message- > > From

RE: when does PATH search stop?

> -Original Message- > From: Geoff Clare [mailto:g...@opengroup.org] > Sent: Thursday, November 24, 2016 11:32 AM > To: austin-group-l@opengroup.org > Subject: Re: when does PATH search stop? > > Mark Galeck wrote, on 24 Nov 2016: > > > > >There is no precise definition of "acceptable" >

RE: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

> -Original Message- > From: Geoff Clare [mailto:g...@opengroup.org] > Sent: Monday, November 07, 2016 5:20 PM > To: austin-group-l@opengroup.org > Subject: Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set > -C > > That seems to be in contradiction with it calling the link() s

RE: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

> -Original Message- > From: Geoff Clare [mailto:g...@opengroup.org] > Sent: Tuesday, November 01, 2016 11:27 AM > To: austin-group-l@opengroup.org > Subject: Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set > -C > > > Why are we bothering to attempt to make > (with -C) atom