Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15525 > unrolled thread

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

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: -e test description in the GNU Bash 5.0 man page from 7 December 2018 Marco Ippolito <maroloccio@gmail.com> - 2019-10-21 12:00 +0200

#15525 — Re: -e test description in the GNU Bash 5.0 man page from 7 December 2018

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

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web