in reply to Shebang behavior with perl

I've been exploring the use of:

sample:
#!/bin/sh
echo "This is shell"
SPECIAL_VAR=1
export SPECIAL_VAR
eval "exec perl -x -S $(dirname $0)/$(basename $0) ${1+\"\$@\"}"

#! -*- perl -*- -w
use strict;
print "This is Perl\n";
print "ARGV:".join(':',@ARGV)."\n";
print "SPECIAL_VAR: $ENV{SPECIAL_VAR}\n";

[download]

as a means of initializing an environment prior to execution of given perl code. The above configuration will preserve quote strings so calls like:

sample -multi "hello there" -single one

[download]

Will keep the "hello there" as a single value in ARGV. The dirname/basename combo supports execution from ./ or any other path as dirname will return '.' if the script is called without a path

The intent is to use "source .initenv" in the shell code to load environment initialization code shared across several perl scripts.

Replies are listed 'Best First'.
Re^2: Shebang behavior with perl
by MidLifeXis (Monsignor) on Mar 02, 2015 at 18:16 UTC

    I note that you are using perl -w to run your application. You probably likely will want to use warnings instead. -w will also cause other modules to emit warnings, even if they are not designed to run under the warnings pragma, which is probably not the behavior you usually want. use warnings; is lexically scoped, allowing you to control what modules you actually receive warnings from.

    --MidLifeXis

[reply]
[d/l]
[select]

      Well, that situation was part of the motivation for the creation of "use warnings". But, I find that this motivation mostly no longer applies and that "use warnings" has its own problems and those are now worse than the problems of "-w" in most environments that I encounter.

      For example, it is fairly common to work in a manner where treating undef as either 0 or the empty string is not a problem. In such an environment, I don't enable warnings. But if I use a "modern" module, then it will have turned on warning for itself. When I pass one of these undefs into that module, I'll likely get a warning when the module tries to use that value as a string or as a number.

      So, in that case, "use warnings" causes the exact same problem as the one you claim I should avoid by using it.

      So I have better luck making sure that I always use "-w" in module tests and that I enable warnings in run-time environments where the warnings won't be useless (or worse). It has been a very long time since I ran into a problem with a module producing unwanted warnings due to my use of "-w". It has not been a long time since I've seen unwanted warnings from "use warnings" in a module.

      - tye        

[reply]

        Wonderful. A large portion of my environment is used with a vendor's perl library that is not warnings safe. If the landscape has changed in modern perls to the point that warnings no longer 'does the right thing', then here be dragons. :-/

        Wait, let me wrap my head around what you are stating.... You are passing an undef into a module that has an unstated (and there is the issue) requirement that the value passed in is not undef. Wouldn't that be a bug in the modern module (poor spec/docs/defaults) or in your usage of the module? Not saying that your assumption is inappropriate, just that there is a gap between the assumptions of the user and provider of the code.

        --MidLifeXis

[reply]
Re^2: Shebang behavior with perl
by Corion (Patriarch) on Mar 02, 2015 at 18:06 UTC
[reply]
[d/l]

In Section Seekers of Perl Wisdom