Robert Elz <k...@munnari.oz.au> 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 bug 1275. > 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). 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. > If glob fails to match files that the user thought should be matched, then > the user needs to investigate The command might succeed (operating on the wrong file) and the user would not be alerted to the problem. Particularly bad if it was an rm command. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
