Re: ln does not work as documented
Bill, thanks for pointing out the bad example. I've added Bob's examples verbatim. Thanks, Bob. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln does not work as documented
Thanks for clarifying that. What's misleading is when you say ln -s a b .. # creates links ../a and ../b pointing to ./a and ./b I thought pointing to ./a would be an a in the current directory. Wouldn't it be nice: It seems that I fairly often run into situations where I wish ln had some additional functionality, although I can't say exactly what it should be. But for instance, after compiling a package yesterday with lots of executables, I just wanted to make links to all the executables and put them in my ~/bin. I decided to move them instead because I could do mv a b c d e f g ~/bin. To ln them, which I would prefer, I have to type ln longpathname/a longpathname/b ... . Now that I think about it, I could have defined a variable to shorten the path name, but there were something like 8 executables. Wouldn't it be nice if ln had an option to try to figure out the relative path from the target dir to the cwd (and could perhaps fall back to a hard path if necessary). Bill Bruno wrote: The examples in the man page say I can ln -s a b .. and get links in ../a and ../b to ./a and ./b Yes. Perhaps not the most useful of examples. Suggestions for documentation improvements are always welcome. but when I try it I get a link from ../a and ../b to themselves, which are useless circular links. The info docs say: ln -s a b .. # creates links ../a and ../b pointing to ./a and ./b Symbolic links are purely linked by name value and nothing more. The names in the examples are a and b. Those are created in the directory .. and they do point to ./a and ./b. Not a useful example but still illustrative of what the command does. When the target is a directory the new files (symlinks are special files) created will be named the same as the source file names. Each one will hold the value of the source. Maybe it would be good to have some bad examples in the docs. Bad Example: # Create link ../a pointing to a in that directory. Not really useful # because it points to itself. ln -s a .. Better Example: # Change to the target before creating symlinks to avoid being confused. cd .. ln -s adir/a . Bad Example: # Hard coded paths don't move well. ln -s $(pwd)/a /some/dir/ Better Example: # Relative paths survive directory moves and also work across # networked filesystems. ln -s afile anotherfile ln -s ../adir/afile yetanotherfile I'm using tcsh in linux, uname -r : 2.4.21-20.EL Just fyi but neither of those two pieces of information matter. What might have mattered was the version of the 'ln' command. You can report it with the --version option. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln does not work as documented
William J. Bruno wrote:
ln -s a b .. # creates links ../a and ../b pointing to ./a and
./b
I thought pointing to ./a would be an a in the current directory.
Nope. The value is used unchanged.
It seems that I fairly often run into situations where I wish ln had
some additional functionality, although I can't say exactly what
it should be. But for instance, after compiling a package yesterday
with lots of executables, I just wanted to make links to all the
executables and put them in my ~/bin. I decided to move them
instead because I could do mv a b c d e f g ~/bin. To ln them, which I
would prefer, I have to type ln longpathname/a longpathname/b ... .
Now that I think about it, I could have defined a variable to shorten
the path name, but there were something like 8 executables.
I would typically do a for loop on the command line in that case and
use shell variables as typing aides. In bash:
touch foo1 foo2 bar baz
cd ~/bin
for f in ~-/foo[12] ~-/{bar,baz}; do ln -s $f .; done
Of course use of ~- creates full path links and I want to avoid those
if possible or I can't access them over NFS and things like that. So
instead I would do this using shell file and directory expansion along
the way.
touch foo1 foo2 bar baz
cd ~/bin
for f in ../src/adir/foo[12] ../src/adir/{bar,baz}; do ln -s $f .; done
Wouldn't it be nice if ln had an option to try to figure out
the relative path from the target dir to the cwd (and could perhaps
fall back to a hard path if necessary).
I seem to recall this being available through some perl script. But
the actual example escapes me at the moment.
Bob
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
ln does not work as documented
The examples in the man page say I can ln -s a b .. and get links in ../a and ../b to ./a and ./b but when I try it I get a link from ../a and ../b to themselves, which are useless circular links. I'm using tcsh in linux, uname -r : 2.4.21-20.EL Bill ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln does not work as documented
Bill Bruno wrote: The examples in the man page say I can ln -s a b .. and get links in ../a and ../b to ./a and ./b Yes. Perhaps not the most useful of examples. Suggestions for documentation improvements are always welcome. but when I try it I get a link from ../a and ../b to themselves, which are useless circular links. The info docs say: ln -s a b .. # creates links ../a and ../b pointing to ./a and ./b Symbolic links are purely linked by name value and nothing more. The names in the examples are a and b. Those are created in the directory .. and they do point to ./a and ./b. Not a useful example but still illustrative of what the command does. When the target is a directory the new files (symlinks are special files) created will be named the same as the source file names. Each one will hold the value of the source. Maybe it would be good to have some bad examples in the docs. Bad Example: # Create link ../a pointing to a in that directory. Not really useful # because it points to itself. ln -s a .. Better Example: # Change to the target before creating symlinks to avoid being confused. cd .. ln -s adir/a . Bad Example: # Hard coded paths don't move well. ln -s $(pwd)/a /some/dir/ Better Example: # Relative paths survive directory moves and also work across # networked filesystems. ln -s afile anotherfile ln -s ../adir/afile yetanotherfile I'm using tcsh in linux, uname -r : 2.4.21-20.EL Just fyi but neither of those two pieces of information matter. What might have mattered was the version of the 'ln' command. You can report it with the --version option. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
