Shebang line management

Are there any clever ways of dealing with portability of the "shebang"
line... when moving Perl scripts across machines (and across operating
systems), where the path to Perl may be different?

For instance, I'm stuck doing initial development of some CGI scripts
on a Windows machine, but then deploying them to a *nix Apache server.
For each script, I'm manually cut-n-pasting to replace the:

#!"c:/perl/bin/perl.exe"

... with:

#!/usr/bin/perl

I was about to put together a script that would parse all my files and
change the shebang line programmatically, but before doing so I wanted
to see if anyone else had a more elegant approach in their own environment.

Re: Shebang line management

Steve wrote in
news:5v1lp2F1jn5dpU1@mid.individual.net:

> Are there any clever ways of dealing with portability of the
> "shebang"
> line... when moving Perl scripts across machines (and across operating
> systems), where the path to Perl may be different?
>
> For instance, I'm stuck doing initial development of some CGI
> scripts
> on a Windows machine, but then deploying them to a *nix Apache server.
> For each script, I'm manually cut-n-pasting to replace the:
>
> #!"c:/perl/bin/perl.exe"
>
> ... with:
>
> #!/usr/bin/perl
>
> I was about to put together a script that would parse all my
> files and
> change the shebang line programmatically, but before doing so I wanted
> to see if anyone else had a more elegant approach in their own
> environment.

This has been asked and answered on this group many times. The question
is somewhat off-topic.

Anyway, myy recommendation is to always use #!/usr/bin/perl with
whatever options you need on the shebang line and read

http://httpd.apache.org/docs/2.2/mod/core.html#scriptinterpr etersource

Sinan

--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines:

Re: Shebang line management

Steve wrote:

> Are there any clever ways of dealing with portability of the
> "shebang"
> line... when moving Perl scripts across machines (and across operating
> systems), where the path to Perl may be different?
>
> For instance, I'm stuck doing initial development of some CGI
> scripts
> on a Windows machine, but then deploying them to a *nix Apache server.
> For each script, I'm manually cut-n-pasting to replace the:
>
> #!"c:/perl/bin/perl.exe"
>
> ... with:
>
> #!/usr/bin/perl
>
> I was about to put together a script that would parse all my
> files and
> change the shebang line programmatically, but before doing so I wanted
> to see if anyone else had a more elegant approach in their own
> environment.

I use Apache Ant [1]. It also can do stuff like packing all your files
together in a zip, etc. In my experience, the she-bang line might not
be the only thing you want to replace, nor that replacing is limited to
Perl (related) files

example:








file="build/cgi-bin/script.cgi"
token="#!perl"
value="#!/usr/bin/perl"
/>


pattern="yyyyMMdd-kkmmss"
locale="en"/>



destfile="dist/${ant.project.name}-${time.stamp}.zip"/>






ant dist


[1] http://ant.apache.org/

--
John

Re: Shebang line management

Quoth "A. Sinan Unur" <1usa@llenroc.ude.invalid>:
> Steve wrote in
> news:5v1lp2F1jn5dpU1@mid.individual.net:
>
> > Are there any clever ways of dealing with portability of the
> > "shebang"
> > line... when moving Perl scripts across machines (and across operating
> > systems), where the path to Perl may be different?
>
> This has been asked and answered on this group many times. The question
> is somewhat off-topic.

Huh? How is it off-topic? Is it less OT if I tell you the correct answer
is 'use MakeMaker', which has a facility to do this for you?

That is, package up your scripts into a proper CPAN-like distribution
(it's not difficult), and tweak the Makefile.PL (or Build.PL, if you
must) to install the scripts where you want them. You need to set the
MakeMaker parameter INSTALLSCRIPT to something sensible, probably by
prompting the user to ask where the CGI directory lives (unless you can
work it out).

Ben

Re: Shebang line management

Ben Morrow wrote in
news:n57t55-bod1.ln1@osiris.mauzo.dyndns.org:

>
> Quoth "A. Sinan Unur" <1usa@llenroc.ude.invalid>:
>> Steve wrote in
>> news:5v1lp2F1jn5dpU1@mid.individual.net:
>>
>> > Are there any clever ways of dealing with portability of the
>> > "shebang"
>> > line... when moving Perl scripts across machines (and across
>> > operating systems), where the path to Perl may be different?
>>
>> This has been asked and answered on this group many times. The
>> question is somewhat off-topic.
>
> Huh? How is it off-topic?

I said "somewhat" because I interpreted this as a web server
configuration issue on Windows. There is no need to rely on the shebang
line for Apache on Windows to correctly run CGI scripts. By using
#!/usr/bin/perl, I have avoided the OP's issue for eons. I know there
might be systems where that line may not work, but it has worked for my
purposes.

I felt this might be crossing into a gray area of off-topicyness as the
answer I thought of would have applied to any CGI script written in any
programming language.

