Re^2: top ten things every Perl hacker should know (script naming)

Perl source files (for scripts, not modules) should be named like whatItDoes.pl and checked in to source control. And you should have a script that "installs" your Perl scripts so that you can run them. That install script should do the following:

adjust the path in the #! (unless you are lucky enough to have enough control of all of your systems so that /usr/bin/perl is always appropriate as Larry intended)
copy the file into the appropriate directory in your PATH
rename the file so it no longer ends in ".pl" so that you execute it simply as "whatItDoes", like every other command you use (because a tool getting reimplemented in a different language should not cause you to have to invoke it any differently)
set execute permission (for some OSes)
run pl2bat (for other OSes) -- Note that some prefer other ways of making it so that, on Win32, you simply invoke a Perl script using an extensionless name (not "perl ..." nor "whatItDoes.pl ...") and I'm not arguing against such alternatives; I'm simply arguing needing to know what language the whatItDoes tool was written in in order to use it is a mistake. (:

Though certainly not necessarily in that order, or even as that many steps.

- tye

Comment on Re^2: top ten things every Perl hacker should know (script naming)

Replies are listed 'Best First'.

Re^3: top ten things every Perl hacker should know (script naming)
by tirwhan (Abbot) on Mar 16, 2006 at 08:33 UTC

Good list, but for

rename the file so it no longer ends in ".pl"

I think I'd prefer to create a link (hard or soft, whichever you feel more comfortable with) from whatItDoes to whatItDoes.pl, leaving the original file as it is. Only for those OSes that can do links of course.

All dogma is stupid.

[reply]
[d/l]

Re^4: top ten things every Perl hacker should know (link)

by tye (Sage) on Mar 16, 2006 at 18:57 UTC

Are you saying you'd link the executable to some working copy of the *.pl file that you have checked out (so that you can't edit without affecting those using it) or to the *.pl inside the revision control system (may not be possible, prevents you from checking in unfinished changes) or that you'd put *.pl files into your "bin" directory? I wouldn't put *.pl files into a "bin" directory, since it tempts the use of the *.pl file which would break when the script gets reimplemented or wrapped in something and it just adds clutter, IMO.

- tye

[reply]

Re^5: top ten things every Perl hacker should know (link)

by tirwhan (Abbot) on Mar 16, 2006 at 21:54 UTC

Yes, I would put the whatever.pl file in the bin directory, and almost precisely for the reason you give against it :-). This makes it possible for me to use whatever.pl directly in a script or system if I want that particular implementation. If you want to place a wrapper around it or reimplement it as "whatever", then that's fine, go ahead and I'll still be using the specific implementation I wrote my script against (and of course, if you're the admin there's nothing stopping you from linking whatever.pl to whatever, thereby forcing me to use the new implementation). Normal users will use whatever anyway and thus benefit from implementation changes directly.

Yes this can be abused, but it provides maximum flexibility. Polite requests over shotguns and all that.

All dogma is stupid.

[reply]
[d/l]

Re^6: top ten things every Perl hacker should know (link)

by tye (Sage) on Mar 16, 2006 at 23:48 UTC

Re^4: top ten things every Perl hacker should know (script naming)

by apotheon (Deacon) on Mar 16, 2006 at 19:26 UTC

I tend to "install" working copies of Perl programs normally, renamed without a file extension. When I'm working on code, though, I tend to keep it in a /home/username/src directory with a file extension, and softlink to it from a /home/username/bin directory with a shorter name (no file extension) so that I can test-run scripts more easily.

I guess maybe I'm somewhere between the two of you on this one.

print substr("Just another Perl hacker", 0, -2);
- apotheon
CopyWrite Chad Perrin

[reply]