Re: Bash handling of ENOENT on missing files and directories

[Jonny Grant]

Hello Bob
Thank you for your reply

On 15/09/17 02:57, Bob Proulx wrote:
> Jonny Grant wrote:
> > Please keep my email address in any replies
> >
> > Bob Proulx wrote:
> > > Jonny Grant wrote:
> > > > Yes, it's a known limitation of POSIX that it uses a shared error code for
> > > > both files and directors, ENOENT. Which without programmers handling and
> > > > checking the stat() flags, means the error isn't completely clear in the
> > > > case where a file or dir does exist.
> > >
> > > I don't see how POSIX is involved in this.  Blaming POSIX is a
> > > complete non-sequitur here.
> >
> > Why do you feel it isn't?
>
> The "No such file or directory" message I see in the Unix v7 code
> circa 1979 and therefore appeared at least that early but probably was
> there since the beginning.  That predates the first POSIX standard by
> many years.
>
> File errlst.c:
> char    *sys_errlist[] = {
>         "Error 0",
>         "Not owner",
>         "No such file or directory",
>          ...
>
> File errno.h:
> #define ENOENT  2

Fair enough. I agree it has been around for longer, but meant that POSIX 
standardized on that limitation, and didn't offer a better solution that 
clarified, eg ENOENTF ENOENTD



> > > > I imagine we have spoken already for longer about this, than it would have
> > > > been to fix it.
> > >
> > > I see no bug to fix here.  However I fear that trying to fix an
> > > imaginary one would introduce a bug here.
> >
> > How can an easy update to clarify message "No such file or directory"
> > introduce a bug?
>
> Because "No such file or directory" is the exact error message that
> corresponds to the error returned by the OS kernel as defined by the
> system in the /usr/include definition file which is used by all
> programs.  It is an important commonality.  All programs should say
> the same thing for that error.

yes, a clearer errno value, for files, and separate for directories 
would be ideal.


> If every program created a different error message for that error then
> it would be hard to learn what each and every program said for each
> and every individual possible error.  OMG!  That would be horrible.
> Changing it to make it something different would obscure the error
> that is being returned by the OS.  It would make this one program say
> something different for that error than other programs.  Different
> makes it harder to understand.

Most programs already use their own messages. eg GEdit :-
Could not find the file “/home/jonny/env.txt”.
Please check that you typed the location correctly and try again.
[Retry] [Cancel]


> Let's look at your cases again.
>
> > $ cd missingdir
> > bash: cd: missingdir: No such file or directory
>
> Why do you think that is undesirable?  That is the system error.  The
> requested "missingdir" to change directory to failed because there is
> no entry by that name, uh, no such file or directory by that name. :-)

Has anyone ever wanted to "cd" into a file?

> > Likewise, software that deals with directories, or in the case of
> > "cd" in bash, trying to change directory, can very easily report "No
> > such directory"
>
> I think some of the problem might be that you are thinking that
> directories are not files.  But in Unix like systems everything is a
> file.  (And in a Linux like system everything is a file system.  It's
> a joke but also with some truth to it.)

yes, I know directories are a kind of special file, but from a user's 
perspective, nowadays they are just folders.

> If I were writing that error message I may have said "No such entry"
> since that is the literal error.  Meaning directory entry.  But I
> could see having written "No such file", stopped there without the
> directory hint, and defended it as being correct because everything is
> a file.  But I forgive them for helping the user out a little by
> hinting that no files, not even special files such as directories,
> were found.  Directories are files.  They are special files.  But
> files just the same.
>
>    https://en.wikipedia.org/wiki/Unix_file_types
>    "The most common special file is the directory."
>
> Let's try some other shells to see what error messages they produce.
>
> $ ksh
> $ cd nonexistent
> ksh: cd: nonexistent: [No such file or directory]
>
> $ mksh
> $ cd nonexistent
> mksh: cd: /home/rwp/nonexistent: No such file or directory
> $ ^D
>
> $ zsh
> % cd nonexistent
> cd: no such file or directory: nonexistent
>
> $ csh
> % cd nonexistent
> nonexistent: No such file or directory.
> % exit
>
> We can also try a programming solution too just to double check what
> error message is provided using a one-liner.
>
>    $ perl -e 'chdir("doesnotexist") or die "$!\n";'
>    No such file or directory
>
> It is good that everyone uses the same error messages.
>
> Let's look at your other case.
>
> > $ ./main
> > -bash: ./main: No such file or directory
>
> $ ksh
> $ ./nonexistent
> ksh: ./nonexistent: not found [No such file or directory]
>
> $ mksh
> $ ./nonexistent
> mksh: ./nonexistent: not found
> $
>
> $ zsh
> % ./nonexistent
> zsh: no such file or directory: ./nonexistent
> %
>
> $ csh
> % ./non-existent
> ./non-existent: Command not found.
> % exit
>
> It looks like mksh and csh are the odd ones out here.

They are both clearer. Like you say "No such entry" above might have 
been generic enough but "Directory not found" or "File not found" are 
clearer for users.

I did propose a workaround, with a simple function on the list, but no 
response. So I'll leave it at that, unless you are happy to discuss further.

Thank you again for your replies
Jonny