bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bash handling of ENOENT on missing files and directories


From: Jonny Grant
Subject: Re: Bash handling of ENOENT on missing files and directories
Date: Tue, 19 Sep 2017 11:40:35 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0



On 17/09/17 06:25, Robert Elz wrote:
     Date:        Mon, 11 Sep 2017 22:49:47 +0300
     From:        Jonny Grant <jg@jguk.org>
     Message-ID:  <c3a2528c-ccbc-c8ad-66fe-52ec98a0cfb5@jguk.org>

   | How can an easy update to clarify message "No such file or directory"
   | introduce a bug?

That's easy ... because it is not just that one message, you change that
to "no directory" (or something) in the case of the cd command, then someone
has to come along and produce the Polish, French, Mandarin, Tagalog, Malay,
Afrikaans, Spanish, Thai, .... versions of that new message, and it is
entirely possible that one or more or those won't end up saying exactly
what it should say.   A bug...

The sys_errlist[] messages are translated already, and widely used, so
any errors in those translations should have already been found and fixed.

kre

Hello Robert

Thank you for your reply. I've proposed at the end of this message an easy solution which doesn't require any additional translation.

In the case where a file exits, the message is appropriate:

$ touch myfile.txt
$ cd myfile.txt
bash: cd: myfile.txt: Not a directory

* This is because opendir sets errno to be ENOTDIR

In the case where the directory doesn't exist, opendir returns ENOENT and the message is not appropriate

$ cd mymissingdir
bash: cd: mymissingdir: No such file or directory



Yes, I appreciate that because the limitation ENOENT doesn't differentiate, it means every application that wants to be multilingual could have a bad translation if the developers don't treat this change professionally.

Better if it was fixed at in the UNIX/POSIX standards, but alas I can't imagine that ever happening, so then better to resolve this in each package in my view, which is why I raised it.

Would have been better to have ENOENT split into two different codes by the standards, one for files and one for directories. ie open() set ENOENTF and opendir() set ENOENTD


POSIX man pages:

http://pubs.opengroup.org/onlinepubs/009695399/functions/opendir.html
http://man7.org/linux/man-pages/man3/opendir.3.html


The easiest workaround is after opendir() to check for ENOENT. You don't need to do any additional translations.

if(NULL == dir)
{
        int err = errno;
        if(ENOENT == err)
        {
                /* Aathis is opendir(), update error to dir, so clear */
                err = ENOTDIR;
        }

        printf("opendir: %s\n", strerror(err));
}

I'm sure you all know this better than myself. We shouldn't be fearful of changing code. That prevents projects moving forward. Testsuites can be used to give added confidence in changes.

Cheers, Jonny



reply via email to

[Prev in Thread] Current Thread [Next in Thread]