tneff@bfmny0.UU.NET (Tom Neff) (10/27/89)
For my money, if the program is SIMPLE enough to do in Bourne that's
the way you should do it. It really just doesn't matter how wonderful
some people think perl is, or C for that matter. Most vendor supplied
control scripts are in Bourne, so *your* new control scripts will fit in
most seamlessly by following the standard. If the job is too complex
for Bourne, then of course you use the simplest tool that suffices.
And please note that the cute device
#!/usr/bin/perl [-flags]
which lets some users run perl scripts directly by name as ziplessly as
if they were standalone executables, DOES NOT WORK everywhere. On my
system, it would be necessary to create companion shell scripts or Korn
shell aliases to invoke any such script.
But finally -- if a reader thinks a certain application ought to be in
one language rather than another, the way to show it is to submit a
version in the desired language! Not just sigh about the other fellow's
poor choice of platform.
--
'We have luck only with women -- \\\ Tom Neff
not spacecraft!' *-((O tneff@bfmny0.UU.NET
-- R. Kremnev, builder of FOBOS \\\ uunet!bfmny0!tneff (UUCP)lwall@jato.Jpl.Nasa.Gov (Larry Wall) (10/28/89)
In article <14810@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes:
: For my money, if the program is SIMPLE enough to do in Bourne that's
: the way you should do it. It really just doesn't matter how wonderful
: some people think perl is, or C for that matter. Most vendor supplied
: control scripts are in Bourne, so *your* new control scripts will fit in
: most seamlessly by following the standard.
There's definitely something to be said for this point of view. I don't
write Configure scripts in perl. (Yet.)
But an argument that says "If it's possible to do it the X way, then you must
do it the X way" doesn't carry much weight in my book.
And you speak of "the standard" as if it's something we shouldn't try
to change. I don't like that. I'm trying to change the standard.
Not to undo the toolbox approach--there's a proper place for that.
But to add another way to do the same things. This is the essence of
perl's philosophy: take most of Unix except the "Unix philosophy" (meaning
the use of chewing gum and bailing wire) and put it into one tool (that
can still be used within the "Unix philosophy") so that better integration
and portability becomes possible. You will never be "forced" to program
in perl, because I don't believe in The One True Way. I think there
should be Two or Three True Ways. I still program in C and shell. When
appropriate.
: If the job is too complex
: for Bourne, then of course you use the simplest tool that suffices.
To use the "simple" Bourne shell, you have to master the complexities of
many tools, which vary from machine to machine. We can't even decide
how to echo consistently. Portable shell programming is close to
impossible, and when you manage it, the result is unreadable. I suspect
portability and readability are the two main drivers for perl's rising
popularity. That and the price. :-)
: And please note that the cute device
:
: #!/usr/bin/perl [-flags]
:
: which lets some users run perl scripts directly by name as ziplessly as
: if they were standalone executables, DOES NOT WORK everywhere. On my
: system, it would be necessary to create companion shell scripts or Korn
: shell aliases to invoke any such script.
Not entirely true. The perl script can be its own companion shell script.
There's even a perl script to translate your perl scripts and insert the two
extra lines at the top.
: But finally -- if a reader thinks a certain application ought to be in
: one language rather than another, the way to show it is to submit a
: version in the desired language! Not just sigh about the other fellow's
: poor choice of platform.
I thought submitting a version in the desired language is precisely what
he did.
I hope nobody is feeling threatened by all this. Pluralism is at the
heart of perl, and the only imposition it will make on you in the coming
year is that you'll probably have to install it on your machine to keep
people happy. If your boss tells you to, you might even have to learn it.
But anyone who knows awk, sed, sh and C already knows most of perl.
'sides, it's one more thing you can put on your resume. :-)
Larry Wall
lwall@jpl-devvax.jpl.nasa.govpvo3366@sapphire.OCE.ORST.EDU (Paul O'Neill) (10/28/89)
In article <14810@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: > >And please note that the cute device > > #!/usr/bin/perl [-flags] > >which lets some users run perl scripts directly by name as ziplessly as >if they were standalone executables, DOES NOT WORK everywhere. On my >system, it would be necessary to create companion shell scripts or Korn >shell aliases to invoke any such script. > Perl is so cool. From the man page: -S makes perl use the PATH environment variable to search for the script (unless the name of the script starts with a slash). Typically this is used to emulate #! startup on machines that don't support #!, in the fol- lowing manner: #!/usr/bin/perl eval "exec /usr/bin/perl -S $0 $*" if $running_under_some_shell; The system ignores the first line and feeds the script to /bin/sh, which proceeds to try to execute the perl script as a shell script. The shell executes the second line as a normal shell command, and thus starts up the perl interpreter. On some systems $0 doesn't always contain the full pathname, so the -S tells perl to search for the script if necessary. After perl locates the script, it parses the lines and ignores them because the variable $running_under_some_shell is never true. Tom Christiansen obviously wrote the program to show off the language, not to do the job. Take a hint. You're not out in the cold if your vendor didn't supply it. Scarf it, install it. You and your users will thank you. Paul O'Neill pvo@oce.orst.edu Coastal Imaging Lab OSU--Oceanography Corvallis, OR 97331 503-754-3251