On Sun, 14 Sept 2025 at 19:15, Chris <seahen...@gmail.com> wrote: > Isn't it better to surprise users who know what they're doing with a > warning, than to surprise users who *don't* know what they're doing with > the lack of one?
That's a false dichotomy. In addition to those choices, there's also the option of confusing users who type some command other than 'ln' and get a truly confusing message about 'ln', who *definitely* won't understand it (and likely won't have a clue how to fix it). The proposal would cause scripts that *correctly* use 'ln' in this manner to start emitting warnings that the users of those scripts would not understand. Worse, adding "just a warning" is not as innocuous as it seems. Spurious warnings can cause false alarms in system monitoring, or failures in continuous integration pipelines, as just two examples. At least people who type 'ln' some chance of understanding what they messed up. The entire point of symbolic links is that they do NOT reference a particular file, but rather they provide a path alias. What's on the other end of that path depends on where it starts from. The behaviour of symlinks is fundamental to POSIX-like filesystems(*1), so changing it is not an option. Like any other inode type, they can have multiple names (hard links) in multiple directories; to see the effect, try the following commands: mkdir /tmp/x$$ cd /tmp/x$$ ln -s .. .up ln -s .up/.top .top mkdir a a/b a/b/c ln .top .up a/ ln .top .up a/b/ mv .top .up a/b/c/ # the next line will fail ls -dilL a/.top a/b/.top a/b/c/.top ln -s . .top # Take note of the inode numbers & link counts (*3) in the output of the following commands (first & third columns) ls -dilL a/.top a/b/.top a/b/c/.top . ls -dil a/.top a/b/.top a/b/c/.top ls -dil a/.up a/b/.up a/b/c/.up ls -dilLt a/.up a/b/.up a/b/c/.up a/b/c/.up/.up a/b/c/.up/.up/.up # make sure that 'pwd' reports your true directory set -o physical # now watch where 'cd' takes you... pwd cd a/b/c pwd cd .top pwd cd a/b/c pwd cd .up pwd cd .up pwd cd .up pwd When you type 'ln -s foo bar', 'foo' does not have to exist as a file; it can be created later, or never. -Martin (*1: some old Unix variants (*2) did not support multiple hard links to a symlink; the sample script won't work on such platforms.) (*2: I remember using an early version of BSD-derived UNIX that treated relative symlinks as being relative to the process's cwd rather than the directory the symlink resided in; that was terrible, it made such links mostly useless.) (*3: remember the link count for a directory includes its own '.' entry, and the '..' entry of each subdirectory)
