Best practice when referring to a program name in C

Question

What is considered best practice when referring to a program name? I have seen:

#define PROGRAM_NAME "myprog" printf("this is %s\n", PROGRAM_NAME); 

and:

 printf("this is %s\n", argv[0]); 

I know that the second approach will give me ./myprog , not myprog , when the program is not called from $PATH , and that the first approach guarantees consistency with the program name.

But is there anything else that makes one approach superior to another?

Answer 1

The second approach is superior when you have multiple links. On * nix systems, sometimes the behavior depends on how you invoke the program. So hard coding the program name will obviously be a problem - it will never be able to verify this.

Answer 2

I tried to take the best of both worlds:

 char const * program_name; int main(int argc, char **argv) { program_name = argv[0]; //... } 

If you need to specify computer_name in some other file, you can declare it as follows:

 extern char const * program_name; 

I declare "char const *" because I want it to be a pointer that points to const data. I am not sure if I did this part correctly.

Answer 3

I usually use argv[0] or basename(argv[0]) , if possible. From the POV user, I think that if they rename or tightly link the executable file (or someone else does it for them), then they want messages from it to appear under the name that they use, and not under some other the name that it was compiled that they may or may not know.

Similarly, if in the future you find that you want to compile your program under different names with different parameters in order to provide different versions, you want to wrap #ifndef around this #define and make sure it is defined through the Compiler Command Line: -DPROGRAM_NAME=myprog_demo , or do you just want to do it and it works?

An exception may be that if your instructions for use are an extract from a man page or other documentation, you might want to set the name of the program in it. But then you probably would not use #define .

Implementations should not provide argv[0] , though, so this case is also handled for better portable methods. Again, if your system does not provide it, then probably the user will also not see messages on any terminal.

By the way:

 #define PROGRAM_NAME "myprog" puts("this is " PROGRAM_NAME); 

Answer 4

The second approach can also give you lines like /usr/bin/myprog if you did it this way; basename should indicate the name of the executable file (which you could call the name of your program) ... if it was not symbolic ... (in this case, you have the name of the link ... that can be used to make some kind of options in program behavior).

The first approach “corrects” the name of the program for what the programmer wanted, regardless of how the user renamed the executable file or is symbolically linked (or even with tight binding)

Answer 5

It doesn't exactly answer your question about programming best practices, but I think you should also keep in mind what works best for the user. I personally prefer programs that refer to themselves using argv[0] , that is, the command that I called, rather than some random name that the encoder is hard-coded in the program. A few examples where a hard-coded name is annoying or at least doesn't help:

• I created a link to the program
• I for some reason renamed binary
• I have several executables with the same base names in different directories in my $PATH
• The program gives me hints about other ways to call it, for example. in usage reports

The only situation where I prefer the name of a hard-coded program is when I use GUI applications. I would not want to see "~ / foo / bar.pl" as the window title.

Answer 6

The first is superior to the later when you do not have argv at hand.

 #define PROGRAM_NAME "myprog" void salute() { // no argv available printf("Hello from %s\n", PROGRAM_NAME ); } void main( int argc, char** argv ) { salute(); } 

Answer 7

Depends on whether argv in scope or not ...