…I was assigned one of my very first program to develop: a way to assure an user can run no more than a specific number of instances
of the same executable.
The real story was this: a company was using an Unix ncurses based ERP, and users were forced to connect via remote shell and
launch it automatically. The problem was that several users were opening more terminals (and therefore ERP clients) limiting
resources to other users.
I wanted to demonstrate my skills being able to implement the solution in a couple of hours, and instead of spending time
searching for a production-ready solution on the Internet, I decided to do it all on my own.
It was clear to me I was needing a kind of
wrapper to control the execution of external programs. In fact, since users were
automatically switched from the remote shell into the ERP client, it did suffice to place the wrapper as the
user shell.
But how to implement it? At that time I knew Java, C++, C, Perl and some Bourne Shell. Making it in Java was too heavy, and
most notably required to install a JVM on the server (it was the time of the Red Hat 5 branch). C and C++ required too much time
to come with a working solution, and Perl was the most promising allowing me to do everything I was able to do with
other languages, overcoming the limitation of the shell (e.g., arithmetic).
But at that time I was not a
fluent Perl developer.
A few days ago I found the above program out of an old backup, and so I spent five minutes to read it again. Not surprisingly, I found
it awful with respect to the code I write today, and moreover I see a lot of code uglyness due to
baby steps. But hey, it was fun
to see how many things I've changed in my coding style, idioms, adoption of the language and of its operators, and most notably
about how I'm today
toward compact code instead of
long and blown code. At that time I was convinced that as long the code was, as much
it must be simpler to read, today I believe it is the opposite (with a very few exceptions I tend not to adopt until I
can remember very well).
In this article I will dissect a few parts of the above program to show you how I was writing code back in those days, and it was
a huge time ago (at least in computer timeline):
15+ years ago.
2 Baby Steps
Well, as you can imagine when I started doing a real job I was nothing more than a programmer-to-be, and my knowlegde
about Perl was really tiny. I mean, I read the Camel Book (of course!), and I was experimenting with Perl as much as I could,
but I was not an avid consumer of the Perl community (as well as other communities) and so I did not have a lot of chances
to learn from other people experience and code.
More than that, I just finished my university degree, and so my mind was literally full of theories about writing
correct and beautiful code, but that were just theories without any implementation! And last but not least, I was convinced
I could do everything by my own (that is, who needs modules?).
Today I recognize the following as baby steps in the Perl world.
2.1 Method Prototypes
Yes, I was using prototypes everywhere.
Why? I suspect they were comfortable to me, since I was used to languages where each method has a prototype (C, C++, Java), and
so I was trying to use a kind of common approach to every language, applying to Perl prototypes even when I was not needing
them at all!
Of course, by time and experience, I found that prototypes are usually not useful at all in my programs, and made refactoring
a lot harder.
2.2 Method instead of Operators
Perl allows operators to be used without braces, but that was something my eyes were not able to parse!
Again, coming from languages where methods and operators both need parentheses, I tried to bend Perl to my will
and use operators the very same way.
2.3 Untrusting the Thruth
Perl has the great ability to cast a variable depending on the context, but it was something too much complex for me.
So for instances, instead of testing a scalar against a not-true value, I was using the
defined operator:
# if ( $scalar )
if ( defined $scalar ){ ... }
Worst: I was not using the ability of an array to be scalar-contextualized in tests:
#if ( ! @array )
if ( not defined @array || $#array <= 0 ){ ... }
2.4 Global Variables
my what?
I was not using scoped variables, and the reasons were:
- it was not clear to me the real difference between
my and local, and I have to confess I thought local was what should be the
name for scoped variables (maybe because of the way some shells declare local variables), but since local was usually a bad idea
I decided not to use either;
- my scripts were quite small and self contained, so there was no risk at all about variable clash.
2.5 Backtick as a Rescue!
I knew pretty much well a kind of command line Unix tools (e.g., grep, awk, sed, find), and sometimes I needed
to do something in Perl without knowing how to do but with shell tools. So, how could I merge the both?
Easy pal: backtick the Unix tools and manage the result in Perl!
2.6 No Modules, please
I was not using modules, both by design and by fear.
With
by design I mean that I was writing scripts for machine loosely connected to the Internet (just think I was working with server behind an ISDN router!),
and therefore even dowloading a module and install it could be quite a pain.
By fear means I was quite scared about importing other people's code. I was still learning about how to use correctly the
CPAN, how to read
the documentation, and so on. And I did not want to install things in the wrong way on code that must run. After all, I was half-an-hour
away from implementing some kind of module functionality by my own (ah, the ego…).
2.7 Regexp Sometimes…
I tried to use regexp, but I was too less experienced. Therefore I usually did the substitution with friendly tools, like
split and alike.
I fear regexp nomore, and even if I'm not a master at all, I find interesting placing them in programs not only because
they allow me to write clear and compact code, but also because they still are some criptic stuff other developers
have hard time reading.
3 The Code
3.1 University Distortion
There are a couple of places where you can see evidence of the teachings at my university, most notably the
command line argument loop:
sub parseCommandLine()
{
# The script must be at least two arguments.
if ( $#ARGV < 1 or $#ARGV > 4 )
{
help();
exit(0);
}
$POLICY_FILE = $DEFAULT_POLICY_FILE;
foreach $argument (@ARGV)
{
if ( $argument =~ /(-program=)/ )
{
$argument =~ s/(-program=)//;
$PROGRAM = $argument;
}
elsif ( $argument =~ /(-policy=)/ )
{
$argument =~ s/(-policy=)//;
$POLICY_FILE = $argument;
}
elsif ( $argument =~ /(-username=)/ )
{
$argument =~ s/(-username=)//;
$USERNAME = $argument;
}
elsif ( $argument =~ /(-message=)/ )
{
$argument =~ s/(-message=)//;
$MESSAGE_FILE = $argument;
}
}
# check main parameters
if ( not defined $USERNAME or $USERNAME eq "")
{
warn("\nCannot find username !!\n\n");
help();
exit(1);
}
elsif ( not defined $PROGRAM or $PROGRAM eq "")
{
warn("\nCannot find the program name \n\n");
help();
exit(2);
}
elsif ( not defined $POLICY_FILE or $POLICY_FILE eq "")
{
warn("\nI need a policy file to run!\n\n");
help();
exit(3);
}
}
As you can see I was
hardwiring the arguments directly into the program, as well as I was not using any
getopt-like module.
That was by
culture: university never told me there was a
getopt way of getting parameters!
Please note also that I was checking the argument numbers as well as exiting from the program with a different exit code for each branch.
The style reminds pretty much the C-style I was used to work with during my exams.
3.2 Ready? Go!
How can I execute another program from within the Perl wrapper?
Well, the simplest way that I was aware of is to call
execute, in other words, to work as a low level C:
sub launch($)
{
# take arguments
my ($program) = @_;
# execute the program
sleep(2);
exec($program);
}
3.3 How Many Instances can you Run?
How to define how many instances an user can run?
Here I decided to take inspiration from the
sudo policy file, and so I invented my own policy file with a pretty
simple syntax:
username@executable=instances
where:
username was the Unix username;executable was the name of the executable to run;instances was the number of the maximum allowed instances of the executable for the specified username.
And to make it looking mor eprofessional, I allowed the policy file to include a star in any field
in order to mean
anything or
any instance.
Of course, the above was full crap. For instance, if you were able to create a link from the
executable to another
with the right name you could change you allowance. But luckily, no user was able to do that, and to some
extent even the other sysadmins!
Having defined the policy file syntax, reading the file was as simple as:
sub getAllowedInstances($$$)
{
# take params
my ($policy_file, $username, $program) = @_;
my $instances = -1;
# try to open the policy file
open (POLICY_FILE_HANDLER, "<".$policy_file) || die("\nCannot parse policy file <$policy_file> !\n");
print "\nParsing configuration file $policy_file for program $program, username $username...";
$instances = 0; # by default do not allow a user to execute a program
# get each line from the policy file, and then search for the username
while ( $line = <POLICY_FILE_HANDLER> )
{
print "\n\t Configuration line: $line ";
# take only lines with the program name specified
if( grep("$program", $line) ){
@lineParts = split("@",$line);
$configUsername = $lineParts[0];
print "\ncontrollo se $username == $configUsername";
if ( $username eq $configUsername )
{
# this is the right line
# take the instances number
@pieces = split("=" , $line);
$instances = $pieces[1];
# remove the '\n'
chomp($instances);
print "\n\t\t\tUser allowance: $instances";
return $instances;
}
elsif ( $configUsername eq "*" )
{
# a valid entry for all users
# take the instances number
@pieces = split("=" , $line);
$instances = $pieces[1];
# remove the '\n'
chomp($instances);
print "\n\t\t\tGlobal allowance: $instances";
}
}
}
# no lines found, the user has no restrictions
return $instances;
}
What an amazing piece of code, uh?
Instead of reading the policy file once (or seldom), I was reading it fully every time I needed to check an user; it was
a very non-optimzed code.
Moreover, I was reading and grepping it a line at time, a very keyboard effort.
3.4 How much are you Running?
How to get the number of runnable instances an user was running?
Piece of cake: let's do it in Unix, backtick in Perl and increase by one:
sub getRunningInstancesCount($$)
{
# get parameters
my ( $program, $username ) = @_;
# get all processes for this program and the username
@processes = `ps -u $username | grep $program | grep -v "grep"`;
# get all lines count
$running_instances = 0;
if ( $#processes >= 0 )
{
$running_instances = $#processes + 1;
}
else
{
return 0;
}
return $running_instances;
}
Please note also the adoption of literals instead of variables: for example
return 0; instead of
return $running_instances where
the latter has been already initialized to zero.
3.5 All Pieces Together
Now, putting the places together made the main loop as simple as:
$RUNNING_INSTANCES = getRunningInstancesCount($BASE_NAME, $USERNAME);
print "\nYou're running $RUNNING_INSTANCES $BASE_NAME\n";
# if the user can, launch the program
if ( $RUNNING_INSTANCES < $ALLOWED_INSTANCES )
{
print "\nExecuting $PROGRAM...";
launch($PROGRAM);
print "\nBye!\n";
}
else
{
print "\nYou can't run no more instances of $PROGRAM";
print "\nBye\n";
displayMessage();
}
4 Lesson Learned
There is no lesson to learn here, but a lot of lessons learned in the between.
The only thing I could say is that you should never, never, throw away your code. Keep it, it is cheap, and someday you could
see how you progressed from a green programmer to the very guru developer you probably are today.
