Hi Branden, On Wed, Jan 15, 2025 at 12:37:24PM -0600, G. Branden Robinson wrote: > > <https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html#tag_03_254> > > One way we've stepped on a rake in Unix terminology, and for no good > reason I've been able to discover, is that we cling to the practice of > referring to two different things as "paths".[1] > > * file names, possibly qualified with location information that may be > absolute or relative to the current working directory ("pathname", > "absolute path(name)", "relative path(name)" POSIX consistently calls these "pathname", I think. > > * a list of the foregoing used to search for command file names or other > loadable resources that an application thinks likely to exist ("PATH", > "LD_LIBRARY_PATH", "MANPATH", "PYTHONPATH", "CLASSPATH", etc.) You could say the *PATH variables contain one or more path(name)s. Maybe I would have put an *S in those variable names, because a plural amount may be one, but a singular amount may not be more than 1, but history. :/ > To state it differently, we are passionately committed to using the term > "path" to refer to objects of significantly distinguishable types, such > as: > > char * > and > char **. I would actually use path and paths for such variable names. > And since this application doesn't admit general recursion--we don't > ever refer to a single character as a "path", nor to a list of lists of > file names as "path", the usage is corrosive to coherent thought. In my programming, I tend to use plural for lists. (*checks to make sure can't be called a liar*) > I don't have any real hope of reforming this abhorrent practice-- > I fear the cement had set good and hard before even POSIX Issue _1_ > came out. (Can I blame "/usr/group"?) > > But...in the event the donkey I'm riding has borrowed some of its > genetic material from a vigorous young warhorse (let's call him > "JeanHeyd"), I would: > > 1. Reserve the term "path" solely for discussion search paths, such as > those implemented by "PATH". The issue I have is: I hate long function parameter names. I think I prefer having path and pathname be synonyms. I still would be consistent in manual pages to use only one of them, but would make them synonyms. I think I would use pathname when speaking, but path for variable names (which are usually shorter; e.g., string and s). > 2. Adopt the term "filespec", or "file specification", or even just > "file name", to refer to a character sequence that locates a file. > POSIX interfaces and utilities tend strongly to be general in this > respect, in the sense that anywhere a "basename" (the "final > component" of a "pathname") is accepted, one that is qualified is > also accepted, as in an "absolute pathname" or "relative pathname". A good example of what you're talking about is exec(3): int execl(const char *pathname, const char *arg, ... /*, (char *) NULL */); int execlp(const char *file, const char *arg, ... /*, (char *) NULL */); int execle(const char *pathname, const char *arg, ... /*, (char *) NULL, char *const envp[] */); int execv(const char *pathname, char *const argv[]); int execvp(const char *file, char *const argv[]); int execvpe(const char *file, char *const argv[], char *const envp[]); The p functions *require* a filename, while the non-p functions accept a pathname. I would change that manual page for consistency into either pathname and filename, or path and file, but the current mix is bad. > The occasions upon which you want to refuse to traverse outside of a > directory is rare enough, and specialized enough, that it merits > case-specific discussion. These are replete with complication. Is > traversing only into a subdirectory of the current working directory > acceptable? Should symlinks be followed? If so, should they be > permitted to escape the part of the tree descended from the current > working directory? Back in the day, about a thousand security > advisories were issued against FTP servers arising from confused or > unstated policy here, and the terminology of "pathname" did > _nothing_ to help resolve them. (Did that term help create the > problems by fogging the minds of the application developers? Who > knows?) That is, filename is rare, and pathname is usually what tools use. Agree. > and > > 3. Throw away the term "pathname" entirely. Banish it. Nah, it's standard. I like that one can go to POSIX and consult what it means. I'll try to use POSIXly correct terms. Actually, it's the term I'd use more often. > And yes, I know, POSIXly correct people I tend to be. :-) > can claim to "eliminate" this > confusion by interrupting conversations with a raised finger: > > "No, no--you don't mean 'path', but 'path_name_'." > > In my life I have found that I have sufficient talent for being > simultaneously right and annoying. I don't need that kind of help. > > So--will you ride with me, Sancho? I mean, Alex? ;-) Hmmm, not this time, I think. :-) > > > > +.IP \[bu] > > > +If you want to store a file on a vfat filesystem, > > > +then its filename can’t contain a 0x3A byte (: in ASCII) > > > > Is that the only one? I expect there are several characters that are > > not allowed in vfat. > > You also can't _end_ a file name with "." (0x2E). I think there are > other restrictions. Putting my own music collection on a file system > that I needed to be able to share with Windows boxes, many years ago, > was a tedious exercise in discovering VFAT's irritating limitations. <https://unix.stackexchange.com/questions/92426/why-doesnt-the-linux-vfat-driver-allow-certain-characters> seems to say there's a list of forbidden characters: ?<>\:*|" Cheers, Alex -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
