RE: Access to old POSIX specifications (Was: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html)

2017-06-08 Thread Joseph Myers
On Thu, 8 Jun 2017, Joe Gwinn wrote: > Joseph M, > > What will you do with this old standard? I routinely use these standards for reference for implementation work (since in practice implementations deal with multiple standard versions, not just the latest), as well as for understanding the hi

RE: Access to old POSIX specifications (Was: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html)

2017-06-08 Thread Joe Gwinn
Joseph M, What will you do with this old standard? Joe G -Original Message- From: Joseph Myers [mailto:j...@polyomino.org.uk] Sent: Thursday, June 08, 2017 1:18 PM To: Stephane Chazelas Cc: Geoff Clare ; austin-group-l@opengroup.org Subject: Re: Access to old POSIX specifications (Was:

Re: Access to old POSIX specifications (Was: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html)

2017-06-08 Thread Joseph Myers
On Thu, 8 Jun 2017, Stephane Chazelas wrote: > 2017-06-08 15:28:49 +0100, Geoff Clare: > > Stephane Chazelas wrote, on 08 Jun 2017: > > > > > > BTW, are older (than SUSv1) versions of POSIX available > > > somewhere? > > > > All previous versions were only distributed on paper. > > OK. Does any

Re: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html

2017-06-08 Thread Joseph Myers
On Thu, 8 Jun 2017, Andrew Josey wrote: > We’re not able to make available IEEE copyrighted materials that > pre-date the MoU of 1998, hence although many of us as individuals have > older POSIX drafts obtained as part of the standards development process > at the time, we cannot post them . W

Re: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html

2017-06-08 Thread Stephane Chazelas
2017-06-08 16:51:39 +0100, Andrew Josey: [...] > >> I just came across > >> https://www.opengroup.org/austin/papers/posix_faq.html > >> where question Q0, Q3 ("What is the latest version of POSIX.1?") > >> would need to be updated following the recent release of TC2. > > […] > > > > > Q18 as well

Re: rm -rf ./ ../

2017-06-08 Thread Stephane CHAZELAS
2017-06-08 22:34:30 +0700, Robert Elz: > Date:Thu, 8 Jun 2017 10:50:07 +0100 > From:Stephane CHAZELAS > Message-ID: <20170608095007.gb7...@chaz.gmail.com> > > | It would be like saying: find . -name '.*' should report all the > | . and .. entries, because those en

Re: Access to old POSIX specifications (Was: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html)

2017-06-08 Thread Andrew Josey
Stephane Comments below > On 8 Jun 2017, at 16:51, Stephane Chazelas > wrote: > > 2017-06-08 15:28:49 +0100, Geoff Clare: >> Stephane Chazelas wrote, on 08 Jun 2017: >>> >>> BTW, are older (than SUSv1) versions of POSIX available >>> somewhere? >> >> All previous versions were only distribu

Re: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html

2017-06-08 Thread Andrew Josey
Stephane, all Thanks , comments below > On 8 Jun 2017, at 13:27, Stephane CHAZELAS > wrote: > > 2017-06-08 13:02:45 +0100, Stephane Chazelas: > [...] >> I just came across >> https://www.opengroup.org/austin/papers/posix_faq.html >> where question Q0, Q3 ("What is the latest version of POSIX

Access to old POSIX specifications (Was: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html)

2017-06-08 Thread Stephane Chazelas
2017-06-08 15:28:49 +0100, Geoff Clare: > Stephane Chazelas wrote, on 08 Jun 2017: > > > > BTW, are older (than SUSv1) versions of POSIX available > > somewhere? > > All previous versions were only distributed on paper. OK. Does anybody here have any digitalised copy? Is re-distribution restrict

Re: rm -rf ./ ../

2017-06-08 Thread Robert Elz
Date:Thu, 8 Jun 2017 10:50:07 +0100 From:Stephane CHAZELAS Message-ID: <20170608095007.gb7...@chaz.gmail.com> | It would be like saying: find . -name '.*' should report all the | . and .. entries, because those entries are there and we don't | want "find" second

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

2017-06-08 Thread Austin Group Bug Tracker
The following issue has been RESOLVED. == http://austingroupbugs.net/view.php?id=1052 == Reported By:dannyniu Assigned To: ===

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

2017-06-08 Thread Austin Group Bug Tracker
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1052 == Reported By:dannyniu Assigned To: =

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

2017-06-08 Thread Austin Group Bug Tracker
The issue 0001051 has been set as DUPLICATE OF the following issue. == http://austingroupbugs.net/view.php?id=267 == Reported By:Don Cragun As

[1003.1(2013)/Issue7+TC1 0001051]: stderr redirection of the "time" utility

2017-06-08 Thread Austin Group Bug Tracker
The following issue has been set as DUPLICATE OF issue 267. == http://austingroupbugs.net/view.php?id=1051 == Reported By:stephane Assigne

[1003.1(2013)/Issue7+TC1 0001051]: stderr redirection of the "time" utility

2017-06-08 Thread Austin Group Bug Tracker
The following issue has been CLOSED. == http://austingroupbugs.net/view.php?id=1051 == Reported By:stephane Assigned To: =

Re: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html

2017-06-08 Thread Geoff Clare
Stephane Chazelas wrote, on 08 Jun 2017: > > BTW, are older (than SUSv1) versions of POSIX available > somewhere? All previous versions were only distributed on paper. > What about the archives of the mailing list (prior to > gmane)? Try https://collaboration.opengroup.org/operational/mailarch.

Re: rm -rf ./ ../

2017-06-08 Thread Geoff Clare
Stephane Chazelas wrote, on 08 Jun 2017: > > 2017-06-08 12:11:22 +0100, Geoff Clare: > [...] > > I can't answer that without knowing why the Base Working Group decided > > to put in that text instead of using the POSIX.1-1990 text. It's > > possible there might be some defect report against a dra

Re: rm -rf ./ ../

2017-06-08 Thread Geoff Clare
Stephane Chazelas wrote, on 08 Jun 2017: > > 2017-06-08 12:11:22 +0100, Geoff Clare: > [...] > > > OK, but the question remains: "what does it mean?". A "stricter > > > requirement" for what? That "." or ".." should not come without > > > the other (my interpretation)? Or that they should not be >

Re: rm -rf ./ ../

2017-06-08 Thread Shware Systems
It supports base POSIX systems aren't non-conforming, if they use how I interpret it. Requiring both if one exists but not the other is XSI, it looks, but my copy of c165.pdf just has the shading, not the XSI margin code. So we could both be right and wrong on this, lol. On Thursday, June 8, 20

Re: rm -rf ./ ../

2017-06-08 Thread Stephane Chazelas
2017-06-08 12:11:22 +0100, Geoff Clare: [...] > I can't answer that without knowing why the Base Working Group decided > to put in that text instead of using the POSIX.1-1990 text. It's > possible there might be some defect report against a draft of XSH4, or > a discussion in the email archives fr

Re: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html

2017-06-08 Thread Stephane Chazelas
2017-06-08 13:02:45 +0100, Stephane Chazelas: [...] > I just came across > https://www.opengroup.org/austin/papers/posix_faq.html > where question Q0, Q3 ("What is the latest version of POSIX.1?") > would need to be updated following the recent release of TC2. [...] Q18 as well. BTW, are older (t

About Q15 in the POSIX FAQ

2017-06-08 Thread Stephane Chazelas
https://www.opengroup.org/austin/papers/posix_faq.html > Q15. Does removal of obsolescent utility syntax mean that > implementations supporting usages of head -5 file, tail -5 file, > tail -l file are no longer allowed? > > No, in general the intent of removing the obsolescent forms of > the util

s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html

2017-06-08 Thread Stephane Chazelas
Hello, I just came across https://www.opengroup.org/austin/papers/posix_faq.html where question Q0, Q3 ("What is the latest version of POSIX.1?") would need to be updated following the recent release of TC2. -- Stephane

Re: rm -rf ./ ../

2017-06-08 Thread Stephane Chazelas
2017-06-08 12:11:22 +0100, Geoff Clare: [...] > > OK, but the question remains: "what does it mean?". A "stricter > > requirement" for what? That "." or ".." should not come without > > the other (my interpretation)? Or that they should not be > > treated specially (Mark's interpretation) or that t

Re: rm -rf ./ ../

2017-06-08 Thread Geoff Clare
Stephane Chazelas wrote, on 08 Jun 2017: > > 2017-06-08 10:53:52 +0100, Geoff Clare: > > Stephane CHAZELAS wrote, on 08 Jun 2017: > > > > > > I can see that text was already there at > > > http://archive.opengroup.org/publications/archive/CDROM/c435.pdf > > > (1994, I don't think I have access to

Re: rm -rf ./ ../

2017-06-08 Thread Stephane Chazelas
2017-06-08 11:01:29 +0100, Geoff Clare: > Robert Elz wrote, on 08 Jun 2017: > > > > And while here, I am also not in favour of attempts to "fix" breakage, just > > so we appear to conform to the standard. If "." and ".." are supposed to > > appear in the directories, and (for whatever reason) onl

Re: "-" operand to "sh"

2017-06-08 Thread Stephane CHAZELAS
2017-06-08 12:04:40 +0200, Joerg Schilling: > Stephane CHAZELAS wrote: > > > Let's face it, a shell that would leave the "m" option "on" when > > the user explicitly requested it to be "off" in > > > > sh +m > > > > is a bug (and in this case also a conformance bug for shells > > that support UP

Re: rm -rf ./ ../

2017-06-08 Thread Stephane Chazelas
2017-06-08 10:53:52 +0100, Geoff Clare: > Stephane CHAZELAS wrote, on 08 Jun 2017: > > > > I can see that text was already there at > > http://archive.opengroup.org/publications/archive/CDROM/c435.pdf > > (1994, I don't think I have access to older POSIX/Unix related > > specifications), but marke

Re: "-" operand to "sh"

2017-06-08 Thread Joerg Schilling
Stephane CHAZELAS wrote: > Let's face it, a shell that would leave the "m" option "on" when > the user explicitly requested it to be "off" in > > sh +m > > is a bug (and in this case also a conformance bug for shells > that support UP though it may need to be clarified). Since POSIX requires tha

Re: rm -rf ./ ../

2017-06-08 Thread Geoff Clare
Robert Elz wrote, on 08 Jun 2017: > > And while here, I am also not in favour of attempts to "fix" breakage, just > so we appear to conform to the standard. If "." and ".." are supposed to > appear in the directories, and (for whatever reason) only one of them happens > to be there, then readdir(

Re: "-" operand to "sh"

2017-06-08 Thread Stephane CHAZELAS
2017-06-08 11:39:31 +0200, Joerg Schilling: > Jilles Tjoelker wrote: > > > > While doing this, I discovered that the Burne Shell first parses the > > > command line options and later decides whether the current shell is > > > interactive. For this reason, I do not see that it would be possible >

Re: rm -rf ./ ../

2017-06-08 Thread Geoff Clare
Stephane CHAZELAS wrote, on 08 Jun 2017: > > I can see that text was already there at > http://archive.opengroup.org/publications/archive/CDROM/c435.pdf > (1994, I don't think I have access to older POSIX/Unix related > specifications), but marked "EX" (extension) there which doesn't > tie up with

Re: rm -rf ./ ../

2017-06-08 Thread Stephane CHAZELAS
2017-06-08 11:10:36 +0200, Joerg Schilling: > Stephane CHAZELAS wrote: > > > Could it be that it means that "." and ".." should be returned > > *first* when they're there on XSI systems? (which would be yet > > another interpretation that is valid as an "extension" (non-XSI > > are allowed to ret

Re: "-" operand to "sh"

2017-06-08 Thread Joerg Schilling
Jilles Tjoelker wrote: > > While doing this, I discovered that the Burne Shell first parses the > > command line options and later decides whether the current shell is > > interactive. For this reason, I do not see that it would be possible > > to use "sh +m" in a useful way. > > It is possible t

Re: rm -rf ./ ../

2017-06-08 Thread Joerg Schilling
Stephane CHAZELAS wrote: > Could it be that it means that "." and ".." should be returned > *first* when they're there on XSI systems? (which would be yet > another interpretation that is valid as an "extension" (non-XSI > are allowed to return other entries before "." and "..")). >From what I c