anantha%ravi@Sun.COM (Anantha Srirama) (01/05/90)
While installing latest PERL that was posted to the net I noticed the following: - It provided a lot of tests and examples as a part of package. This is great, but the '#! ....' had a path name that was hardcoded, /usr/bin/perl. I think it should be dynamic, in the sense that it should be driven by the INSTALL directory. It so happens that my install directory is not in /usr/bin but somewhere else, necessitating a manual edit of all the files to change this path. It could be done automatically after running the 'Configure' script. Just my two cents worth to make PEARL :-> installation easier. -Anantha- ******************************************************************************* Anantha Padmanabha N. Srirama | USENET: ...sun!anantha@Eng Sun Microsystems | ARPA: anantha@Eng.Sun.COM 2550, Garcia Ave. MS: 16-02 | Mt. View, CA-94043 | *******************************************************************************
rodney@sun.ipl.rpi.edu (Rodney Peck II) (01/06/90)
>>>>> On 4 Jan 90 18:41:45 GMT, anantha%ravi@Sun.COM (Anantha Srirama) said:
Anantha> While installing latest PERL that was posted to the net I
Anantha> noticed the following:
Anantha> - It provided a lot of tests and examples as a part of
Anantha> package. This is great, but the '#! ....' had a
Anantha> path name that was hardcoded, /usr/bin/perl.
Anantha> I think it should be dynamic, in the sense that it should be
Anantha> driven by the INSTALL directory. It so happens that my
Anantha> install directory is not in /usr/bin but somewhere else,
Anantha> necessitating a manual edit of all the files to change this
Anantha> path. It could be done automatically after running the
Anantha> 'Configure' script. Just my two cents worth to make PEARL
Anantha> :-> installation easier.
All you have to do is put a link from /usr/bin/perl to /usr/local/bin/perl
or wherever you actually installed it.
If you rely on the header pointing to exactly where your site's copy is, you
won't be able to run files off the net without changing their headers too.
I think the link solution is the right thing to do.
--
Rodneyanantha%ravi@Sun.COM (Anantha Srirama) (01/06/90)
rodney@sun.ipl.rpi.edu (Rodney Peck II) writes: >All you have to do is put a link from /usr/bin/perl to /usr/local/bin/perl >or wherever you actually installed it. >If you rely on the header pointing to exactly where your site's copy is, you >won't be able to run files off the net without changing their headers too. >I think the link solution is the right thing to do. >-- >Rodney This automatically assumes that I have write permissions in /usr/bin directory. This may not always be the case. I still say that the Configure should set it up. -Anantha- ******************************************************************************* Anantha Padmanabha N. Srirama | USENET: ...sun!anantha@Eng Sun Microsystems | ARPA: anantha@Eng.Sun.COM 2550, Garcia Ave. MS: 16-02 | Mt. View, CA-94043 | *******************************************************************************
tale@cs.rpi.edu (David C Lawrence) (01/06/90)
In <129933@sun.Eng.Sun.COM> anantha%ravi@Sun.COM (Anantha Srirama) writes: > This automatically assumes that I have write permissions in /usr/bin > directory. This may not always be the case. I still say that the > Configure should set it up. We (myself and mysterious other third parties I am invoking to support this position) disagree. It is an unnecessary editing step because the scripts can still be tested no matter what the #! line says, or even if it didn't exist. The test suite already provides a way to run all the tests together as they are, with the #! test set as /usr/bin/perl but with no perl there. If you want to run them seperately use perl as the command rather than the script itself. That's all the #! cookie ends up doing anyway. Dave -- (setq mail '("tale@cs.rpi.edu" "tale@ai.mit.edu" "tale@rpitsmts.bitnet"))
allbery@NCoast.ORG (Brandon S. Allbery) (01/07/90)
As quoted from <RODNEY.90Jan5142822@sun.ipl.rpi.edu> by rodney@sun.ipl.rpi.edu (Rodney Peck II): +--------------- | >>>>> On 4 Jan 90 18:41:45 GMT, anantha%ravi@Sun.COM (Anantha Srirama) said: | | Anantha> I think it should be dynamic, in the sense that it should be | Anantha> driven by the INSTALL directory. It so happens that my | Anantha> install directory is not in /usr/bin but somewhere else, | | All you have to do is put a link from /usr/bin/perl to /usr/local/bin/perl | or wherever you actually installed it. | If you rely on the header pointing to exactly where your site's copy is, you | won't be able to run files off the net without changing their headers too. | I think the link solution is the right thing to do. +--------------- I still think it is the wrong solution -- and that #! commits the sin of hard-coded pathnames. I want to keep non-OS programs out of /usr/bin and /bin, so that it's easy to reinstall the system and then restore added programs. (SunOS4 seems to have taken the same step, I believe. So how does this hardcoded /usr/bin/perl interact with a read-only /usr/bin?) ++Brandon -- Brandon S. Allbery allbery@NCoast.ORG, BALLBERY (MCI Mail), ALLBERY (Delphi) uunet!cwjcc.cwru.edu!ncoast!allbery ncoast!allbery@cwjcc.cwru.edu *(comp.sources.misc mail to comp-sources-misc[-request]@backbone.site, please)* *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
sean@ms.uky.edu (Sean Casey) (01/08/90)
rodney@sun.ipl.rpi.edu (Rodney Peck II) writes: |All you have to do is put a link from /usr/bin/perl to /usr/local/bin/perl |or wherever you actually installed it. This assumes that one has symlinks or that they are on the same file system. Sean -- *** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet, ukma!sean *** Copyright 1989 by Sean Casey. Only non-profit redistribution permitted. *** "Gotta warn ya, if you're not a RUSH fan, well, what's *wrong* with you?" *** -DJ during WKQQs Four HOURS of Rush special.