Uhm, this problem has been solved decades ago. Unix comes
with a large set of utilities. One doesn't have to remember
where a particular utility is located - that's why you have
a PATH environment variable. One doesn't have to
remember what the parameters of a utility are, that what
manual pages and usage messages are for. One doesn't even
have to remember which utility does what, that's what
apropos is for - and that will even show you which
Perl modules to use.
$ apropos localtime
localtime [ctime] (3) - transform date and time to broken-down tim
+e or ASCII
timegm (3) - inverses for gmtime and localtime
Time::localtime (3pm) - by-name interface to Perl's built-in loc
+altime() function
timelocal [timegm] (3) - inverses for gmtime and localtime
Time::tm (3pm) - internal object used by Time::gmtime and
+ Time::localtime
$
Abigail | [reply]
[d/l] |
I have found myself in the same situation. Often rather frustrating..
"I know I had a little tool to do this or but what was the syntax..?" etc. etc. The following are some simple tips that have helped me.
I got some advise about this type of thing and since I have started to
religiously do it I have not had this problem.
Firstly - Comment your code thoroughly.. this took me a little longer to code
anything when I started but now it is part of my process of getting anything done.. When I say thoroughly
I mean at the start of you program a detailed description of what it does and what its inputs are and what it outputs.
Also I find it helpfull to end with different error levels which I can check when my util has completed.. and you guessed it, I
document these also.Then, for each subroutine I do a similar thing.. inputs, outputs and what is returned.
Secondly - I build a html page with my utils in a table.. something like - | Utilname | Description and commandline args etc |
I started this type of thing ages ago and now all I have to do is keep adding to it..
Thirdly - If my util takes command line args I also include a usage subroutine that gets launched when I have not included any args. So by way of a silly example my code would look something like -
| [reply]
[d/l] |
| [reply] |
Have a usage flag that shows you the standard inputs and flags and a man page -- unix can't be so wrong. =)
-Waswas | [reply] |
And a shell with history - to remember last used inputs and flags.
| [reply] |
I have my emacs set up so that every time I create a new file with ".perl" at the end of the file name, it automatically inserts the following into the editing buffer:
#!/usr/bin/perl
=head1 NAME
=head1 SYNOPSIS
=head1 DESCRIPTION
=cut
use strict;
my $Usage = "$0 ";
The very next thing that happens, after I open this new perl file, is I fill in the blanks. Then I start to write perl code -- and if it is a command-line tool that I'm writing (almost always the case), the first code that I write is "die $Usage if ..." (or "unless...") with suitable conditions checking the command line args. (Naturally, Getopts::Long or Getopts::Std is usually involved in that part.)
I make a habit of never using "-?" as an actual command line option flag, so whenever I need to see the usage message, I run the script with "-?" as the sole option, which always causes the script to die and print $Usage. If that and the name of the script are not enough to remind me what the script is supposed to do (or what I'm supposed to do with it), the "$0" in the usage message always prints the full path to the script, and I can then paste that as an arg to "perldoc", to see the pod.
Apart from that, a perl-tk pod browser is definitely a good idea -- I have one that I adapted from sample code that came with the Perl/Tk bundle, to show all the docs for the core distribution and for all installed modules. It just does a system() call to run "xterm -e perldoc chosen-page &" (which uses "less" as the pager), so I can have as many scrollable man pages as I want on the screen at once. I just now posted that here (Code->GUI Programming->PerlMan). (Heh, since I adapted that from someone else's code, my normal emacs init didn't happen there -- but it's a GUI, it doesn't have command line args, so who cares...)
You could easily adapt that to all the perl programs in your arsenal, if these are all kept in places that are marked in your PATH environment variable, and if they all have a consistent file name pattern (e.g. *.pl or *.perl). Adding widgets for running command lines might be fun (or scary, depending on the roles you fill at your job). | [reply]
[d/l] |
