develooper Front page | perl.perl5.porters | Postings from August 2013

Re: Should runperl warn about "<"?

Thread Previous | Thread Next
From:
Zefram
Date:
August 31, 2013 12:53
Subject:
Re: Should runperl warn about "<"?
Message ID:
20130831125254.GD31643@fysh.org
Craig A. Berry wrote:
>                                   triggered the home-grown
>command-line redirection code on VMS (which is done within Perl, not
>by the CLI).

Yes, I saw.  I'm classing that as part of shell syntax for the present
purposes.  It is, as noted, not portable.

>Anything doing actual work with <> readline syntax wouldn't be affected.

Want to bet?  At the trivial level, "<>;" performs the useful work of
throwing away one line of input, after which other code can do something
more interesting with the following lines.

But more deeply, there's nothing objectively special about "<" at the
beginning of a CLI argument relative to "<" anywhere else.  After all,
if we're imitating Bourne shell redirection, introducing that distinction
makes a poor imitation.  (Bourne shell redirection is affected a little
bit by whitespace before "<", but that's only in the case where the
character before the whitespace is a digit.)  There's no reason why some
other platform wouldn't have "<" special in a place that looks to you
like the middle of an argument.

OK, let's look at better workarounds.  Partly because the unportability of
runperl pisses me off; partly because it's going to be fun.  The intention
is to get arbitrary code into an inferior perl process without using any
likely shell metacharacters on the constructed command line.  We can
avoid the general case of awkward characters by encoding the code of
interest in a way that uses innocuous characters, and having a small bit
of code to decode and eval it.  Then we only need to worry about awkward
characters in the decode/eval code.  Luckily, pack() can do most of the
heavy lifting.

	perl -eeval,for+pack+q+h28+,q+072796e6470222a4140584c5e622+

In this format, there's a single argument which consists only of
[-+,0-9a-z], characters quite unlikely to be interpreted specially
by any shell or anything pretending to be a shell.  This formulation
loses any exception resulting from compiling the inner code, but we
could work around that by introducing another layer of eval inside it,
with explicit handling of $@.

	sub rp {
		my $e = unpack("h*", $_[0]);
		system("perl -eeval,for+pack+q+h@{[length($e)]}+,q+$e+\n");
	}

Opinions on rebuilding runperl around this?

-zefram

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About