|
From: | Pádraig Brady |
Subject: | bug#13447: ln "" foo gives misleading error message |
Date: | Tue, 15 Jan 2013 09:53:22 +0000 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 |
On 01/15/2013 09:31 AM, Jim Meyering wrote:
Pádraig Brady wrote:On 01/15/2013 08:23 AM, Ken Irving wrote:(Previously sent in error to the bug-gnu-utils list.) I've been using symbolic links in a non-file-related way, e.g., to store arbitrary string values, but find that if I try to create a symlink with an empty 'target' name, e.g., as 'ln -s "" foo', the error message emitted is not really correct. $ ln -s "" foo ln: creating symbolic link `foo' -> `': No such file or directory $ ln -sf "" foo ln: creating symbolic link `foo' -> `': No such file or directory A link can be created when no file or directory exists, e.g., $ stat x || ln -s x foo && echo ok stat: cannot stat `x': No such file or directory ok so it seems that 'No such file or directory' must not be the actual reason for the failure. Perhaps something like 'null target name' would be more accurate? I only happened upon this in working on a test script, and have no expectation for the operation to succeed.We're just reporting what the operating system returns here: $ python -c 'import os; os.symlink("","tl")' Traceback (most recent call last): File "<string>", line 1, in <module> OSError: [Errno 2] No such file or directory Interestingly I notice that solaris for example allows a NULL old_path.That Solaris behavior is contrary to POSIX 2008 http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html
The POSIX ENOENT description only mentions the empty path2 case. I.E. the empty symlink name, which as expected would return ENOENT.
If someone is motivated, this suggests a symlink wrapper in gnulib would be welcome: it would make it so even on Solaris, symlink(any, "") would fail with the required ENOENT.I suppose we could handle this case specially like: if (errno == ENOENT && !*old_path) error(...,"An empty target is not supported on this system");s/supported.*/portable|valid/?Though I'm not sure there's much benefit in a specific error message in this case?I could go either way. There is precedent, but it's such a corner case, it may not be worth the added code.
given the confusion above, it might be worth the clarification error message. thanks, Pádraig.
[Prev in Thread] | Current Thread | [Next in Thread] |