Re: 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.

Comment on Re: Shebang behavior with perl Select or Download Code

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]
Re^3: Shebang behavior with perl (-w) by tye (Sage) on Mar 02, 2015 at 18:33 UTC
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]
Re^4: Shebang behavior with perl (-w) by MidLifeXis (Monsignor) on Mar 02, 2015 at 18:57 UTC
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^5: Shebang behavior with perl (-w) by tye (Sage) on Mar 02, 2015 at 22:29 UTC
Re^6: Shebang behavior with perl (-w) by BrowserUk (Patriarch) on Mar 03, 2015 at 06:40 UTC
Some notes below your chosen depth have not been shown here
Re^6: Shebang behavior with perl (use warnings) by tye (Sage) on Mar 03, 2015 at 05:41 UTC
Re^2: Shebang behavior with perl by Corion (Patriarch) on Mar 02, 2015 at 18:06 UTC
Also see Get default login environment and the ensuing discussion on how to `source` a shell script that sets up the environment from within Perl.	[reply] [d/l]


P is for Practical
	PerlMonks