On 1/18/13 5:19 PM, Andrew Johnson wrote:
> It seems the recommended way to handle this has changed a bit over the years.
> The current trend for both Perl and Python seems to be to use /usr/bin/env,
> which finds perl in the path without being quite so verbose:
>
> #!/usr/bin/env perl
>
> All modern Unix-type systems understand the #! line and have the env program
> in /usr/bin — even Solaris and Cygwin. The magical parts in the above eval
> were needed to get around various specific shells that might be executing the
> script, but I don't believe anyone will be trying to run EPICS on the exotic
> ones nowadays (and they're not needed if the script has a #! line).
>
> Windows does not understand either the #! line or any of the above magic, so
> the EPICS build system always explicitly includes $(PERL) in the command line
> and I think manually running perl scripts will always require that too.
Hi, Andrew.
In this case, it seems confusing to me that these would be installed
under bin on Windows if they're not executable. I suggest improving the
behavior under Windows by installing batch files in place of, or
alongside, Perl scripts installed under bin, that invoke the correct
Perl interpreter on the correct Perl script. If there's a possibility
that some Windows systems have executing batch scripts disabled, perhaps
the build system could create small executables for each Perl script to
be installed that invoke the correct Perl interpreter on the correct
Perl script.
Improving more, I would say that binaries ending in .pl are not a good
idea. If capr.pl is being installed under a bin directory, it should
just be named capr. The fact that it's written in Perl is irrelevant.
All I should know is that there's an executable called capr, and it does
something; I shouldn't care what language it's written in. Making this
change would make the change suggested in the above paragraph even cleaner.
> I propose to change the preamble of all the Perl scripts in base-3.14 to the
> above; any objections? There's a patch file of the necessary changes at
> http://www.aps.anl.gov/epics/base/R3-14/12-docs/envPerl.patch
This just depends on the meaning of the PERL build system variable.
Does it indicate the build-time Perl interpreter to use, the run-time
Perl interpreter to use, or both?
If it is ever the run-time Perl interpreter to use, I would expect
installed Perl scripts to use the interpreter specified by the PERL
build system variable, not choosing a Perl interpreter based on the
command search path. That's the behavior Murali wants, but it's easy to
imagine someone else *not* wanting that behavior.
On the other hand, if PERL just indicates the build-time Perl
interpreter to use, then your proposal seems an improvement over the
current behavior (based on your email; I haven't looked at your patch).
Lewis
- References:
- Alter Perl hashbang in capr.pl Shankar, Murali
- Re: Alter Perl hashbang in capr.pl Ralph Lange
- Re: Alter Perl hashbang in capr.pl Andrew Johnson
- Navigate by Date:
- Prev:
Re: Alter Perl hashbang in capr.pl Shankar, Murali
- Next:
Re: sequencer programs in an IOC Jiro Fujita
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Alter Perl hashbang in capr.pl Andrew Johnson
- Next:
Re: Alter Perl hashbang in capr.pl Shankar, Murali
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|