Additionally, when GLOB_NOCHECK is in flags it is not expected to call stat()
and return 0 paths if it does not exist. It is on the application to note the
increase in count by 1 and compare the result for match to pattern to see if it
needs to do a stat() seperately. One of the examples or
2019-08-01 15:51:10 +0100, Geoff Clare:
> Stephane Chazelas wrote, on 01 Aug 2019:
> >
> > It's also not clear what the interaction between GLOB_MARK and
> > GLOB_NOCHECK would be. If a pattern expands to itself because it
> > can't find a match, should it still call stat on it?
>
> Not clear?
Stephane Chazelas wrote, on 01 Aug 2019:
>
> It's also not clear what the interaction between GLOB_MARK and
> GLOB_NOCHECK would be. If a pattern expands to itself because it
> can't find a match, should it still call stat on it?
Not clear? Seems crystal clear to me.
GLOB_NOCHECK: "... shall
2019-07-27 10:49:39 +, Austin Group Bug Tracker:
[...]
> > If, during the search, a directory is encountered that cannot
> > be opened or read and errfunc is not a null pointer, glob()
> > calls (*errfunc()) with two arguments.
> [...]
> > 2. The eerrno argument is the value of errno
Stephane Chazelas wrote, on 30 Jul 2019:
>
> 2019-07-30 15:31:13 +0100, Geoff Clare:
> [...]
> > It's not invention because the standard already requires it. (It also
> > requires EACCES, ELOOP, ENAMETOOLONG, ENOENT, ENOTDIR to be treated as
> > errors. The question is which ones the standard
2019-07-30 15:31:13 +0100, Geoff Clare:
[...]
> It's not invention because the standard already requires it. (It also
> requires EACCES, ELOOP, ENAMETOOLONG, ENOENT, ENOTDIR to be treated as
> errors. The question is which ones the standard should be changed to
> say are ignored.)
[...]
By that
Robert Elz wrote, on 30 Jul 2019:
>
> | I strongly disagree that EMFILE and ENFILE should be ignored in the
> | shell. That leads to the execution of commands with an unchanged
> | pattern when there are matching files it should have used instead.
>
> Same thing for all the other errors.
2019-07-30 14:29:23 +0100, Geoff Clare:
[...]
> > Do you have a better suggestion?
>
> Unless one of the implementations changes to do something better
> before we get too far into work on Issue 8, I think the only
> choices we have are the Solaris behaviour, the GNU/BSD behaviour,
> the GNU/BSD
Date:Tue, 30 Jul 2019 14:39:54 +0100
From:Geoff Clare
Message-ID: <20190730133954.GB27152@lt2.masqnet>
| This thread is specifically about the glob() function in XSH.
Yes, I know, see my previous reply to Stephane.
If I replied to a message in the wrong thread,
Date:Tue, 30 Jul 2019 14:35:47 +0100
From:Stephane Chazelas
Message-ID: <20190730133547.mcqvnbaz3wmms...@chaz.gmail.com>
| While I generally agree for bugid:1275 -- for shell globs or
| glob() without GLOB_ERR
As I said (and also in response to the first part of
Robert Elz wrote, on 30 Jul 2019:
>
> My recommendation would be to forbid glob (at least in the shell,
> I don't care so much about whatever other uses there are)
This thread is specifically about the glob() function in XSH.
The similar issues with pathname expansion in the shell are
covered by
2019-07-30 20:18:43 +0700, Robert Elz:
[...]
> If a sys call executed by glob while searching fails, then it should treat
> that exactly the same as ENOENT (the thing simply doesn't exist for glob
> purposes) and continue with whatever is next.
[...]
While I generally agree for bugid:1275 -- for
Stephane Chazelas wrote, on 30 Jul 2019:
>
> 2019-07-30 11:27:15 +0100, Geoff Clare:
> [...]
> > > For ENOENT, that can be seen as a pathological case worth
> > > reporting as well, especially in the */*.c case where the
> > > current directory contains broken symlinks.
> >
> > That's
Date:Tue, 30 Jul 2019 12:43:54 +0100
From:Stephane Chazelas
Message-ID: <20190730114354.72qqdwckkidsd...@chaz.gmail.com>
| Do you have a better suggestion?
My recommendation would be to forbid glob (at least in the shell,
I don't care so much about whatever other
2019-07-30 11:27:15 +0100, Geoff Clare:
[...]
> > For ENOENT, that can be seen as a pathological case worth
> > reporting as well, especially in the */*.c case where the
> > current directory contains broken symlinks.
>
> That's inconsistent with your position on ENOTDIR.
>
> If regfile exists
2019-07-30 10:48:49 +0100, Geoff Clare:
[...]
> The odd thing about all these implementations that ignore ENOTDIR and ENOENT
> (or don't but think they should), is that they are not following either of
> the possible interpretations of the current text.
>
> If they want to interpret it literally
Stephane Chazelas wrote, on 29 Jul 2019:
>
> 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
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
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 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
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 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 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 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
Austin Group Bug Tracker wrote, on 27 Jul 2019:
>
> The following issue has been SUBMITTED.
> ==
> http://austingroupbugs.net/view.php?id=1273
> ==
> In the
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1273
==
Reported By:stephane
Assigned To:
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1273
==
Reported By:stephane
Assigned To:
A NOTE has been added to this issue.
==
http://austingroupbugs.net/view.php?id=1273
==
Reported By:stephane
Assigned To:
The following issue has been UPDATED.
==
http://austingroupbugs.net/view.php?id=1273
==
Reported By:stephane
Assigned To:
2019-07-27 10:49:39 +, Austin Group Bug Tracker:
[...]
> Category: Shell and Utilities
[...]
Sorry, my bad that should have been "System interfaces". It
doesn't seem I can change it after the fact.
--
Stephane
The following issue has been SUBMITTED.
==
http://austingroupbugs.net/view.php?id=1273
==
Reported By:stephane
Assigned To:
31 matches
Mail list logo
