Symbolic Links in Linux

[chsh]

Originally posted by Vorlin
That's f'ing odd. Symbolic links aren't supposed to act that way and if they're modifying the way the binary is called and using the symlink to determine what happens, I can almost guarantee not many *nix boxes have that. It's a weird way of calling 'command line' options I guess. Good job though!

Actually, it's fairly common Vorlin. All a symbolic link is is a link to the real executable. You could rename the file to a different name, and it would still behave the same. It's in the app, the links aren't doing anything.

[Vorlin]

That's what I'm talking about. I could care less about the actual application itself, I'm more concerned with the symlink acting the way it is. I've already stated before that symlinks are just pointers to a directory or executable. To quote myself exactly:

All a symbolic link is, is a pointer from one "file" to another "file". The reason those are in " is because *everything* in *nix is considered a file, whether it's a file, directory, block device, character device, tape drive, named pipe, etc... All arguments given to a symbolic link will be compared against the binary's to see if they can run and will run using the linked binary if possible. Example below:

The symlink doesn't have to point to an existing file (as already stated as well) and it does nothing more than pass on the real target to the shell.

$ mkdir foo
$ ln -s foo bar (bar is now a symlink to foo)
$ rmdir foo (remove the directory now)
$ ls -l bar
<symlink still exists to a null directory>
$ cd bar
<failure message, nonexistent target>


It'd be the same as a regular executable with passing all arguments to said target executable.

[chsh]

Vorlin, I understand that. All the app does is check argv[0] for HOW it was called though. If you renamed the executable, it would do the same thing.

Personally, I think it's handy.

[Vorlin]

Yeah, I can see argv[0] being checked, and yes, renaming the executable to something else would do the same thing, as would copying it to another name, etc etc...so many ways to do the same thing, hehe.

Good conversation about this btw. I've learned some stuff about symlinks and code from this and right now I'm trying to find the ln source code so I can look at the inode checking for cross-file-system hard links. I know that hard links share the same permissions as the target and that if someone changes the target, the hard link is changed (like a sync) but that's because they share the same inode. I'm guessing they won't let you hard link across file systems because of this.