use of softlink and argv[0]

On linux, if I add a softlink to an executable:

Code:

ln -s a.out myprog

When myprog is executed (really a softlink to a.out), argv[0] is the name of the softlink. This means a single, pre-compiled binary can respond to the name of the softlink via which it is invoked (which could be other than the actual name of the executable).

I am almost positive this will be true on all other unix style filesystems, but I just wanted to check with anyone who might know for sure before I incorporate this potential into something that will be used cross-platform.

I believe (but can't quite seem to verify) that this behavior is based on the runtime library, so anybody running GNU libc would see the same behavior. (Certainly this machine running Mac OSX exhibits the same behavior.)

This is a very common thing (so, for instance, vi/vim/ex are linked to the same executable, and modes are set based on the command line; same with tex/latex/pdf[la]tex/etc.) in the unix world, so I would feel comfortable going ahead.

Yay, thanks. I am kind of thrilled I was asked to do this, so I am being a little paranoid about all the angles.

Originally Posted by MK27

Yay, thanks. I am kind of thrilled I was asked to do this, so I am being a little paranoid about all the angles.

And to add to the list of "executable is the same file with soft links":
g++ -> gcc
If it's good enough for gcc, it should be good enoung for you.

I'm not sure, but I think umount and mount are the same way too.

Obviously, it won't work that way in Windows, because ln -s doesn't exist (although there is a way to make links in NTFS).

--
Mats

I was mostly asking because The Application In Question will end up in some BSD distro (or so I'm told), which I've never used. I notice that FreeBSD is GNU C. If tabstop says MacOS respects this too then it must have Pretty Old Roots.

I suppose I should check with my peeps about this, but you guys have reassured me enough that I'm willing to go ahead now. Thanks!!

This is always true, and in fact the "rsh" program uses this to do a goofy trick -- if you symlink rsh to "hostname," then invoking it through the link will automatically connect to the named host.

The runtime library COULD resolve the name to a canonical name, but it has no business doing so, and any runtime which does so is broken.

methinks it's the command intrepreter ie the shell that does the trick for you so it's transparent to the user process

Originally Posted by itCbitC

methinks it's the command intrepreter ie the shell that does the trick for you so it's transparent to the user process

Indeed, I agree with that. But like brewbuck says, should the command interpreter (shell) decide to resolve the link and find the actual file, and replace argv[0] with that, it would break MANY applications that rely on this.

--
Mats

So this should be pretty much foolproof, is what you are saying.

Originally Posted by MK27

So this should be pretty much foolproof, is what you are saying.

Yes, on any Unix-based OS it should be fine.

--
Mats

Originally Posted by matsp

Indeed, I agree with that. But like brewbuck says, should the command interpreter (shell) decide to resolve the link and find the actual file, and replace argv[0] with that, it would break MANY applications that rely on this.

--
Mats

IMO the shell fork()'s a copy and calls exec()'s thereby overlaying the shell copy with a copy of the program and it's inside the exec() call that the shell follows the symlink to the program it actually points too.

Originally Posted by itCbitC

IMO the shell fork()'s a copy and calls exec()'s thereby overlaying the shell copy with a copy of the program and it's inside the exec() call that the shell follows the symlink to the program it actually points too.

The shell doesn't follow the symlink. It doesn't care if it's a link or not. The OS is what resolves the link.

Applications should never know, nor care, whether they are working with links or real files. That defeats the purpose of links.

Originally Posted by brewbuck

The shell doesn't follow the symlink. It doesn't care if it's a link or not. The OS is what resolves the link.

I may have this wrong but I thought it was the shell that issued the open() for exec'ing on the symlink making it to follow that to the actual program.

Originally Posted by brewbuck

Applications should never know, nor care, whether they are working with links or real files. That defeats the purpose of links.

Yes that's the purpose of symlinks ie to be transparent to the application.

Originally Posted by itCbitC

I may have this wrong but I thought it was the shell that issued the open() for exec'ing on the symlink making it to follow that to the actual program.

Yes that's the purpose of symlinks ie to be transparent to the application.

The shell just calls exec(), it does not open anything. The translation of the symlink is done by the kernel -- the shell has no idea it happens.

Originally Posted by brewbuck

The shell just calls exec(), it does not open anything. The translation of the symlink is done by the kernel -- the shell has no idea it happens.

thanks for clarifying!