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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
