[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bash-bug
Subject:    Re: Bash handling of ENOENT on missing files and directories
From:       Jonny Grant <jg () jguk ! org>
Date:       2017-09-19 8:40:35
Message-ID: 3c49a921-8f51-4eb3-707d-aaf44c742733 () jguk ! org
[Download RAW message or body]



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


[prev in list] [next in list] [prev in thread] [next in thread]