Questions on Gbrowse CGI shebang lines and perl -S calls

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Questions on Gbrowse CGI shebang lines and perl -S calls

Richard Hayes
Hi,

The Gbrowse tarball ships with cgi-bin files all hard-coded with paths to the perl executable at /usr/bin/perl. I'm hoping there are better options than updating these hardcoded paths manually.

The same situation affects the shebangs of scripts under bin/ in the tarball releases.

Our servers use a custom perl installation, so we've had to adopt use of #!/usr/bin/env perl to pull the correct interpreter from our PATH.

1) Other than the need to use "use warnings" in place of the -w flag, are there portability issues that have delayed implementation of an env shebang line in Gbrowse?

2) Are there equivalent changes that can be made to these lines at the top of Gbrowse CGI scripts? I'm referencing the use of the -S perl switch, like:
eval 'exec /usr/bin/perl  -S $0 ${1+"$@"}'
    if 0; # not running under some shell

Updating this to replace "/usr/bin/perl" with "/usr/bin/env perl" or even just "perl" doesn't seem to work in (admittedly) limited testing. Am stuck changing the hardcoded paths to match my environment after each install (likely modifying the tarball I use each time)?

3) Why do some CGI script have that
eval 'exec /usr/bin/perl  -S $0 ${1+"$@"}'
line three or even four times? Since I probably need to update these scripts for our environment, would one be sufficient?

Thanks for taking the time to answer a rather esoteric set of questions!

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://www.phytozome.net

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: Questions on Gbrowse CGI shebang lines and perl -S calls

Richard Hayes
Any thoughts on this from others? I assume I'm stuck re-hardcoding perl executable paths at this point.

On Thu, Oct 17, 2013 at 3:19 PM, Richard Hayes <[hidden email]> wrote:
Hi,

The Gbrowse tarball ships with cgi-bin files all hard-coded with paths to the perl executable at /usr/bin/perl. I'm hoping there are better options than updating these hardcoded paths manually.

The same situation affects the shebangs of scripts under bin/ in the tarball releases.

Our servers use a custom perl installation, so we've had to adopt use of #!/usr/bin/env perl to pull the correct interpreter from our PATH.

1) Other than the need to use "use warnings" in place of the -w flag, are there portability issues that have delayed implementation of an env shebang line in Gbrowse?

2) Are there equivalent changes that can be made to these lines at the top of Gbrowse CGI scripts? I'm referencing the use of the -S perl switch, like:
eval 'exec /usr/bin/perl  -S $0 ${1+"$@"}'
    if 0; # not running under some shell

Updating this to replace "/usr/bin/perl" with "/usr/bin/env perl" or even just "perl" doesn't seem to work in (admittedly) limited testing. Am stuck changing the hardcoded paths to match my environment after each install (likely modifying the tarball I use each time)?

3) Why do some CGI script have that
eval 'exec /usr/bin/perl  -S $0 ${1+"$@"}'
line three or even four times? Since I probably need to update these scripts for our environment, would one be sufficient?

Thanks for taking the time to answer a rather esoteric set of questions!

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://www.phytozome.net


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse
Reply | Threaded
Open this post in threaded view
|

Re: Questions on Gbrowse CGI shebang lines and perl -S calls

Michael Dondrup-3
Hi Richard,

Afaik Gbrowse uses Module::Build for installation, which in my understanding does replace the shebang lines with the current perl during the
installation procedure (This is not so well documented except here: see http://search.cpan.org/~leont/Module-Build-0.4007/lib/Module/Build/API.pod).
==
fix_shebang_line(@files)
[version 0.??]

Modify any "shebang" line in the specified files to use the path to the perl executable being used for the current build. Files are modified in-place. The existing shebang line must have a command that contains "perl"; arguments to the command do not count. In particular, this means that the use of #!/usr/bin/env perl will not be changed.
==

If you want to use a different perl, it should be sufficient to use that explictly for Build.Pl, like in:

/another/bin/perl ./Build.PL

The lines
eval 'exec /usr/bin/perl -w -S $0 ${1+"$@"}'
    if 0; # not running under some shell
are autogenerated by either Module::Build or ExtendedUtils::MakeMaker. They are there for a hypothetical case where  e.g.
the script is run under "some shell" e.g. bash gbrowse_details. I think that this can be just ignored for a CGI script. I guess they occur
 multiple times because the scripts were checked into the repository directly from an installed version.

Disclaimer, I'm not affiliated to gmod.


Michael Dondrup
Postdoctoral fellow
Sea Lice Research Centre/Department of Informatics
University of Bergen
Thormøhlensgate 55, N-5008 Bergen,
Norway

On Oct 21, 2013, at 8:23 PM, Richard Hayes wrote:

> Any thoughts on this from others? I assume I'm stuck re-hardcoding perl executable paths at this point.
>
> On Thu, Oct 17, 2013 at 3:19 PM, Richard Hayes <[hidden email]> wrote:
> Hi,
>
> The Gbrowse tarball ships with cgi-bin files all hard-coded with paths to the perl executable at /usr/bin/perl. I'm hoping there are better options than updating these hardcoded paths manually.
>
> The same situation affects the shebangs of scripts under bin/ in the tarball releases.
>
> Our servers use a custom perl installation, so we've had to adopt use of #!/usr/bin/env perl to pull the correct interpreter from our PATH.
>
> 1) Other than the need to use "use warnings" in place of the -w flag, are there portability issues that have delayed implementation of an env shebang line in Gbrowse?
>
> 2) Are there equivalent changes that can be made to these lines at the top of Gbrowse CGI scripts? I'm referencing the use of the -S perl switch, like:
> eval 'exec /usr/bin/perl  -S $0 ${1+"$@"}'
>     if 0; # not running under some shell
>
> Updating this to replace "/usr/bin/perl" with "/usr/bin/env perl" or even just "perl" doesn't seem to work in (admittedly) limited testing. Am stuck changing the hardcoded paths to match my environment after each install (likely modifying the tarball I use each time)?
>
> 3) Why do some CGI script have that
> eval 'exec /usr/bin/perl  -S $0 ${1+"$@"}'
> line three or even four times? Since I probably need to update these scripts for our environment, would one be sufficient?
>
> Thanks for taking the time to answer a rather esoteric set of questions!
>
> Richard D. Hayes, Ph.D.
> Joint Genome Institute / Lawrence Berkeley National Lab
> http://www.phytozome.net
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk_______________________________________________
> Gmod-gbrowse mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Questions on Gbrowse CGI shebang lines and perl -S calls

Richard Hayes
Hi all,

I forgot to respond back with an update, but Module::Build did handle the custom perl path correctly.

There's still a mixture of the occasional additional

eval 'exec /usr/bin/perl -w -S $0 ${1+"$@"}'

lines that were not substituted, so a cgi-bin source cleanup is still a good idea to remove these extra lines. However, I've not seen any conflicts with the correctly substituted eval line that is listed first in those files...

Best regards,

Richard D. Hayes, Ph.D.
Joint Genome Institute / Lawrence Berkeley National Lab
http://www.phytozome.net


On Mon, Oct 21, 2013 at 12:19 PM, Michael Dondrup <[hidden email]> wrote:
Hi Richard,

Afaik Gbrowse uses Module::Build for installation, which in my understanding does replace the shebang lines with the current perl during the
installation procedure (This is not so well documented except here: see http://search.cpan.org/~leont/Module-Build-0.4007/lib/Module/Build/API.pod).
==
fix_shebang_line(@files)
[version 0.??]

Modify any "shebang" line in the specified files to use the path to the perl executable being used for the current build. Files are modified in-place. The existing shebang line must have a command that contains "perl"; arguments to the command do not count. In particular, this means that the use of #!/usr/bin/env perl will not be changed.
==

If you want to use a different perl, it should be sufficient to use that explictly for Build.Pl, like in:

/another/bin/perl ./Build.PL

The lines
eval 'exec /usr/bin/perl -w -S $0 ${1+"$@"}'
    if 0; # not running under some shell
are autogenerated by either Module::Build or ExtendedUtils::MakeMaker. They are there for a hypothetical case where  e.g.
the script is run under "some shell" e.g. bash gbrowse_details. I think that this can be just ignored for a CGI script. I guess they occur
 multiple times because the scripts were checked into the repository directly from an installed version.

Disclaimer, I'm not affiliated to gmod.


Michael Dondrup
Postdoctoral fellow
Sea Lice Research Centre/Department of Informatics
University of Bergen
Thormøhlensgate 55, N-5008 Bergen,
Norway

On Oct 21, 2013, at 8:23 PM, Richard Hayes wrote:

> Any thoughts on this from others? I assume I'm stuck re-hardcoding perl executable paths at this point.
>
> On Thu, Oct 17, 2013 at 3:19 PM, Richard Hayes <[hidden email]> wrote:
> Hi,
>
> The Gbrowse tarball ships with cgi-bin files all hard-coded with paths to the perl executable at /usr/bin/perl. I'm hoping there are better options than updating these hardcoded paths manually.
>
> The same situation affects the shebangs of scripts under bin/ in the tarball releases.
>
> Our servers use a custom perl installation, so we've had to adopt use of #!/usr/bin/env perl to pull the correct interpreter from our PATH.
>
> 1) Other than the need to use "use warnings" in place of the -w flag, are there portability issues that have delayed implementation of an env shebang line in Gbrowse?
>
> 2) Are there equivalent changes that can be made to these lines at the top of Gbrowse CGI scripts? I'm referencing the use of the -S perl switch, like:
> eval 'exec /usr/bin/perl  -S $0 ${1+"$@"}'
>     if 0; # not running under some shell
>
> Updating this to replace "/usr/bin/perl" with "/usr/bin/env perl" or even just "perl" doesn't seem to work in (admittedly) limited testing. Am stuck changing the hardcoded paths to match my environment after each install (likely modifying the tarball I use each time)?
>
> 3) Why do some CGI script have that
> eval 'exec /usr/bin/perl  -S $0 ${1+"$@"}'
> line three or even four times? Since I probably need to update these scripts for our environment, would one be sufficient?
>
> Thanks for taking the time to answer a rather esoteric set of questions!
>
> Richard D. Hayes, Ph.D.
> Joint Genome Institute / Lawrence Berkeley National Lab
> http://www.phytozome.net
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk_______________________________________________
> Gmod-gbrowse mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse



------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Gmod-gbrowse mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gmod-gbrowse