ctwise is precisely correct.

In fact on Solaris, "cp" and "mv" are precisely the same binary file - not the same file on disk, but they are identical binary copies of the other. So if you happen to delete one accidentally, you can restore it by copying the other remaining one, to the name of the one you deleted.

As for why "ncal" doesn't work when you use an alias - this is because an alias is actually like a function or a script; it runs the binary for you, and the binary that gets run still has its executable/process name set as the name of the file on disk.
Alias "myaliastest" to "sleep" and run "myaliastest 60" and look in your process listing - you'll see that "sleep" is in the process listing, not "myaliastest".

And as for why using a softlink DOES work - well, a softlink DOES affect the process name. A softlink doesn't run a binary for you like an alias does... it IS the binary (well, it's a link to it, but for this purpose that's equivalent).
Make a softlink of "mylinktest" to "sleep" and do the same test - you'll see that "mylinktest" shows in the process list.

[ Reply to This | # ]

Bah, sorry, small correction: in Solaris, "cp" and "mv" ARE the same binary file on disk; the directory entry for each are hard links (not soft links) to the same file on the disk.

[ Reply to This | # ]

The major reason is for compatibility. Evidently, Apple didn't see a need for the full functionality of ncal, and only preinstalled it with its backward compatible name, "cal". The sillies.

You also see symlinks doing the same job, as delivered by the vendor. *EL4 has symlinks from /bin/egrep and /bin/fgrep to /bin/grep; in this case, the man page is the same too.

(How apt that "ln" was used in this hint -- "ln" is yet another hardlink to the inode referenced by "cp" and "mv". This is why the "source" and "destination" for "ln" seem to be the wrong way round.)

[ Reply to This | # ]