bug-bash
[Top][All Lists]
Advanced

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

Re: -e test description in the GNU Bash 5.0 man page from 7 December 201


From: Marco Ippolito
Subject: Re: -e test description in the GNU Bash 5.0 man page from 7 December 2018
Date: Mon, 21 Oct 2019 12:00:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 21/10/2019 11:11, Andreas Schwab wrote:
On Okt 21 2019, Marco Ippolito wrote:

In the GNU Bash 5.0 man page from 7 December 2018 the -e test is
documented as such:

        -e file
               True if file exists.

When "file" is a symlink name to a non-existing target, the -e test fails,
and this may be surprising from just reading the documentation.
It also says:

        Unless otherwise specified, primaries that operate on files follow sym-
        bolic links and operate on the target of the link, rather than the link
        itself.

Andreas.

I still personally find this overloading of the term "file" to refer to:

(1) a generic operand of those primaries we'll call "file", be it an actual file or something else

(2) an actual file

somewhat unnecessarily ambiguous compared to the POSIX version.

As a minor point, when I read the POSIX's wording of "resolves to an existing directory entry", I find it intuitive, possibly from familiarity with other Computer Science contexts like DNS in which look-ups happen in a chain, that the word "resolves" might entail recursion, as in the case I highlighted in code, where a link's target was another symlink. When I read "follow", especially paired with the singular "the target of the link" (not "of the links" or "of the link chain" or similia - and by the way, why use "link" here and not "symlink"? to give the name "link" to a "chain of symlinks"?), I am left wondering for a moment if that implies recursion or not, which is something I did not, subjectively, wonder about when reading the alternative word "resolves". After all, the man page for readlink uses the word "follow" to read a link's target but it makes the point of being explicit about recursive application for the canonicalisation options, as if it weren't automatic to think of "following a link" as "following it... until the end":

       -f, --canonicalize
              canonicalize by following every symlink in every component of the given name recursively; all but the last component must exist

       -e, --canonicalize-existing
              canonicalize by following every symlink in every component of the given name recursively, all components must exist

       -m, --canonicalize-missing
              canonicalize by following every symlink in every component of the given name recursively, without requirements on components existence

If following is meant to be understood as "always to the end of the symlink chain", it seems redundant to say to follow _every_ symlink and to do so _recursively_.

So, in summary:

- file still looks less precise than pathname to me

- (minor point) resolution seems like an elegant term to copy from POSIX to indicate the recursive process, whereby to "follow", especially paired with a singular noun (i.e. link), might be more confusing to some




reply via email to

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