in reply to custom name to the process

Some OSen will allow you to assign to $0; if yours is one of them then you could use that. Otherwise your best bet might be using symlinks to the real file, or consider adding a dummy argument that's ignored that you use to differentiate between instances.

The cake is a lie.
The cake is a lie.
The cake is a lie.

Replies are listed 'Best First'.
Re^2: custom name to the process
by rimvydazas (Novice) on Dec 04, 2007 at 21:53 UTC
    Is there any way to assign different command options/arguments for each symlinc?
[reply]
      I've used a symlinking approach allowing the real script to see how it was called, using a dispatch table.. perhaps this will work for your purposes:

      Create a script for example /usr/sbin/myscript.pl 
      #!/usr/bin/perl

use strict;
use warnings;

my $ME = $0 ;
$ME =~ s@^\.\/|\/.*\/@@g;
$ME =~ /myscript.pl/ and die ("\n Please dont call me directly!\n\n");

my %workerscripts = ( 'worker01'  => \&worker01,
                      'worker02'  => \&worker02,
                      'worker03'  => \&worker03
                    );

my $real_command  = $workerscripts{&findME};
&$real_command;



#---
sub findME
{
   while ( my($k,$v) =  each %workerscripts )
   {
      return $k if $k =~ /$ME/ ;
   };
};

sub worker01
{ print "worker01 was called\n"; exit 0; };

sub worker02
{ print "worker02 was called\n"; exit 0; };

sub worker03
{ print "worker03 was called\n"; exit 0; };

      [download]


      Then create links to that script: 
      cd /usr/bin/
ln -s /usr/sbin/myscript.pl worker01
ln -s /usr/sbin/myscript.pl worker02
ln -s /usr/sbin/myscript.pl worker03

      [download]
      Invoke /usr/bin/worker01, worker02, or worker03 and the proper subroutine should be called..

      Does that get you closer?
      -Harold

[reply]
[d/l]
[select]
        Using this principle you could create the symlinks from Perl, using symlink. That way you can launch the script using fork and exec, and delete (unlink) the symlink in the parent.

        Be careful not to delete the symlink before the child has had chance to exec the symlink. Either waitpid the parent before deleteing it, or use some IPC to indicate the child has started.
[reply]
        I like this approach. I am going try this one. Thanks Harold! Thanks to all other people helping me out!
[reply]
      Well, you can check the value of $0 and do different things with it. But probably the best solution is to use different parameters to ps. For instance, ps -fe will give you the parameters passed to each instance, which is probably a pretty good way of distinguishing your processes.
[reply]
[d/l]
[select]
        As has been hinted at, some OSes specifically disable showing of parameters, as showing those can prove to be security hole....e.g. you can see which config files are used by some programs OR even see userid/password passed to a program as parameters.
        symlinks are probably the best bet, as you can't reserve PID, for reasons of OS stability/security. You could easily though print the PID from the program when it starts each time, by printing the $$ variable.
        the hardest line to type correctly is: stty erase ^H
[reply]

In Section Seekers of Perl Wisdom