Different meanings of $0 under the same operating system

[Jorge_de_Burgos]

I am using a Linux system (Ubuntu 9.10). It took me several hours of frustration to realise something about $0. This built-in variable is defined in perlvar as "the name of the program being executed". Perlvar doesn't mention that its meaning can change, even inside the same program running under the same system, according to the way the program is run. You have this code:

#!/usr/bin/perl -w
use UI::Dialog; # sudo apt-get install libui-dialog-perl

my $statement = "My name is $0...\n";

my $d1 = new UI::Dialog(title => 'I know my name');
$d1->msgbox(text => $statement);

print $statement;

exit;

You save it into a file named "knowthyself" in your Desktop. You give the file executable permissions (chmod 755 knowthyname). Then you run the program 3 times:

1. The first time you open a terminal and type "perl knowthyself". You get this output: "My name is knowthyself..."
2. Then you use the terminal and type "./knowthyself". You get this output: "My name is ./knowthyself..."
3. Finally you go to your file manager (Nautilus) and click on the file. You are asked what to do: Do you want to run it in a terminal, do you want to show its contents, do you want to cancel the action, or do you want to just run it? Of course you choose this last action (run the program without opening a terminal). You get this output (in a window): My name is /home/user/Desktop/knowthyself...

Moral: even if you are running your program under one and the same system, even if it supports $0, you have to be very careful before relying on what $0 returns.

[ikegami]

Typical use of $0:

use Cwd qw( realpath );
use File::Basename qw( dirname basename );

# Look for modules relative to script location
use lib dirname(realpath($0));

sub usage {
    my $prog = basename($0);
    print STDERR "usage: $prog [options] [--] [files]\n";
    exit(1);
}

[Bloodnok]

...all of which can be summarised as: $0 represents the path by which *NIX locates the script

Furthermore, there is yet a 4th possibility - normally only noticed under one of the std *NIX shells whereby, if a script is 'dot'ted or 'source'ed, $0 is the name of the shell in which the 'dot'/'source' command is run - the perl equivalent of which is to do knowthyself from another script.

[Jorge_de_Burgos]

...all of which can be summarised as: $0 represents the path by which *NIX locates the script

I agree. Maybe we should promote a change in the perlvar definition of $0 I quoted at the very beginning of this node ("the name of the program being executed")?

[JavaFan]

...all of which can be summarised as: $0 represents the path by which *NIX locates the script

Except of course when it doesn't.

$ perl < knowthyself
My name is -...

[Bloodnok]

Ahh, but it is ... since, when used as a file name, '-' is an alternative id for stdin - witness most of the *NIX filter commands e.g. sort, join et al

[JavaFan]

Why such a complicated program? Does it give different output if you would have written:

#!/usr/bin/perl -w
print "My name is $0...\n";

instead?

[Jorge_de_Burgos]

Well, yes, of course I could have written a shorter program like yours. In that case the program would totally miss the output when run by Nautilus without a terminal open, wouldn't it? Just try to run your shorter program without a terminal.

[assemble]

#!/usr/bin/perl -w
print "My name is $0...\n";
<STDIN>;

...

[MidLifeXis]

The same exists for C (argv[0]), shell ($0), and many other languages. Under some OSen and languages, you can even change the name of the program in the process list by modifying $0 to be what you want.

[Anonymous Monk]

That is no surprise if the post meant to show one. Try with (symbolic|hard) link (exectute the link created afterwords).

[Anonymous Monk]

they are all practically the same, in the format PATH/PROGRAM

in (2) bash need ./ to look in the directory and in (3) nautilus is running on /

you can always get only the name by using something like:

@name = split '/', $0;
$name = pop @name;
print "my name is $name \n";

[FloydATC]

...except for some primitive operating systems out there that use other characters than '/' to separate path elements.