Re: [PATCH] Allow qualified filename (bar/foo) PATH searching.

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

tlaronde and I have been exchanging mail off-list on this thread and
part of our discussion has wandered back into on-list territory.  The
last mail I got on the subject says

> [I think that these exchanges about the semantics could be discussed
> more widely on the list. If you agree, could you answer to the list
> too including of course whatever in this mail you see fit for the
> discussion?]

which I'm doing.

>>> +Since the behavior can not be changed only at a shell level, there
>> And, why not?  Why can't it be?  I did that in my shell once.  [...]
> You can just change in the shell, but in this case, calling an
> utility dealing with utilities (nice, nohup, timeout, xargs...) you
> can't use the feature since then the command name is an argument,
> unless you add ad hoc knowledge in the shell about which commands to
> treat specifically for arguments being command names.

Well, unless the utility runs a shell.  For some use cases, that's
appropriate; for others, less so.  But I have no problem with
conceptually conflating this with the rest of the things shells do that
execve doesn't, such as redirection.

> And you will probably miss some utilities dealing with utilities.

Definitely will, since some of them are written by other people and you
don't have copies.

>>> +environment variable. And since [...], the variable has to have a definition.
>> Um, what does it mean for an environment variable to exist without a
>> definition?
> An empty environment variable.

Well, I'd consider that a defined variable whose value happens to be
zero-length.

> If I'm not mistaken, there is a difference between "defined" and
> "set";

Possibly.  I'm not familiar with any such that applies to environment
variables; what should I read up on?

> I use "definition" for having an not empty value.  This is probably
> incorrect wording.

Well, it's confusing to me, at least, because that doesn't match how I
have come to understand the term.

> For example [POSIXLY_CORRECT] is an environment variable [...].  It
> has no definition; it can be empty or it can be whatever; only
> matters is presence in the environment.

While writing this, I realized that "has no definition" could refer to
something technical, such as I wrote about above, or it could refer
mean "nobody has defined any semantics for its value string".

>> [about the dot business]
(For list consumption: this was about the part of document, as posted
to the list, which invents semantics for paths with a trailing dot.)
> The "explanation", as I tried to write, is an afterthought.

> In order for the feature to have some sense (for me) there should be
> a distinction between a locator and an identifier.  This means that
> no path relative directive has to be present in the identifier.

Well, I think my point was that _every_ pathname component is
path-relative.  The "foo"s in /usr/bin/foo, /tmp/foo, /home/mouse/foo,
and xyz/foo bear no relation to one another except similarity of
spelling (assuming of course that symlinks don't cause two of the
apparently different directories to actually be identical); each one is
interpreted relative to the path-so-far (with a starting point
depending on whether there's a leading / or not).  . and .. are no
different in that regard.  Indeed, you may note that (at least in the
versions I have on hand) namei treats . and .. as special only when
doing emulation-root things - it's the filesystems that handle them,
and FFS, at least, implements them as ordinary directory entries in
most respects.

> I found that testing strstr(name, "./") was eliminating any relative
> path in one shot without beating around the bush.  But has the
> inconvenience to eliminate also all names that have no path relative
> directives, but which have at least one path component with a
> trailing dot.

> Then the question arises: is this absolutely unacceptable?

Absolutely?  No.  But, at least to me, it requires a lot more
justification than I've seen so far; I think the bar for introducing a
new class of special names, especially in more than just shells, should
be very high.  (Note that leading dots are special in shells, but not
much else - the only other thing I can think of offhand that gives
leading dots any special semantics is ls(1).)

> But "." and ".." are special.

Somewhat.

> And I once wondered about a scheme allowing to walk a filesystem with
> more dimensions

Hm, interesting thought!

> (say: how do you set a filesystem with a couple of parents as dir
> leading to a child, but with the possibility to go "up" from child to
> the two parents?).  For this, one would have to introduce a mean to
> say "change plane at this point".

Not necessarily; you could instead introduce a new piece of per-process
state, specifying which dimension .. operates on.  Which of those
schemes, or some other, is most appropriate depends on the use case
you're designing for, I'd say.

> "..." or whatever?

Possibly.  But there's no need to make it special for any use except
your experimental multidimensional filesystem.  Just make its lookup
routine special-case whatever strings you want to give special meaning
to and you're done, without bothering anyone else.  No need to reserve
anything for anyone not using that filesystem.

> I can't help it ;-) I'm always thinking about "what could be done
> later" and I tend to reserve some spare for what is at present very
> fuzzy.

When most of the possible space is unallocated, that makes sense.  But
pathname components with trailing dots, besides . and .., are already
in use.  I just checked one of my machines and I find one file in
/usr/xsrc and five files in /usr/src with trailing dots in their names,
and, while I use pathname components ending in dots rarely, it has
happened - I have dozens of them, mostly named after text strings like
"Even In The Quietest Moments...".

> For the "pronouns", these are like 'I': there is one definite meaning
> in very specified context, or no definite meaning without very local
> context.

In that regard, they're just like "foo".

Or any other pathname component.

> But It could as well be simply a succession of tests at beginning, at
> end, and strstr(name, "/./") == NULL && strstr(name, "/../") == NULL
> that is no restriction but it is an identifier only if no path
> directive is included [...].

Possibly, but that seems unnecessarily restrictive.  I have a few
directories on some of my machines which are in a fixed place but
typically are symlinks to wherever is most useful for that machine;
I've occasionally used paths like /foo/bar/../blee/file to follow the
symlink and then refer to a sibling of where it points to.  Should such
be forbidden?  Why?

> All in all, if one writes "bar", even if it is in the current working
> directory, if "." is not in the PATH, it will not be found even if
> right under the shell's nose.  So one (at least me :-) could argue
> that it is in fact not introducing a special treatment: "bar/foo"
> behaves as "bar".

It's introducing even more special treatment, actually, because then .
_is_ special, in that ./foo behaves differently from bar/foo: . and bar
are no longer coeval pathname components.  Under the current rules,
./foo and bar/foo - and, actually, /foo and /bin/foo - are treated the
same: the presence of a slash causes PATH search to be suppressed, and
that's all there is to it.  The ./ in the former is just a way to get a
slash into a pathname which refers to foo in the current directory.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B