Why does argv include the program name?

To begin with, note that argv[0] is not necessarily the program name. It is what the caller puts into argv[0] of the execve system call, e.g. see this question on stack overflow. (All other variants of exec are not system calls but interfaces to execve.)

Suppose for instance the following (using execl):

execl("/var/tmp/mybackdoor", "top", NULL);

/var/tmp/mybackdor is what is executed but argv[0] is set to top, and this is what ps or (the real) top would display. See this answer on U&L SE for more on this.

Setting all of this aside: Before the advent of fancy file systems like /proc, argv[0] was the only way for a process to learn about its own name. What would that be good for?

• Several programs customize their behavior depending on the name by which they were called (several examples are provided in other answers to this question).
• Moreover, services, daemons and other programs that log through syslog often prepend their name to the log entries; without this, event tracking would become next to infeasible.

Plenty:

• Bash runs in POSIX mode when argv[0] is sh. It runs as a login shell when argv[0] begins with -.
• Vim behaves differently when run as vi, view, evim, eview, ex, vimdiff, etc.
• Busybox, as already mentioned.
• In systems with systemd as init, shutdown, reboot, etc. are symlinks to systemctl.
• and so on.

Historically, argv is just an array of pointers to the "words" of the commandline, so it makes sense to start with the first "word", which happens to be the name of the program.

And there's quite a few programs that behave differently according to which name is used to call them, so you can just create different links to them and get different "commands". The most extreme example I can think of is busybox, which acts like several dozen different "commands" depending on how it is called.

Edit: References for Unix 1st edition, as requested

One can see e.g. from the main function of cc that argc and argv were already used. The shell copies arguments to the parbuf inside the newarg part of the loop, while treating the command itself in the same way as the arguments. (Of course, later on it executes only the first argument, which is the name of the command). It looks like execv and relatives didn't exist then.

Use cases:

You can use the program name to change the program behavior.

For example you could create some symlinks to the actual binary.

One famous example where this technique is used is the busybox project which installs only one single binary and many symlinks to it. (ls, cp, mv, etc). They are doing it to save storage space because their targets are small embedded devices.

This is also used in setarch from util-linux:

$ ls -l /usr/bin/ | grep setarch
lrwxrwxrwx 1 root root           7 2015-11-05 02:15 i386 -> setarch
lrwxrwxrwx 1 root root           7 2015-11-05 02:15 linux32 -> setarch
lrwxrwxrwx 1 root root           7 2015-11-05 02:15 linux64 -> setarch
-rwxr-xr-x 1 root root       14680 2015-10-22 16:54 setarch
lrwxrwxrwx 1 root root           7 2015-11-05 02:15 x86_64 -> setarch

Here they are using this technique basically to avoid many duplicate source files or just to keep the sources more readable.

Another use case would be a program which needs to load some modules or data at runtime. Having the program path makes you able to load them from a location relative to the program location.

Moreover programs usually print error messages containing their program name.

Why:

1. Because it's POSIX convention (man 3p execve):

argv is an array of argument strings passed to the new program. By convention, the first of these strings should contain the filename associated with the file being executed.

2. It's C standard (at least C99 and C11):

If the value of argc is greater than zero, the string pointed to by argv[0] represents the program name; argv[0][0] shall be the null character if the program name is not available from the host environment.

Note the C Standard says "program name" not "filename".

In addition to programs altering their behaviour depending on how they were called, I find argv[0] useful in printing the usage of a program, like so:

printf("Usage: %s [arguments]\n", argv[0]);

This causes the usage message to always use the name through which it was called. If the program is renamed, its usage message changes with it. It even includes the path name it was called with:

# cat foo.c 
#include <stdio.h>
int main(int argc, char **argv) { printf("Usage: %s [arguments]\n", argv[0]); }
# gcc -Wall -o foo foo.c
# mv foo /usr/bin 
# cd /usr/bin 
# ln -s foo bar
# foo
Usage: foo [arguments]
# bar
Usage: bar [arguments]
# ./foo
Usage: ./foo [arguments]
# /usr/bin/foo
Usage: /usr/bin/foo [arguments]

It's a nice touch, especially for small special-purpose tools/scripts that might live all over the place.

This seems common practice in GNU tools as well, see ls for example:

% ls --qq
ls: unrecognized option '--qq'
Try 'ls --help' for more information.
% /bin/ls --qq
/bin/ls: unrecognized option '--qq'
Try '/bin/ls --help' for more information.

One executes the program typing: program_name0 arg1 arg2 arg3 ....

So the shell should already divide the token, and the first token is already the program name. And BTW so there are the same indices on program side and on shell.

I think this was just a convenience trick (on very very beginning), and, as you see in other answers, it was also very handy, so this tradition was continued and set as API.

Basically, argv includes the program name so that you can write error messages like prgm: file: No such file or directory, which would be implemented with something like this:

    fprintf( stderr, "%s: %s: No such file or directory\n", argv[0], argv[1] );

Another example of an application of this is this program, which replaces itself with... itself, until you type something that isn't y.

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main (int argc, char** argv) {

  (void) argc;

  printf("arg: %s\n", argv[1]);
  int count = atoi(argv[1]);

  if ( getchar() == 'y' ) {

    ++count;

    char buf[20];
    sprintf(buf, "%d", count);

    char* newargv[3];
    newargv[0] = argv[0];
    newargv[1] = buf;
    newargv[2] = NULL;

    execve(argv[0], newargv, NULL);
  }

  return count;
}

Obviously, kind of a contrived if interesting example, but I think this may have real uses -- for example, a self-updating binary, which rewrites its own memory space with a new version of itself that it downloaded or changed.

Example:

$ ./res 1
arg: 1
y
arg: 2
y
arg: 3
y
arg: 4
y
arg: 5
y
arg: 6
y
arg: 7
n

7 | $

Source, and some more info.