> Is it less OT if I tell you the correct
> answer is 'use MakeMaker', which has a facility to do this for you?

My CGI scripts are usually very short, only five or six lines. The
scripts instantiate the handler object and call its handle_request
method. I have not felt it necessary to use MakeMaker for the scripts
(although the libraries are indeed packaged properly).

> That is, package up your scripts into a proper CPAN-like distribution
> (it's not difficult), and tweak the Makefile.PL (or Build.PL, if you
> must) to install the scripts where you want them. You need to set the
> MakeMaker parameter INSTALLSCRIPT to something sensible, probably by
> prompting the user to ask where the CGI directory lives (unless you
> can work it out).

Good advice if the OP's needs are more sophisticated than mine.

Sinan

--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines:

Re: Shebang line management

Quoth "A. Sinan Unur" <1usa@llenroc.ude.invalid>:
> Ben Morrow wrote in
> news:n57t55-bod1.ln1@osiris.mauzo.dyndns.org:
> > Quoth "A. Sinan Unur" <1usa@llenroc.ude.invalid>:
> >> Steve wrote in
> >> news:5v1lp2F1jn5dpU1@mid.individual.net:
> >>
> >> > Are there any clever ways of dealing with portability of the
> >> > "shebang"
> >> > line... when moving Perl scripts across machines (and across
> >> > operating systems), where the path to Perl may be different?
> >>
> >> This has been asked and answered on this group many times. The
> >> question is somewhat off-topic.
> >
> > Huh? How is it off-topic?
>
> I said "somewhat" because I interpreted this as a web server
> configuration issue on Windows. There is no need to rely on the shebang
> line for Apache on Windows to correctly run CGI scripts. By using
> #!/usr/bin/perl, I have avoided the OP's issue for eons. I know there
> might be systems where that line may not work, but it has worked for my
> purposes.

Fair enough. The question is more general than just Apache-under-
Windows, though.

> > Is it less OT if I tell you the correct
> > answer is 'use MakeMaker', which has a facility to do this for you?
>
> My CGI scripts are usually very short, only five or six lines. The
> scripts instantiate the handler object and call its handle_request
> method. I have not felt it necessary to use MakeMaker for the scripts
> (although the libraries are indeed packaged properly).

You can include a script (or scripts) in the module distribution, and it
will be installed at the same time. If you can work out where to install
them to in your Makefile.PL, you get 'one-click' CGI installation :).

Ben

Re: Shebang line management

Steve wrote:
> Are there any clever ways of dealing with portability of the "shebang"
>line... when moving Perl scripts across machines (and across operating
>systems), where the path to Perl may be different?
>
> For instance, I'm stuck doing initial development of some CGI scripts
>on a Windows machine, but then deploying them to a *nix Apache server.
>For each script, I'm manually cut-n-pasting to replace the:
>
>#!"c:/perl/bin/perl.exe"
>
> ... with:
>
>#!/usr/bin/perl

Windows doesn't care about the shebang line, therefore you can use the Unix
version even on Windows.

jue

Re: Shebang line management

Ben Morrow wrote in
news:akju55-s1k2.ln1@osiris.mauzo.dyndns.org:

>
> Quoth "A. Sinan Unur" <1usa@llenroc.ude.invalid>:

>> ... it has worked for my purposes.
>
> Fair enough. The question is more general than just Apache-under-
> Windows, though.

I agree

>> My CGI scripts are usually very short, only five or six lines. The
>> scripts instantiate the handler object and call its handle_request
>> method. I have not felt it necessary to use MakeMaker for the scripts
>> (although the libraries are indeed packaged properly).
>
> You can include a script (or scripts) in the module distribution, and
> it will be installed at the same time. If you can work out where to
> install them to in your Makefile.PL, you get 'one-click' CGI
> installation :).

That makes it easier obviously. I'll follow your advice.

Sinan

--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines:

Re: Shebang line management

Jürgen Exner wrote in
news:21gpo314dqv6016j2teeq5ktrjhkuksla0@4ax.com:

> Steve wrote:
>> Are there any clever ways of dealing with portability of the
>> "shebang"
>>line... when moving Perl scripts across machines (and across operating
>>systems), where the path to Perl may be different?
>>
>> For instance, I'm stuck doing initial development of some CGI
>> scripts
>>on a Windows machine, but then deploying them to a *nix Apache server.
>>For each script, I'm manually cut-n-pasting to replace the:
>>
>>#!"c:/perl/bin/perl.exe"
>>
>> ... with:
>>
>>#!/usr/bin/perl
>
> Windows doesn't care about the shebang line, therefore you can use the
> Unix version even on Windows.

Windows shell does not but Apache under Windows does unless the
ScriptInterpreterSource directive is specified in httpd.conf.

Sinan


--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: