The points from Michael and Benjamin should explain why I don't think
we're likely to change what we ship (especially now that we have almost
everything using "#!/usr/bin/env perl").
I would rather we make life easy for new users than for packagers. If
Debian maintainers have to patch every Perl script to adjust the shebang
line, I think that's just a cost of doing the packaging under Debian's
guidelines. If someone uses perlbrew to install a newer Perl version
than comes with their OS, I'd much prefer that we automatically pick up
their new version immediately.
- Andrew
On 11/05/2018 09:48 AM, J. Lewis Muir wrote:
> On 09/11, J. Lewis Muir wrote:
>> Hi, all!
>>
>> I suggest that all EPICS-Base-installed Perl scripts should use an
>> absolute path to the desired Perl interpreter in their shebang line
>> rather than using env to invoke the interpreter.
>>
>> I'm reminded of this because of
>>
>> https://epics.anl.gov/core-talk/2018/msg00443.php
>>
>> in which Martin Konrad wrote:
>>
>>> Looking at the Perl scripts included in EPICS Base I'm wondering if it
>>> is really necessary to start some of them (see for example [1]) with the
>>> rather esoteric
>>>
>>> eval 'exec perl -S $0 ${1+"$@"}' # -*- Mode: perl -*-
>>> if $running_under_some_shell;
>>>
>>> rather than the usual "#!/usr/bin/perl" or "#!/usr/bin/env perl"
>>
>> I would much prefer the former over the latter, but it seems the latter
>> is what has been chosen! This was discussed on Tech-Talk in
>>
>> https://epics.anl.gov/tech-talk/2013/msg00098.php
>>
>> but I'll just say again, I think the pathname of the Perl interpreter
>> should be specified as a variable in an appropriate file under configure
>> and for that to be used in the shebang line of all installed Perl
>> scripts. I would like scripts to work without requiring perl to be
>> on the command search path, and I would like to be able to specify
>> which perl is used for the scripts when they are installed rather than
>> whatever perl is first on the command search path. This way, the
>> scripts do not rely on the command search path to find perl, and if
>> multiple versions of Perl are installed, or if the perl that is first
>> on the command search path changes, I can be sure that the installed
>> scripts will continue to work. For more on this opinion, see
>>
>> http://julio.meroh.net/2016/09/env-considered-harmful.html
>>
>> Thanks!
>>
>> Lewis
>
> Hello!
>
> Would any core developers be willing to weigh in on this?
>
> Here's the archive of the thread in case you no longer have it:
>
> https://epics.anl.gov/core-talk/2018/msg00448.php
>
> The only core developer who replied to this thread was Michael
> Davidsaver, but that was not about this, it was about a thread hijack on
> bashisms.
>
> Thanks!
>
> Lewis
>
--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon
- References:
- Perl scripts shebang: /usr/bin/perl vs. /usr/bin/env perl J. Lewis Muir
- Re: Perl scripts shebang: /usr/bin/perl vs. /usr/bin/env perl J. Lewis Muir
- Navigate by Date:
- Prev:
Re: Perl scripts shebang: /usr/bin/perl vs. /usr/bin/env perl Benjamin Franksen
- Next:
Build failed in Jenkins: epics-base-3.15-win64 #379 APS Jenkins via Core-talk
- Index:
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: Perl scripts shebang: /usr/bin/perl vs. /usr/bin/env perl Michael Davidsaver
- Next:
Re: Perl scripts shebang: /usr/bin/perl vs. /usr/bin/env perl Benjamin Franksen
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|