Date: Tue, 30 Jul 2019 12:43:54 +0100
From: Stephane Chazelas <stephane.chaze...@gmail.com>
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 uses there are) from ever
returning any error status or issuing any error messages from operations
related to its path search -- errors from shell memory management - exhausing
available mem because the list of found paths contains too manny and they're
too long, or similar problems, is a different issue .. similarly if the
shell needs to fork because of the way its glob code is implemented, and
the fork fails, or in such a case if the shell needs a pipe to, or shared
memory with, its child to receive the results, and that fails to be
stablished.
Glob isn't the right tool (it isn't a tool at all) to find file system
problems, whether they're problems we generally want glob to hide
(ENOTDIR because the first '*' in */*.c matched a regular file, or
ENOTDIR which might be because a directory inode got corrupted and is
now appearing to the filesystem as if it were a regular file, or a fifo
or something) EIO, errors about symlink loops, or absurldly long pathnames
or pathname components, or anything else (including EMFILE and ENFILE).
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.
If glob fails to match files that the user thought should be matched, then
the user needs to investigate - whether the cause eventually is determined
to be incoprrect permissions somewhere, a typo in the script or an arg given
to the script (incorrect name), over long pathnames, symlink loops,
or bad blocks on the drive; other tools will find that (ls, find, even cat
or cp). There's no real advantage having glob trying to deal with all
these cases, nor in attempting to divide up the errrors between the "good"
ones and the "bad" ones - there's no way to do that that will satisfy
everyone, as this dispute over ELOOP (etc) shows.
What's more, frankly, it is ludicrous to claim that a script should
abort itself when one of these (quite rare) errors occurs, because it
might do the wrong thing, while at the same time proclaiming that it
has to continue for one of the much more common errors (like bad permission
settings causeing EACCES or a typing mistake generating ENOENT or ENOTDIR).
If the script is going to do the wrong thing in one case, it will do the
same wrong thing in the other case as well.
kre
