A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1274
==
Reported By:dannyniu
Assigned To:
Austin Group Bug Tracker wrote, on 27 Jul 2019:
>
> The following issue has been SUBMITTED.
> ==
> http://austingroupbugs.net/view.php?id=1273
> ==
> In the
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
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
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
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"
>
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
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...
2019-07-29 13:54:43 +0100, Stephane Chazelas:
[...]
> 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.
[...]
I was looking at an old version of musl. L
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1262
==
Reported By:stephane
Assigned To:
The following issue has been RESOLVED.
==
http://austingroupbugs.net/view.php?id=1262
==
Reported By:stephane
Assigned To:
==
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
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1264
==
Reported By:shware_systems
Assigned To:
The following issue NEEDS AN INTERPRETATION.
==
http://austingroupbugs.net/view.php?id=1264
==
Reported By:shware_systems
Assigned To:
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 Op
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=YE
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
no
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?
>
>
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
> >
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
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
> 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
Rule 7 is also referenced by Rule 8, as the token may represent a function name
to be defined, and determining whether the token is an IO_NUMBER or a reference
to a file on the path also comes into play, depending on the following tokens
to disambiguate command's productions. For that 7a establ
23 matches
Mail list logo
