Re: x[ as first word in sh
> On Jul 29, 2019, at 3:30 PM, Stephane Chazelas > wrote: > > 2019-07-29 22:25:29 +0100, Stephane Chazelas: >> 2019-07-29 21:33:50 +0100, Stephane Chazelas: >> [...] >>> BTW, what's the point of 2.10.2 7a? It seems 7b already says >>> what 7a says (if the TOKEN doesn't contain a =, then rule 1 >>> applies). The distinction seems to be caused by the distinction >>> between cmd_name vs cmd_word grammar rules which seems to be >>> about keywords not being recognised after redirections or >>> assignments, but I can't see how 7a/7b help there. >> [...] >> >> It seems it was broken in the 2016 edition by the resolution of >> http://austingroupbugs.net/view.php?id=839 > [...] > > > I see it (and several other issues) was already raised in > http://austingroupbugs.net/view.php?id=1100 > which was rejected. > > The grammar in the suggested resolution there makes a lot more > sense to me than the current one but that may be down to me > missing some background on yacc parsing and misunderstanding how > it works. > > Since 1100 was rejected, shouldn't the other issues it was meant > to factorize (which doesn't include this one though) and were > closed as duplicate reopened? > > -- > Stephane Hi Stephane, No. The reasons why bugid:1100 was rejected are clearly detailed in bugnote:4038. None of those issues have been addressed in the more than 14 months since that bug report was rejected. There is no reason to believe that if we reopened all of the bugs that Mark said were replaced by bugid:1100 that we would not just be wasting our time and rejecting each one of them with a duplicate of bugnote:4038 as the reason for rejection. Please do not tell us to go back and redo a lot of work we did over a year ago. If you think you understand the problem(s) better than Mark did, please file a new bug (or a few new bugs) that clearly states the problem that each is addressing, gives examples of shell productions that are incorrectly handled by the current grammar, explains how your changes fix the problem (without creating new problems), and defines all new terms used by your changes. All of this is detailed in bugnote:4038. Sincerely, Don
Re: x[ as first word in sh
2019-07-29 22:25:29 +0100, Stephane Chazelas: > 2019-07-29 21:33:50 +0100, Stephane Chazelas: > [...] > > BTW, what's the point of 2.10.2 7a? It seems 7b already says > > what 7a says (if the TOKEN doesn't contain a =, then rule 1 > > applies). The distinction seems to be caused by the distinction > > between cmd_name vs cmd_word grammar rules which seems to be > > about keywords not being recognised after redirections or > > assignments, but I can't see how 7a/7b help there. > [...] > > It seems it was broken in the 2016 edition by the resolution of > http://austingroupbugs.net/view.php?id=839 [...] I see it (and several other issues) was already raised in http://austingroupbugs.net/view.php?id=1100 which was rejected. The grammar in the suggested resolution there makes a lot more sense to me than the current one but that may be down to me missing some background on yacc parsing and misunderstanding how it works. Since 1100 was rejected, shouldn't the other issues it was meant to factorize (which doesn't include this one though) and were closed as duplicate reopened? -- Stephane
Re: x[ as first word in sh
2019-07-29 21:33:50 +0100, Stephane Chazelas: [...] > BTW, what's the point of 2.10.2 7a? It seems 7b already says > what 7a says (if the TOKEN doesn't contain a =, then rule 1 > applies). The distinction seems to be caused by the distinction > between cmd_name vs cmd_word grammar rules which seems to be > about keywords not being recognised after redirections or > assignments, but I can't see how 7a/7b help there. [...] It seems it was broken in the 2016 edition by the resolution of http://austingroupbugs.net/view.php?id=839 -- Stephane
Re: x[ as first word in sh
2019-07-29 13:30:56 -0500, Eric Blake: > On 7/29/19 1:08 PM, Stephane Chazelas wrote: [...] > > I had the vague recollection that there was but I can't find it > > now. If there's not, that would be a bug in the spec as several > > shells including ksh, bash, zsh, yash treat it as the start of > > an array element assignment (like in: [...] Sorry, I was wrong about yash. Array element assignment in yash is done with the "array" builtin. > > x[ foo > > + 1]=value > > Ouch. I think you've identified a real problem. Not that big a problem as I don't expect anyone would use "x[" in the first word of a command. Thanks for double-checking. I thought there was text that explicitely allowed that ksh behaviour, maybe I was confusing with [[...]] or ((...)). BTW, what's the point of 2.10.2 7a? It seems 7b already says what 7a says (if the TOKEN doesn't contain a =, then rule 1 applies). The distinction seems to be caused by the distinction between cmd_name vs cmd_word grammar rules which seems to be about keywords not being recognised after redirections or assignments, but I can't see how 7a/7b help there. -- Stephane
Re: x[ as first word in sh
On 7/29/19 1:08 PM, Stephane Chazelas wrote: > That's a follow-up on > https://www.mail-archive.com/bug-bash@gnu.org/msg23451.html > > Is there anything in the POSIX spec that allows: > > x[ foo > > To be interpreted as anything other than invoking the "x[" > command with "foo" as argument? > > I had the vague recollection that there was but I can't find it > now. If there's not, that would be a bug in the spec as several > shells including ksh, bash, zsh, yash treat it as the start of > an array element assignment (like in: > > x[ foo > + 1]=value Ouch. I think you've identified a real problem. In XSH 2.13.3, we explicitly added wording to allow unmatched unquoted '[' in a word to be used in its role similar to 'test' (the difference being whether a later ']' argument is necessary): If the pattern contains an open bracket ( '[' ) that does not introduce a bracket expression as in XBD RE Bracket Expression, ... If the pattern does not match any existing filenames or pathnames, the pattern string shall be left unchanged. So by that argument, if the shell parses 'x[' as a word, then because it does not form a valid glob, it must be used unchanged as the command name. But that explicit wording does not cover whether 'x[' has to be delimited as a word. XSH 2.3 states in rule 7 that an unquoted blank ends the delimiting of any prior word, but the behavior you are showing for shells that parse a[b]= as an array assignment are trying to find the matching ] before delimiting the first word (so the shell extension of array assignment is somehow acting as a quoting context that prevents the whitespace thus parsed from being the unquoted blank that ends the delimiting of the word). The shell grammar, at XSH 2.10.1, allows for array assignments in rule 7b: If the TOKEN contains an unquoted (as determined while applying rule 4 from Token Recognition) character that is not part of an embedded parameter expansion, command substitution, or arithmetic expansion construct (as determined while applying rule 5 from Token Recognition): If the TOKEN begins with '=', then rule 1 shall be applied. If all the characters in the TOKEN preceding the first such form a valid name (see XBD Name), the token ASSIGNMENT_WORD shall be returned. Otherwise, it is unspecified whether rule 1 is applied or ASSIGNMENT_WORD is returned. with the intent that a[b]= can be an ASSIGNMENT_WORD in shells with array extensions, but can also be WORD for shells that treat it as glob to determine a command name. But without any explicit specification of permitting whitespace in the array arguments, it looks like there is a discrepancy between POSIX requirements and existing shell behavior. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
x[ as first word in sh
That's a follow-up on https://www.mail-archive.com/bug-bash@gnu.org/msg23451.html Is there anything in the POSIX spec that allows: x[ foo To be interpreted as anything other than invoking the "x[" command with "foo" as argument? I had the vague recollection that there was but I can't find it now. If there's not, that would be a bug in the spec as several shells including ksh, bash, zsh, yash treat it as the start of an array element assignment (like in: x[ foo + 1]=value -- Stephane
Austin Group teleconference +1 888 974 9888 PIN 618 156 403
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1// CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:20120311T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:20121104T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:5d3f1d9aef...@opengroup.org DTSTAMP:20190729T162355Z ATTENDEE;ROLE=CHAIR:MAILTO:g.cl...@opengroup.org CREATED:20190729T00Z DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 05-Aug-2019 at 11: 00 America/New_York\nDuration: 1.00 hours\nURL: https://collaboration.open group.org/platform/single_unix_specification/events.php\n\n** All calls ar e anchored on US time **\n\nTopic: Austin Group teleconference\n-- -\nAudio conference informatio n\n---\n\nYou are invi ted to a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, iOS or Android: https://logitech.zoom.us/j/618156403\n \nor join by phone: \nUS: 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n \nOther international numbers available here:\nhttps://zoom.us/u/adlvr b8ILj\n \nMeeting ID: 618 156 403\n\nor join from a H.323/SIP Device: \nDial: 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeetin g ID: 618 156 403\n\nShare from a PC or MAC: https://zoom.us/share/6181564 03\n\nOr iPhone one-tap (US Toll): +16699006833\,618156403# or +164655886 56\,618156403#\n\nAll Austin Group participants are most welcome to join t he call.\nThe call will last for 1 hour.\nThis call is handling defect rep ort processing.\n\nAn etherpad is usually up for a meeting\, with a URL us ing the date format as below:\n\nhttp://posix.rhansen.org/p/201x-mm-dd\nus ername=posix password=2115756#\n\nBug reports are available at:\nhttp://ww w.austingroupbugs.net\n DTSTART;TZID=America/New_York:20190805T11 DURATION:PT1H0M0S LAST-MODIFIED:20190729T172355Z ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403 TRANSP:OPAQUE URL:https://collaboration.opengroup.org/platform/single_unix_specification/ events.php X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-VISIBILITY:40 X-JOINBEFORE:5 X-CATEGORY:Teleconference X-PLATO-SITE:Single UNIX Specification X-PLATO-SITEID:136 END:VEVENT END:VCALENDAR meeting.ics Description: application/ics
Draft minutes of the 29th July 2019 Teleconference
These are the draft minutes from today's call. Andrew will need to allocate the Austin-xxx document number and add the file to the document register after he returns. Regards, Geoff. --- Minutes of the 29th July 2019 Teleconference Austin-xxx Page 1 of 1 Submitted by Geoff Clare, The Open Group. 29th July 2019 Attendees: Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Mark Ziegast, SHware Systems Dev. Don Cragun, IEEE PASC OR Geoff Clare, The Open Group Eric Blake, Red Hat, Open Group OR Joerg Schilling, FOKUS Fraunhofer Apologies: Andrew Josey * General news None * Outstanding actions (Please note that this section has been flushed to shorten the minutes - to locate the previous set of outstanding actions, look to the minutes from 13th June 2019 and earlier) Bug 1220: Add an API to query the name of a locale category of a locale object OPEN http://austingroupbugs.net/view.php?id=1220 Action: Eric to ask if The Open Group is willing to sponsor this interface. * Current Business Bug 1234: in most shells, backslash doesn't have two meaning wrt pattern matchingOPEN http://austingroupbugs.net/view.php?id=1234 We agreed this item is still undergoing some discussions on the reflector and we will revisit status at a future meeting. Bug 1254: "asynchronous list" description uses "command" instead of "AND-OR list" OPEN http://austingroupbugs.net/view.php?id=1254 Action: Joerg to investigate how his shell behaves. Bug 1262: 941 fix incorrectly appliedAccepted as Marked http://austingroupbugs.net/view.php?id=1262 This item is tagged for TC3-2008. Change: read response if printf "%s\n" "$response" | grep -- -Eq "$(locale yesexpr)" to: IFS= read -r response if printf "%s\n" "$response" | grep -Eq -- "$(locale yesexpr)" Bug 1263: Add ppoll() OPEN http://austingroupbugs.net/view.php?id=1263 Action: Eric to ask if The Open Group is willing to sponsor this interface. Bug 1264: "default locale" inadequately specified in newlocale() Accepted as Marked http://austingroupbugs.net/view.php?id=1264 This item is tagged for TC3-2008. An interpretation is required. Interpretation response The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: - There are several different uses of "default" and it is not clear which one should apply here. Notes to the Editor (not part of this interpretation): --- On page 1392 line 46282 section newlocale(), change: default locale to: POSIX locale Bug 1265: Knock-on effects of Issue 7 change to XCU 2.8.1 OPEN http://austingroupbugs.net/view.php?id=1265 This item was discussed and will be continued next time. Next Steps -- The next calls are on: August 1 2019 (Thursday) This call will be for 90 minutes. August 5 2019 (Monday) This call will be for 60 minutes. Apologies in advance: Andrew Josey, 2019-08-01, 2019-08-05, 2019-08-08 Calls are anchored on US time. (8am Pacific) Please check the calendar invites for dial in details. http://austingroupbugs.net An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/201x-mm-dd username=posix password=2115756# -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[1003.1(2016)/Issue7+TC2 0001264]: "default locale" inadequately specified in newlocale()
The following issue NEEDS AN INTERPRETATION. == http://austingroupbugs.net/view.php?id=1264 == Reported By:shware_systems Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1264 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: Interpretation Required Name: Mark Ziegast Organization: SHware Systems Dev. User Reference: Section:newlocale(), others Page Number:1392 Line Number:46280-2 Interp Status: Pending Final Accepted Text:http://austingroupbugs.net/view.php?id=1264#c4500 == Date Submitted: 2019-06-27 19:01 UTC Last Modified: 2019-07-29 15:42 UTC == Summary:"default locale" inadequately specified in newlocale() == Issue History Date ModifiedUsername FieldChange == 2019-06-27 19:01 shware_systems New Issue 2019-06-27 19:01 shware_systems Name => Mark Ziegast 2019-06-27 19:01 shware_systems Organization => SHware Systems Dev. 2019-06-27 19:01 shware_systems Section => newlocale(), others 2019-06-27 19:01 shware_systems Page Number => 1392 2019-06-27 19:01 shware_systems Line Number => 46280-2 2019-06-28 03:36 Don Cragun Note Added: 0004456 2019-07-04 17:09 shware_systems Note Added: 0004473 2019-07-04 19:38 Don Cragun Note Added: 0004474 2019-07-04 19:39 Don Cragun Note Edited: 0004474 2019-07-05 08:39 geoffclare Note Added: 0004475 2019-07-05 14:45 geoffclare Note Added: 0004476 2019-07-05 17:53 shware_systems Note Added: 0004477 2019-07-29 15:41 geoffclare Note Added: 0004500 2019-07-29 15:42 geoffclare Interp Status => Pending 2019-07-29 15:42 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1264#c4500 2019-07-29 15:42 geoffclare Status New => Interpretation Required 2019-07-29 15:42 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2016)/Issue7+TC2 0001264]: "default locale" inadequately specified in newlocale()
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1264 == Reported By:shware_systems Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1264 Category: System Interfaces Type: Clarification Requested Severity: Objection Priority: normal Status: New Name: Mark Ziegast Organization: SHware Systems Dev. User Reference: Section:newlocale(), others Page Number:1392 Line Number:46280-2 Interp Status: --- Final Accepted Text: == Date Submitted: 2019-06-27 19:01 UTC Last Modified: 2019-07-29 15:41 UTC == Summary:"default locale" inadequately specified in newlocale() == -- (0004500) geoffclare (manager) - 2019-07-29 15:41 http://austingroupbugs.net/view.php?id=1264#c4500 -- Interpretation response The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: - There are several different uses of "default" and it is not clear which one should apply here. Notes to the Editor (not part of this interpretation): --- On page 1392 line 46282 section newlocale(), change:default localeto:POSIX locale Issue History Date ModifiedUsername FieldChange == 2019-06-27 19:01 shware_systems New Issue 2019-06-27 19:01 shware_systems Name => Mark Ziegast 2019-06-27 19:01 shware_systems Organization => SHware Systems Dev. 2019-06-27 19:01 shware_systems Section => newlocale(), others 2019-06-27 19:01 shware_systems Page Number => 1392 2019-06-27 19:01 shware_systems Line Number => 46280-2 2019-06-28 03:36 Don Cragun Note Added: 0004456 2019-07-04 17:09 shware_systems Note Added: 0004473 2019-07-04 19:38 Don Cragun Note Added: 0004474 2019-07-04 19:39 Don Cragun Note Edited: 0004474 2019-07-05 08:39 geoffclare Note Added: 0004475 2019-07-05 14:45 geoffclare Note Added: 0004476 2019-07-05 17:53 shware_systems Note Added: 0004477 2019-07-29 15:41 geoffclare Note Added: 0004500 ==
Re: [1003.1(2016)/Issue7+TC2 0001273]: glob()'s GLOB_ERR/errfunc and non-directory files
2019-07-29 13:13:03 +0100, Stephane Chazelas: [...] > For the ENOTDIR ignoring in GNU libc, that was in 1999 following > a bug report (libc/1032 which I coudn't find). See > https://sourceware.org/git/?p=glibc.git;a=commit;h=647361287ddb2d52ffe9dbbfe2bd27ed76dc2c56 [...] The bug report can be seen at https://sourceware.org/ml/libc-alpha/1999-q1/msg00498.html Somebody noted that Solaris 7 had the same problem, but it was fixed nonetheless https://sourceware.org/ml/libc-alpha/1999-05/msg4.html -- Stephane
[1003.1(2016)/Issue7+TC2 0001262]: bugid:941 fix incorrectly applied
The following issue has been RESOLVED. == http://austingroupbugs.net/view.php?id=1262 == Reported By:stephane Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1262 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: Resolved Name: Stephane Chazelas Organization: User Reference: http://austingroupbugs.net/view.php?id=941 Section:locale utility Page Number:2907 Line Number:96034 (in the 2018 edition) Interp Status: --- Final Accepted Text:http://austingroupbugs.net/view.php?id=1262#c4499 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2019-06-15 08:51 UTC Last Modified: 2019-07-29 15:13 UTC == Summary:http://austingroupbugs.net/view.php?id=941 fix incorrectly applied == Issue History Date ModifiedUsername FieldChange == 2019-06-15 08:51 stephane New Issue 2019-06-15 08:51 stephane Name => Stephane Chazelas 2019-06-15 08:51 stephane User Reference=> http://austingroupbugs.net/view.php?id=941 2019-06-15 08:51 stephane Section => locale utility 2019-06-15 08:51 stephane Line Number => 96034 (in the 2018 edition) 2019-06-24 17:53 Don Cragun Page Number => 2907 2019-06-24 17:53 Don Cragun Interp Status => --- 2019-07-29 15:12 geoffclare Note Added: 0004499 2019-07-29 15:13 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1262#c4499 2019-07-29 15:13 geoffclare Status New => Resolved 2019-07-29 15:13 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2016)/Issue7+TC2 0001262]: bugid:941 fix incorrectly applied
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1262 == Reported By:stephane Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1262 Category: Shell and Utilities Type: Error Severity: Objection Priority: normal Status: New Name: Stephane Chazelas Organization: User Reference: http://austingroupbugs.net/view.php?id=941 Section:locale utility Page Number:2907 Line Number:96034 (in the 2018 edition) Interp Status: --- Final Accepted Text: == Date Submitted: 2019-06-15 08:51 UTC Last Modified: 2019-07-29 15:12 UTC == Summary:http://austingroupbugs.net/view.php?id=941 fix incorrectly applied == -- (0004499) geoffclare (manager) - 2019-07-29 15:12 http://austingroupbugs.net/view.php?id=1262#c4499 -- Change: read response if printf "%s\n" "$response" | grep -- -Eq "$(locale yesexpr)" to: IFS= read -r response if printf "%s\n" "$response" | grep -Eq -- "$(locale yesexpr)" Issue History Date ModifiedUsername FieldChange == 2019-06-15 08:51 stephane New Issue 2019-06-15 08:51 stephane Name => Stephane Chazelas 2019-06-15 08:51 stephane User Reference=> http://austingroupbugs.net/view.php?id=941 2019-06-15 08:51 stephane Section => locale utility 2019-06-15 08:51 stephane Line Number => 96034 (in the 2018 edition) 2019-06-24 17:53 Don Cragun Page Number => 2907 2019-06-24 17:53 Don Cragun Interp Status => --- 2019-07-29 15:12 geoffclare Note Added: 0004499 ==
Re: [1003.1(2016)/Issue7+TC2 0001273]: glob()'s GLOB_ERR/errfunc and non-directory files
2019-07-29 13:13:03 +0100, Stephane Chazelas: [...] > NetBSD has this comment in the code: > > /* > * Posix/XOpen: glob should return when it encounters a > * directory that it cannot open or read > * XXX: Should we ignore ENOTDIR and ENOENT though? > * I think that Posix had in mind EPERM... > */ [...] OpenBSD has: /* TODO: don't call for ENOENT or ENOTDIR? */ the same as in FreeBSD before the 2016 fix. It's the same comment that could be found in 1990 in the BSD code, when the glob() function was added. It can be found in tcsh, nvi, sudo and perl code as well. And in opensolaris/illumos glob(). Most likely that TODO is still in the Solaris code. glob(3) is a POSIX invention, isn't it? I couldn't find it in SVR4. I wonder how other SYSV-derived OSes (and that don't have a BSD heritage like Solaris) behave. uclibc, musl and dietlibc behave like GNU (ignore ENOTDIR, not ENOENT) AFAICT from reading the code. musl seems to do some extra processing on EACCESS, I've not looked much further into it. -- Stephane
Re: [1003.1(2016)/Issue7+TC2 0001273]: glob()'s GLOB_ERR/errfunc and non-directory files
2019-07-29 12:12:28 +0100, Geoff Clare: [...] > > in */*.c, Solaris returns with an error if the current directory > > contains a non-directory file (and calls errfunc() with ENOTDIR > > and that file), which is not wanted. > > True, but there's no way round that because GLOB_ERR can't distinguish > these cases. It's "all or nothing". > > > IMO, GLOB_ERR should be about failure to expand the glob. > > The ENOTDIR error when expanding /etc/passwd/*.c is not > > preventing the glob from expanding (to nothing). If passwd was a > > symlink to some inaccessible area, then it would. > > To me the point of having GLOB_ERR and errfunc as two different > error reporting mechanisms is that GLOB_ERR is "all or nothing" > and errfunc lets you be more selective. You said yourself in the bug > that the Solaris behaviour is "more flexible in that the caller can > use a errfunc that ignores ENOENT/ENOTDIR to emulate the GNU/FreeBSD > behaviour". [...] Yes, but to me that sounds more like the Solaris behaviour is bogus and there's a way to work around it. >From https://reviews.freebsd.org/rS304284 https://reviews.freebsd.org/rS304284#C38376190OL661 FreeBSD implementated that ignoring of ENOENT/ENOTDIR for POSIX compliance in 2016. For the ENOTDIR ignoring in GNU libc, that was in 1999 following a bug report (libc/1032 which I coudn't find). See https://sourceware.org/git/?p=glibc.git;a=commit;h=647361287ddb2d52ffe9dbbfe2bd27ed76dc2c56 NetBSD has this comment in the code: /* * Posix/XOpen: glob should return when it encounters a * directory that it cannot open or read * XXX: Should we ignore ENOTDIR and ENOENT though? * I think that Posix had in mind EPERM... */ (ITTM EACCESS). -- Stephane
Re: [1003.1(2016)/Issue7+TC2 0001273]: glob()'s GLOB_ERR/errfunc and non-directory files
Stephane Chazelas wrote, on 29 Jul 2019: > > 2019-07-29 11:43:11 +0100, Geoff Clare: > [...] > > > But here I'm saying that the ENOENT/ENOTDIR errors should be > > > ignored with GLOB_ERR. It can already be implied to some extent > > > in that if you get those errors then it's not "directories" > > > you're trying to open (so it's not a case there "it encounters a > > > *directory* that it cannot open or read), but still the Solaris > > > implementation (for both ENOENT and ENOTDIR) and GNU > > > implementations (for ENOENT) still return errors. > > > > I think you're interpreting the current text too literally. My > > reading is that it is trying to describe what happens when glob() > > attempts to open what it expects to be a directory and gets an error. > > The Solaris behaviour seems like the right thing to do. If an > > application calls glob() to expand /etc/passwd/*.c without GLOB_NOCHECK > > and with GLOB_ERR then I think the application writer would want glob() > > to indicate that there's a problem with the pattern, not just that there > > are no matches. > [...] > > But then > > in */*.c, Solaris returns with an error if the current directory > contains a non-directory file (and calls errfunc() with ENOTDIR > and that file), which is not wanted. True, but there's no way round that because GLOB_ERR can't distinguish these cases. It's "all or nothing". > IMO, GLOB_ERR should be about failure to expand the glob. > The ENOTDIR error when expanding /etc/passwd/*.c is not > preventing the glob from expanding (to nothing). If passwd was a > symlink to some inaccessible area, then it would. To me the point of having GLOB_ERR and errfunc as two different error reporting mechanisms is that GLOB_ERR is "all or nothing" and errfunc lets you be more selective. You said yourself in the bug that the Solaris behaviour is "more flexible in that the caller can use a errfunc that ignores ENOENT/ENOTDIR to emulate the GNU/FreeBSD behaviour". -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001273]: glob()'s GLOB_ERR/errfunc and non-directory files
2019-07-29 11:43:11 +0100, Geoff Clare: [...] > > But here I'm saying that the ENOENT/ENOTDIR errors should be > > ignored with GLOB_ERR. It can already be implied to some extent > > in that if you get those errors then it's not "directories" > > you're trying to open (so it's not a case there "it encounters a > > *directory* that it cannot open or read), but still the Solaris > > implementation (for both ENOENT and ENOTDIR) and GNU > > implementations (for ENOENT) still return errors. > > I think you're interpreting the current text too literally. My > reading is that it is trying to describe what happens when glob() > attempts to open what it expects to be a directory and gets an error. > The Solaris behaviour seems like the right thing to do. If an > application calls glob() to expand /etc/passwd/*.c without GLOB_NOCHECK > and with GLOB_ERR then I think the application writer would want glob() > to indicate that there's a problem with the pattern, not just that there > are no matches. [...] But then in */*.c, Solaris returns with an error if the current directory contains a non-directory file (and calls errfunc() with ENOTDIR and that file), which is not wanted. IMO, GLOB_ERR should be about failure to expand the glob. The ENOTDIR error when expanding /etc/passwd/*.c is not preventing the glob from expanding (to nothing). If passwd was a symlink to some inaccessible area, then it would. (but again, there's the problem of lstat() failures that are not reported, but that's a different problem). -- Stephane
Re: [1003.1(2016)/Issue7+TC2 0001273]: glob()'s GLOB_ERR/errfunc and non-directory files
Stephane Chazelas wrote, on 29 Jul 2019: > > 2019-07-29 10:45:35 +0100, Geoff Clare: > [...] > > I noticed the same problem when I was working on the wording changes > > to glob() as part of the pathname expansion fixes that arose from > > bug 1255, which is why the proposed change in my email on 25th July > > had: > > > > | In glob() change GLOB_ERR from: > > | > > | Cause glob() to return when it encounters a directory that it > > | cannot open or read. Ordinarily, glob() continues to find matches. > > | > > | to: > > | > > | Cause glob() to return when an attempt to open, read or search a > > | directory fails because of an error condition that is related to > > | file system contents. If this flag is not set, glob() shall > > | not treat such conditions as an error, and shall continue to > > | look for matches. > > > > plus similar fixes further down the page. > [...] > > But here I'm saying that the ENOENT/ENOTDIR errors should be > ignored with GLOB_ERR. It can already be implied to some extent > in that if you get those errors then it's not "directories" > you're trying to open (so it's not a case there "it encounters a > *directory* that it cannot open or read), but still the Solaris > implementation (for both ENOENT and ENOTDIR) and GNU > implementations (for ENOENT) still return errors. I think you're interpreting the current text too literally. My reading is that it is trying to describe what happens when glob() attempts to open what it expects to be a directory and gets an error. The Solaris behaviour seems like the right thing to do. If an application calls glob() to expand /etc/passwd/*.c without GLOB_NOCHECK and with GLOB_ERR then I think the application writer would want glob() to indicate that there's a problem with the pattern, not just that there are no matches. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: [1003.1(2016)/Issue7+TC2 0001273]: glob()'s GLOB_ERR/errfunc and non-directory files
2019-07-29 10:45:35 +0100, Geoff Clare: [...] > I noticed the same problem when I was working on the wording changes > to glob() as part of the pathname expansion fixes that arose from > bug 1255, which is why the proposed change in my email on 25th July > had: > > | In glob() change GLOB_ERR from: > | > | Cause glob() to return when it encounters a directory that it > | cannot open or read. Ordinarily, glob() continues to find matches. > | > | to: > | > | Cause glob() to return when an attempt to open, read or search a > | directory fails because of an error condition that is related to > | file system contents. If this flag is not set, glob() shall > | not treat such conditions as an error, and shall continue to > | look for matches. > > plus similar fixes further down the page. [...] But here I'm saying that the ENOENT/ENOTDIR errors should be ignored with GLOB_ERR. It can already be implied to some extent in that if you get those errors then it's not "directories" you're trying to open (so it's not a case there "it encounters a *directory* that it cannot open or read), but still the Solaris implementation (for both ENOENT and ENOTDIR) and GNU implementations (for ENOENT) still return errors. -- Stephane
Re: [1003.1(2016)/Issue7+TC2 0001273]: glob()'s GLOB_ERR/errfunc and non-directory files
Austin Group Bug Tracker wrote, on 27 Jul 2019: > > The following issue has been SUBMITTED. > == > http://austingroupbugs.net/view.php?id=1273 > == > In the XSH glob() specification, > > For GLOB_ERR, the spec says: > > > Cause glob() to return when it encounters a directory that it > > cannot open or read. Ordinarily, glob() continues to find > > matches. I noticed the same problem when I was working on the wording changes to glob() as part of the pathname expansion fixes that arose from bug 1255, which is why the proposed change in my email on 25th July had: | In glob() change GLOB_ERR from: | | Cause glob() to return when it encounters a directory that it | cannot open or read. Ordinarily, glob() continues to find matches. | | to: | | Cause glob() to return when an attempt to open, read or search a | directory fails because of an error condition that is related to | file system contents. If this flag is not set, glob() shall | not treat such conditions as an error, and shall continue to | look for matches. plus similar fixes further down the page. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[1003.1(2016)/Issue7+TC2 0001274]: pid_t must fit in an int for definition of fcntl to be consistent.
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1274 == Reported By:dannyniu Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1274 Category: Base Definitions and Headers Type: Omission Severity: Editorial Priority: normal Status: New Name: DannyNiu/NJF Organization: Individual User Reference: Section: header Page Number:402-405 Line Number:13652-13746 Interp Status: --- Final Accepted Text: == Date Submitted: 2019-07-28 10:42 UTC Last Modified: 2019-07-29 09:08 UTC == Summary:pid_t must fit in an int for definition of fcntl to be consistent. == -- (0004498) geoffclare (manager) - 2019-07-29 09:08 http://austingroupbugs.net/view.php?id=1274#c4498 -- There is no problem with F_GETOWN here because the value to be returned is guaranteed to be able to fit in an int. This is because it is set via an int argument passed to fcntl() with F_SETOWN. (Okay, there might be an extension that could be used to set it to a larger value, but then there would be an equivalent extension to query it as well.) So the only real problem I see is that it is not possible for a process with a PID greater than INT_MAX or a process group with a PGID greater than INT_MAX+1 to be set to receive SIGURG signals (without using an extension). One solution would be to require that process IDs are always <= INT_MAX. Another would be to make F_SETOWN and F_GETOWN obsolescent and warn about the problem in APPLICATION USAGE. There is certainly no need to alter the requirements about how pid_t can be defined. Issue History Date ModifiedUsername FieldChange == 2019-07-28 10:42 dannyniu New Issue 2019-07-28 10:42 dannyniu Name => DannyNiu/NJF 2019-07-28 10:42 dannyniu Organization => Individual 2019-07-28 10:42 dannyniu Section => header 2019-07-28 10:42 dannyniu Page Number => 402-405 2019-07-28 10:42 dannyniu Line Number => 13652-13746 2019-07-28 13:49 jilles Note Added: 0004496 2019-07-29 00:52 shware_systems Note Added: 0004497 2019-07-29 09:08 geoffclare Note Added: 0004498 ==
