perl T-shirt and #!/usr/bin/perl -T conflict
by dws (Chancellor) on Jan 25, 2001 at 07:45 UTC
|
When I first saw this thread in Newest Nodes, I misread it as
perl T-shirt and #!/usr/bin/perl -T conflict
(I'd recently seen jima's note about the nifty Camel T-shirt, and probably hadn't had enough sleep.)
But I wonder, doesn't a t-shirt that reads
#!/usr/bin/perl -w
use strict;
cover only two of the four most common bits of advice handed out here? Wouldn't a truly monastery-compliant t-shirt begin
#!/usr/bin/perl -Tw
use strict;
use CGI; # don't reinvent the wheel
And then, on the back
(*)++ ( )-- ( )+= 0
| [reply] [d/l] [select] |
|
Unless things were very different back then, I'm wondering how ()+= 0 is monastary-compliant.
--
Linux, sci-fi, and Nat Torkington, all at Penguicon 3.0
perl -e 'print(map(chr,(0x4a,0x41,0x50,0x48,0xa)))'
| [reply] [d/l] |
|
It's an option in user-settings (so you can change your mind about voting on a node).
| [reply] |
Re: perl -T script.pl and #!/usr/bin/perl -T conflict
by rlk (Pilgrim) on Jan 24, 2001 at 23:54 UTC
|
Here's the simple solution.
#!/usr/bin perl -w
print "Script started\n";
eval {
exec("perl -wT $0") #Only works if taint mode off
};
print "Now we're in taint mode!\n";
Unfortunately, if your script is suid, this has a gaping security hole, as you've just executed an arbitrary program as root. (Was it /usr/bin/perl as you were expecting, or was it /home/l33t_hax0r/bin/perl? With an insecure $ENV{PATH}, you'll never know.)
Here's a version that fixes that particular hole
#!/usr/bin perl -w
print "Script started\n";
eval {
$ENV{PATH}, exec("/path/to/perl -wT $0") #Only works if ta
+int mode off
};
print "Now we're in taint mode!\n";
Eliminating the "useless use of a hash element in void context" message is left as an exercise for the reader. (Hint: look at the is_tainted function example in perlsec)
--
Ryan Koppenhaver, Aspiring Perl Hacker
"I ask for so little. Just fear me, love me, do as I say and I will be your slave."
| [reply] [d/l] [select] |
Re: perl -T script.pl and #!/usr/bin/perl -T conflict
by KM (Priest) on Jan 24, 2001 at 23:34 UTC
|
I assume you mean the 'Too late for "-T" option at script.pl line 1.' error.
This happens because you have run perl without -T, then when it examines the #! line
and sees -T, it realizes you want tainting, but it is too late. You need to make sure -T is
passed when using 'perl script.pl'. I know of no way around this, as opposed to aliasing 'perl'
with 'perl -T' or some similar lunacy.
Cheers,
KM | [reply] |
|
Neat related idea (and you know, I have princepawn to thank for making me think about this in the first place) -- you could also have a batch file (as you explained in the CB, you're worried about porting to win32), that calls perl.exe -T %1 (or however that's done =), call it (say) perlrun.bat, stick it in your PATH, and call the script as perlrun script.pl Philosophy can be made out of anything. Or less -- Jerry A. Fodor
| [reply] [d/l] [select] |
Re: perl -T script.pl and #!/usr/bin/perl -T conflict
by arturo (Vicar) on Jan 24, 2001 at 23:29 UTC
|
I'd just chmod 0755 script.pl so they can all execute it via a simple /path/to/script.pl , then tell 'em *NOT* to run it through the interpreter from the command-line unless they know what they're doing. The message you're getting is probably "Too late for -T switch". I don't think there is any way around this behavior, but if there is, I'm sure someone else who frequents this site does =)
Philosophy can be made out of anything. Or less -- Jerry A. Fodor
| [reply] [d/l] [select] |
Re: perl -T script.pl and #!/usr/bin/perl -T conflict
by japhy (Canon) on Jan 24, 2001 at 23:46 UTC
|
| [reply] |
|
| [reply] |