Sometimes this is used for other purposes, as well. For instance, the busybox binary provides a lot of utilities (cp, init, ping etc) all linked to /bin/busybox, which uses the name it is called under to determine which program to run.
The GNU mtools also used this scheme. So the idea goes back pretty far.
(Mtools is a collection of tools to allow Unix systems to manipulate MS-DOS files: read, write, and move around files on an MS-DOS filesystem,
typically a floppy disk.)
No, on my system they're three distinct executables; check the sizes shown in my previous comment.
Ubuntu 14.04 uses GNU grep 2.16. When I install it from source (grep-2.16.tar.xz), I get the three distinct executables. When I install the latest version (2.25) from source, egrep and fgrep are shell script that invoke "grep". (Which could be a problem if you happen to have another "grep" command in an earlier directory in your $PATH. Symlinks would avoid that problem.)
Here's the Changelog entry for the change to shell scripts:
2014-03-23 Paul Eggert <eggert@cs.ucla.edu>
egrep, fgrep: go back to shell scripts
Although egrep's and fgrep's switch from shell scripts to
executables may have made sense in 2005, it complicated
maintenance and recently has caused subtle performance bugs.
Go back to the old way of doing things, as it's simpler and more
easily separated from the mainstream implementation. This should
be good enough nowadays, as POSIX has withdrawn egrep/fgrep and
portable applications should be using -E/-F anyway.
That's a stretch to call it "related", but this one reminded me of another story related to file names in a surprising way - "The $5000 Compression Challenge": https://news.ycombinator.com/item?id=9163782
> There is also a setter function, setprogname, which is not to be confused with the slightly different setproctitle. There’s no getter for proctitle, however, unless you count ps.
setproctitle() is only for the current process. It is a system-specific interface implemented in libc (in OpenBSD/FreeBSD a sysctl() to set the memory address where the string is stored).
ps(1) examines other processes and again uses a system-specific interface to the kernel to retrieve all information about other processes (using kvm(3) on OpenBSD/FreeBSD).
I see. So you could use the same kvm API to get all the proctitles (assuming you're on a bsd), and then filter it yourself to find the one for the current process, right?
Classically, tools like ps worked by opening /dev/kmem, reading the symbol list from /vmunix or wherever, and chasing data structures in kernel memory a bit like a debugger might.
These days there is usually a getter for proctitle in the form of the /proc filesystem, sysctls, etc.
