Elmar Zander <el...@zandere.de> wrote: > as I've understood from those threads > http://lists.gnu.org/archive/html/bug-coreutils/2007-12/msg00211.html > http://lists.gnu.org/archive/html/bug-coreutils/2007-11/msg00006.html > and the FAQ the difference in ln and ln -s behaviour is intended and not > fixable. > > To summarize: if you type > * ln 'path1/file1' 'path2/file2', then 'path2/file2' points to > ./path1/file1', i.e. the path is considered relative to the current
You have the right idea, but once two files are hard-linked, there is no directionality. Each refers to the same inode. I.e., saying one points to the other is misleading. > working directory (since the inode of 'path1/file1' is immediately > resolved) > * ln -s 'path1/file1' 'path2/file2', then 'path2/file2' points to > path2/path1/file1', i.e. the path is considered relative to the > directory where 'file2' resides (since just the string 'path1/file1' > is stored somehow in 'path2/file2' and only resolved when the symlink > path2/file2' is accessed) > > If you know that in the first case 'file2' is made to point to the > same inode and in the second case just the path 'path1/file1' is > stored in 'file2' this behaviour is ok and understandable. *But*: the > documentation (GNU coreutils 6.10, April 2008) for 'ln' just states > for the -s option > > ‘-s’, ‘--symbolic’ > make symbolic links instead of hard links. > > Nothing more. For me, a statement like this usually implies that the > two are semantically equivalent (which they are not, as > described). So, I think that the user should be informed of this > difference, maybe by a sentence like > > Note: if 'target' is a relative path and 'linkname' does not point > to the current directory, the created link will be relative to the > directory the link is created in. > > or > > For semantic differences between ln and ln -s see the examples section. Thanks. Either would be good. Would you like to adjust doc/coreutils.texi accordingly? If you change the man page (aka --help output), bear in mind that is should stay concise. It does point to the complete documentation in the info pages after all. If so, please take a look at the contribution guidelines: http://git.sv.gnu.org/cgit/coreutils.git/plain/HACKING _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
