Re: logical paths
..I'm afraid you may be biting off more than you can chew. Adding logical behavior to all the coreutils.. ..just sounds like a huge task to me, with minimal benefits. snip Chet Ramey's comments* on bug-bash are still pertinent - when worried about logical vs. physical filename tab-completion in the shell, it is easier to use the existing shell feature of 'set -o physical' to temporarily force the shell to physical during the calculation of the filenames to tab-complete, than it is to teach every utility the difference between logical and physical. Thanks for the warning. You're right, it's not that big a deal. ..it sounds invasive enough that you would need to assign copyright to FSF if you ever expected it to be incorporated.. That's not a problem, of course. Thanks, Kartik * http://thread.gmane.org/gmane.comp.shells.bash.bugs/9273 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: logical paths
Just about every system call that deals with file names will have to deal with file names that contain ... I don't think this is true. For example, there's a call to chdir(..) in remove.c::AD_pop_and_chdir() that I'm pretty sure won't need to be touched. As another example, the calls to fopen() temp files in the operation of sort don't need to be touched. I didn't have to search too hard to find such examples, so I don't think they are rare. Wouldn't it be easier to change your C library instead? That would fix the problem for (almost) all programs, not just for coreutils. That seems like a bad idea: 0. We don't *have* to change the semantics of all file operations everywhere one sees them. As I mentioned above we only need to change places operating on externally visible path names. 1. I don't think we even *should* change the semantics of stat() to read $PWD for every single user of libc out there. The further down I go the software stack the more likely I am to run into unforeseen consequences, scenarios that affect other people. I thought about this alternative when I suggested adding an option: we avoid changing *default* behavior that people might already be relying upon in their scripts. 2. The further down I go the software stack the harder it will get *politically* to make changes. And with good reason; the further down the stack one gets the more conservative people have to be about changing things because of one random guy's input. Who knows what implications may result? See previous point. That sort of reasoning is why I went first to bash to see if there was a fix in the shell. I have no illusions that I can go around back-patching every piece of UNIX software out there to respect logical paths. Logical paths will remain a leaky abstraction, I'm just trying to explore whether we can get a lot of bang for a little buck by changing coreutils. The answer to that may well be in the negative. --- Does anybody have a comment on how common file operations are on externally visible path names? There are ~100 occurrences of calls to *stat(), a lot of those would need to change I think. That and a few of the ~30 calls to fopen() should get us most of the way there. Am I talking through my hat? Or is this a significant enough set of changes to make people uncomfortable without some extensive testing? Again, I'm not recommending changing default behavior. Thanks, Kartik ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
(no subject)
Hi, I suspect this may have come up on this list before, but a search didn't reveal it*. Does POSIX require that coreutils commands use only physical path rather than pwd to resolve relative paths? When pwd contains symlinks and we try to operate upon relative paths that take us outside the symlink, the effect is often jarring and non-intuitive. For example: $ mkdir base_dir $ cd base_dir $ mkdir -p x/y $ touch z $ ln -s x/y f $ cd f $ cp ../z . cp: cannot stat `../z': No such file or directory $ ls .. y Related discussion on bug-bash: http://thread.gmane.org/gmane.comp.shells.bash.bugs/9273 Thanks, Kartik * - The closest I got was this thread: http://lists.gnu.org/archive/html/bug-coreutils/2005-04/msg00073.html ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: logical paths
Bob Proulx: The $PWD process environment variable is a construct created by the command shell. The chdir(2) operating system call does not modify any process environment variable. Keeping those two in sync is not an operating system function and is never automatic. When mixing programs with different conventions one will always be surprisingly different than expected from the other one. Eric Blake: However, there is nothing preventing coreutils from adding additional command-line options that tell tools to interpret $PWD and behave on relative paths logically. This was sort of what I was hoping for :) I realize converting the world will be slow and painful, and that all bets are off for tools that chdir() internally, but just giving coreutils such options would get this leaky abstraction most of the way there. I will submit patches in a bit. Eric Blake: On the other hand, it is quite easy to type `pwd`/../z, and get a valid physical path to hand to cp, regardless of whether $PWD is currently physical or logical.. Just the sort of workaround I was looking for, but it doesn't seem to quite work. However, this does work: Type `pwd`/../ and press Tab. At least in bash, `pwd` gets expanded on the commandline. Thanks. Eric Blake: Please use a subject line. It makes it less likely that your message will be discarded as junk. Apologies. I've given up on subject lines in casual email, but of course they're useful in a mailing list. Bob Proulx: At this point try this and remember the inode numbers. ls -ldogi . x x/y Thanks for the nice tour. Kartik ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
