🚀 go-pugleaf

In article <1992Aug28.155801.14501@sei.cmu.edu> kochmar@sei.cmu.edu (John Kochmar) says:
: 
: In article <1992Aug28.145234.17625@news.eng.convex.com>, Tom Christiansen <tchrist@convex.COM> writes:
: |> ...
: |> In the particular case of perl, it really does make things *much*
: |> easier if there is an agreed-upon, standard location.  The 
: |> preferred strategy is to put a link in /usr/bin pointing to 
: |> where it actually lives, which varies from machine to machine.
: |> ...
: 
: OK, I'll bite: why is it that it is much easier if perl is in an agreed
: upon place like /usr/bin?

Because perl is a scripting language.  That means it wants to have a #!
line at the beginning with the path name to an executable.  Distributing
code in this situation can be an annoyance unless you can arrange to
have the path to perl be the same on different systems.

I'm not sure, though, that I would characterize this as "*much*
easer".  It isn't that hard to edit a file or sed a collection of
files.

: We use /usr/local for all tools that aren't part of the standard
: distribution that the vendor sends us, and I've made all sorts of
: software work cleanly while living in /usr/local (and, in almost all
: cases, without the use of symbolic links in /usr/bin.)  This model
: works really well for us, and most tools will work with this model
: if the programmers weren't of the lazy sort who like to hardwire
: paths into the binary.

But scripts have a path hardwired into them almost by definition.

--
Frank Peters  -  UNIX Systems Programmer  -  Mississippi State University
Internet: fwp@CC.MsState.Edu  -  Phone: (601)325-7030  -  FAX: (601)325-8921