[31794] in Perl-Users-Digest
Perl-Users Digest, Issue: 3057 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 2 06:09:21 2010
Date: Mon, 2 Aug 2010 03:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 2 Aug 2010 Volume: 11 Number: 3057
Today's topics:
Re: data structures/query question sln@netherlands.com
Re: data structures/query question sln@netherlands.com
Re: data structures/query question <m@rtij.nl.invlalid>
Re: Help with regular expression <markhobley@yahoo.donottypethisbit.co>
Re: Help with regular expression <hjp-usenet2@hjp.at>
Re: Help with regular expression <whynot@pozharski.name>
Re: If Perl is compiled on a 32-bit system, and the sys <nospam-abuse@ilyaz.org>
Re: If Perl is compiled on a 32-bit system, and the sys <hjp-usenet2@hjp.at>
Re: piped open and shell metacharacters <nospam-abuse@ilyaz.org>
Re: piped open and shell metacharacters <ben@morrow.me.uk>
Re: piped open and shell metacharacters (Alan Curry)
Re: piped open and shell metacharacters <jak@isp2dial.com>
Re: piped open and shell metacharacters <jak@isp2dial.com>
Re: piped open and shell metacharacters (Randal L. Schwartz)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 01 Aug 2010 15:34:18 -0700
From: sln@netherlands.com
Subject: Re: data structures/query question
Message-Id: <lvrb5655aqt7uht0ouududqdnao5b2d0i9@4ax.com>
On Wed, 21 Jul 2010 22:13:35 +0200, Martijn Lievaart <m@rtij.nl.invlalid> wrote:
>On Wed, 21 Jul 2010 07:33:52 -0700, ccc31807 wrote:
>
[snip ccc]
>> The positions that matched: fID 1BDD 1ADSS 1SC 1E 1SD 1ASD 1AA 1SSS 1ASC
>> 1DSS
>> ------------end output---------------------
>
>Your output does not match your sample data. F.i. there is no position
>code 1E.
>
>>
[snip ccc]
>OK, first note that we can skip any line that starts with a function code
>we're not interested in. After that, we just count the number of non-zero
>functions per position and print the ones that have the same number as
>the query.
>
>M4
>
>
>#!/usr/bin/perl
>
>use strict;
>use warnings;
>
># I/O simplyfied
># Error handling omitted
>
>my @in = qw/53ProcStuR 15DataEntr 54ProspStu 02AcadAdvUg 48PrtcipOr
>68Trnscrpt 69TrnfrCrd 27GrdProcA/;
>
>my $line = <DATA>;
>chomp $line;
>my @positioncodes = split /,/, $line;
>shift @positioncodes; # skip fID column
>
>my %positions;
>while ($line = <DATA>) {
chomp $line;
Because ",,,,,\n" and if ("\n") is true
and the output is:
The positions that matched: 1ASD 1BDD 1AA 1ADSS 1ASC 1CLK3
where 1CLK3 does not match:
1CLK3
15DataEntr, ,1
53ProcStuR, ,
54ProspStu, ,1
02AcadAdvUg, ,
48PrtcipOr, ,
68Trnscrpt, ,
69TrnfrCrd, ,
27GrdProcA, ,
> my ($function, @people) = split /,/, $line;
Here, every single line is split() even if it is not an
interresting line. I find it hard to believe there could be
millions of function id's, though there might be more position codes.
> next unless grep { $_ eq $function } @in; # skip uninteresting
^
grep's gonna loop through all @in every time.
Would there be better performance if it were a hash?
next unless exists $in{ $function };
-sln
------------------------------
Date: Sun, 01 Aug 2010 15:50:03 -0700
From: sln@netherlands.com
Subject: Re: data structures/query question
Message-Id: <kmtb565fip2brr7nr24b62ieu1tnln3v0t@4ax.com>
On Wed, 21 Jul 2010 07:33:52 -0700 (PDT), ccc31807 <cartercc@gmail.com> wrote:
>I've solved this twice, but still am not happy with my solution. I can
>post working code that meets the requirements, and I will do so. But
>first, I'd like to listen to the wisdom of this august body.
>
>I have reproduced a sample of the data file below. The top row
>consists of position codes. The left column consists of function
>codes. The cells consists of the number of people who have the
>position identified in the top row that perform the function
>identified in the left column.
>
>The requirement is: return a list of all position codes where at least
>one person with that position performs all the functions in the query.
>A query can look like this:
>----------------query (in.txt)----------------
>53ProcStuR 15DataEntr 54ProspStu 02AcadAdvUg 48PrtcipOr 68Trnscrpt
>69TrnfrCrd 27GrdProcA
>
>Here is a sample run:
>------------output-----------------
>jobs1>perl crunch_data_2.plx
>Enter the name of your data file (comma separated values): Consol.csv
>Enter the name of the functions file (space separated values): in.txt
>
>The functions you specified are: 53ProcStuR 15DataEntr 54ProspStu
>02AcadAdvUg 48PrtcipOr 68Trnscrpt 69Trn frCrd 27GrdProcA
>
>The positions that matched: fID 1BDD 1ADSS 1SC 1E 1SD 1ASD 1AA 1SSS
>1ASC 1DSS
>------------end output---------------------
I didn't see this post until now.
One thing, like Lievaart said, when you load the position codes into an array,
you have to shift out the first value because it throws off the results.
I don't know how big your data is, this is another method you can
benchmark to see how it is. If you need more information, like
how many people are available it would need counting code.
I imagine there is quite a few ways to do this.
-sln
-------------
use strict;
use warnings;
#
my %queryfuncs = map {$_ => ''} qw /
53ProcStuR 15DataEntr 54ProspStu 02AcadAdvUg
48PrtcipOr 68Trnscrpt 69TrnfrCrd 27GrdProcA /;
my $line = <DATA>;
defined $line or die "Can't find the position codes.";
chomp $line;
my @posncodes = split /,/, $line;
shift @posncodes;
@posncodes > 0 or die "0 number of position codes.";
my @flags = (1) x scalar @posncodes;
#
while( defined( $line = <DATA>))
{
chomp $line;
my ($func) = $line =~ /([^,]+),./;
next unless exists $queryfuncs{ $func };
my $ndx = 0;
for( split /,/, substr $line, length( $func) + 1 ) {
last if $ndx > $#flags;
$_ ||= 0;
$flags[$ndx++] = $flags[$ndx] && $_ > 0;
}
@flags[$ndx .. $#flags] = ();
}
for( 0 .. $#flags) {
print "$posncodes[$_]\n" if $flags[$_];
}
exit;
__DATA__
fID,1AA,1AAD,1AD,1ADA,1ADB,1ADBFA,1ADBO,1ADFG,1ADFS,1ADMAS,1ADOF,1ADSS,1AE,1AF,1AS,1AS2,1ASC,1ASD,1ASDSS,1ASST,1ATRD,1ATTD,1BD,1BDD,1BDR,1BDS,1BM,1CA,1CLK1,1CLK3
15DataEntr,31,1,1,1,1,1,1,,,1,1,5,1,1,1,1,4,6,1,1,1,1,1,3,1,1,,1,1,1
54ProspStu,31,,1,1,,,,,,1,1,5,1,,,,4,5,1,1,,,1,6,1,,,,1,1
03ClericSup,23,,,1,1,1,1,,1,1,,3,1,1,1,1,2,4,,1,1,1,,1,1,1,,1,1,1
48PrtcipOr,27,,1,1,,1,,,1,1,1,4,1,1,,1,3,5,1,,1,,,4,,,,,,
53ProcStuR,36,,1,1,,,,,,1,1,3,1,1,,,4,3,,,,,1,2,1,,,,,
42MPlnRcrt,12,1,,,,,,1,,,,3,,,,,1,5,,1,1,,1,7,1,1,,,,1
52PrepStuF,22,,,1,1,,,,,1,1,2,,1,,1,3,4,,,,,,1,,,,,,
55RcvScanD,13,,,,,1,,,,1,,,,1,,1,1,2,,1,1,1,,,,,,1,1,1
24FileDevM,15,,,1,1,1,,,,1,1,4,,1,1,1,2,3,1,1,,,,3,,,,1,1,1
56RecepDut,12,,,,,,,,,1,,,,1,,,1,2,,1,1,1,,,,,,1,1,1
65TestProc,18,,,1,,,,1,,,1,3,1,,,,4,2,,,1,,,2,,,,,,1
04AdmssProc,18,,,1,,,,,,1,1,3,1,1,,,3,3,,,,,,2,,,,,1,
02AcadAdvUg,30,,,1,,,,1,,,1,4,1,1,,,4,3,,,,,,2,,,,,,
27GrdProcA,23,1,,1,1,,1,,1,1,,6,,1,1,,2,4,1,1,,,,2,1,,,,,
09CommInvPR,8,1,1,,,,,1,,1,,2,,,,,2,4,1,1,,,1,7,1,1,,,,1
17RetenStr,7,1,1,1,,,,,,1,,4,,,,,2,6,1,,,,1,6,1,1,,,,
16RecrtStr,7,1,,,,,,1,,1,,1,1,,,,1,5,,,,,1,7,1,1,,,,
18DocImagi,9,,,1,,,,,,,1,2,,1,,1,2,3,,1,,,,,,,,1,1,
68Trnscrpt,27,,,,,,,,,,1,4,1,,,,2,3,,,,,1,1,1,,,,,
57RecrdsMa,8,,,1,1,1,,,,1,1,4,,1,,1,2,3,1,,,,,1,,,,,,
01AcadAdvGr,23,,,1,,,,1,,1,,6,,,,,3,3,,,,,,1,,,,,,
07ClassCoor,5,,1,1,,,,,,,1,3,,,,,1,6,,1,,,,,,,,,,1
58ReprtPre,9,,,,1,1,1,,,1,,1,,1,,1,1,2,1,,,1,,2,,,,1,,
28GrdProce,17,,1,1,,1,,,,,1,6,,,,1,3,3,1,,,,,,,,,,,
45SupEqpPu,1,,,,1,1,1,,1,,1,,,1,1,1,2,2,,,,1,,,,1,,,,
49EndTrmPr,20,,1,1,,,,,,,1,4,,,,,3,3,,,,,,,,,,,,
20EnrLeadM,3,1,,,,,,1,,1,,,,,,,1,3,1,,,,1,6,1,1,,,,
33MailRoom,1,,,,,1,,,1,,,,,1,1,1,1,2,,1,,1,,,,1,,1,,1
51ClassSch,4,1,,1,,,,,,,,2,1,,,,2,2,,,1,,,,,,,,,
29ImplPoli,1,1,1,,,1,2,1,,1,1,5,,,,,1,3,1,,,,,2,,,,,,
35MktgBusR,4,1,,,,,,,,1,,1,,,,,1,2,,,,,,6,,1,,,,
69TrnfrCrd,26,,,,,,,,,,1,3,1,,,,2,1,,,,,,1,,,,,,
13StuSvcsT,7,,1,1,,1,,,,,1,8,1,,,,2,3,1,,,,,1,,,,,,
70TrblshtS,7,,,,1,1,,,1,1,1,1,,1,1,1,3,2,,,,,,1,,,,,,
06BldgMonSe,3,1,,,,1,,,,,1,,1,,,,1,4,,,,,,,,,2,,,1
10HRDocs,,1,,,1,1,2,,1,,1,3,,,,,1,1,1,,,1,,,,,,,,
47OvrseeSt,5,,1,1,,1,,1,,,1,4,1,,,,1,2,1,,,,,,,,,,,
11ComplRpt,2,1,,,1,1,1,,,1,,,,1,,1,,2,,,1,,,1,,,,1,,
62StaffSup,,1,,,,1,1,,1,,1,3,,,,,1,1,,,,,,2,,,,,,
------------------------------
Date: Mon, 2 Aug 2010 07:32:40 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: data structures/query question
Message-Id: <os1ii7-slo.ln1@news.rtij.nl>
On Sun, 01 Aug 2010 15:34:18 -0700, sln wrote:
>>
>>my %positions;
>>while ($line = <DATA>) {
>
> chomp $line;
>
> Because ",,,,,\n" and if ("\n") is true and the output is:
> The positions that matched: 1ASD 1BDD 1AA 1ADSS 1ASC 1CLK3 where
> 1CLK3 does not match:
Good catch.
>
>> my ($function, @people) = split /,/, $line;
>
> Here, every single line is split() even if it is not an interresting
> line. I find it hard to believe there could be millions of function
> id's, though there might be more position codes.
"Make it right first, optimize later". But this is an obvious
optimazation, yes.
>
>> next unless grep { $_ eq $function } @in; # skip uninteresting
> ^
> grep's gonna loop through all @in every time. Would there be better
> performance if it were a hash? next unless exists $in{ $function };
Same, but as @in is relatively small, I doubt it's going to make a
(noticable) difference.
M4
------------------------------
Date: Sun, 1 Aug 2010 19:47:18 +0000 (UTC)
From: Mark Hobley <markhobley@yahoo.donottypethisbit.co>
Subject: Re: Help with regular expression
Message-Id: <i34j05$1be1$1@adenine.netfront.net>
On Sun, 25 Jul 2010 22:04:25 +0200, Peter J. Holzer wrote:
> Is this a match?
>
> (((1 + 2) * (3 +4)))
Yes. That is a match.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
------------------------------
Date: Mon, 2 Aug 2010 00:10:44 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Help with regular expression
Message-Id: <slrni5bs74.bff.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-01 19:47, Mark Hobley <markhobley@yahoo.donottypethisbit.co> wrote:
> On Sun, 25 Jul 2010 22:04:25 +0200, Peter J. Holzer wrote:
>
>> Is this a match?
>>
>> (((1 + 2) * (3 +4)))
>
> Yes. That is a match.
>
Then the problem cannot be solved with a real regular expression.
Perl regexps are an extension and can be used to match parentheses, so
it is probably possible to write one which solves your problem. However,
it will almost certainly be very hard to understand (the simple
solutions offered in this thread won't work).
I agree with Eric: Write a proper grammar and use that to parse your
expressions. If you've ever heard of BNF, using Parse::Yapp or
Parse::RecDescent shouldn't be too hard (I prefer the former, although
the docs assume that you are already familiar with yacc).
Alternatively, you can just walk through your string character by
character and note the start and end of each pair of parentheses (you
only need the last one at each level). If you've found two pairs where
start and end only differ by one character, you have a match.
hp
------------------------------
Date: Mon, 02 Aug 2010 10:06:12 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Help with regular expression
Message-Id: <slrni5crj4.k8d.whynot@orphan.zombinet>
with <slrni5bs74.bff.hjp-usenet2@hrunkner.hjp.at> Peter J. Holzer wrote:
*SKIP*
> I agree with Eric: Write a proper grammar and use that to parse your
> expressions. If you've ever heard of BNF, using Parse::Yapp or
> Parse::RecDescent shouldn't be too hard (I prefer the former, although
> the docs assume that you are already familiar with yacc).
Passed to Ted (Zlatanov). I've learned that from him.
*CUT*
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Sun, 1 Aug 2010 23:13:53 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: If Perl is compiled on a 32-bit system, and the system is upgraded to 64-bit...
Message-Id: <slrni5bvth.d3l.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-08-01, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> So a compiler could put stuff like
>
> * return addresses
> * non-array automatic variables which don't have their address taken
> * function arguments and return values
> * temporary variables
>
> into the stack segment and automatic variables which do have their
> address taken into the data segment.
> Among other things this means that return addresses are not accessible
> with a pointer and can't be overwritten by a buffer overflow.
Cool argument!
> Mozilla is a monster, but it still uses only about 40 MB of code memory,
> which is about 1% of 4 GB:
I suspect your system has 4K virtual address space granularity. Mine
has 64K. (And it has an order of magnitude less memory.)
What is important is the ratio of data/text. In your case, it is
less than 10. (With more memory, you run more of OTHER monsters. ;-)
> instead of 3.96GB for data. Doesn't seem like much of an improvement.
> (especially if you consider that on most 32-bit OSs the address space is
> limited to 2 or 3 GB anyway - lifting that limit would have a much
> larger effect).
No, the effect would be the opposite: 40M/2G is LARGER than 40M/4G. ;-)
>> AFAI suspect (basing on the sparse info I have seen), the only way to
>> load code on solaris is to write an executable module on disk, and
>> dlopen() it.
> That would absolutely kill the performance of a JIT compiler. If
> Solaris/x86 uses separate code and data segments (which I doubt) then
> there is probably some way (maybe with mmap) to map a region of memory
> into both the data and the code segment. More likely they use a common
> address space and just use mprotect to prevent execution of data which
> isn't meant to be code.
BTW, I looked, and OS/2 uses different segments for code and data.
(Although the paging data for them is almost identical, so they are
more or less aliases of each other.)
Yours,
Ilya
------------------------------
Date: Mon, 2 Aug 2010 11:16:40 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: If Perl is compiled on a 32-bit system, and the system is upgraded to 64-bit...
Message-Id: <slrni5d37o.m8f.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-01 23:13, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2010-08-01, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>> Mozilla is a monster, but it still uses only about 40 MB of code memory,
>> which is about 1% of 4 GB:
>
> I suspect your system has 4K virtual address space granularity.
Yes.
> Mine has 64K.
So that would increase the average internal fragmentation per code
region from 2 kB to 32 kB (half the granularity - of course that depends
on the size distribution but its good enough for a back of the envelope
calculation). On Linux Firefox maps 132 code regions into memory (the
GNOME people have a serious case of shared-libraryritis). So that's 132
* (32 kB - 2 kB) = 3960 kB or about 4 MB more. Noticable but probably
less than the effects of other differences between OS/2 and Linux.
> What is important is the ratio of data/text.
No. What is important is the ratio between code and the usable address
space.
> In your case, it is less than 10. (With more memory, you run more of
> OTHER monsters. ;-)
Yes, but those other monsters get their own virtual address space, so
they don't matter in this discussion.
>> instead of 3.96GB for data. Doesn't seem like much of an improvement.
>> (especially if you consider that on most 32-bit OSs the address space is
>> limited to 2 or 3 GB anyway - lifting that limit would have a much
>> larger effect).
>
> No, the effect would be the opposite: 40M/2G is LARGER than 40M/4G. ;-)
No, you misunderstood. If you now have an address space of 2 GB for
code+data, and you move the code to a different segment, you win 40MB
for data. But if the OS is changed to give each process a 4 GB address
space, then you win 2 GB, which is a lot more than 40 MB.
hp
------------------------------
Date: Sun, 1 Aug 2010 23:17:37 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: piped open and shell metacharacters
Message-Id: <slrni5c04h.d3l.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-08-01, John Kelly <jak@isp2dial.com> wrote:
>> /* handle the 2>&1 construct at the end */
>> if (*s == '>' && s[1] == '&' && s[2] == '1'
>> ...
>> if (!*t && (PerlLIO_dup2(1,2) != -1)) {
>> s[-2] = '\0';
>> break;
>> }
>> }
>
> Interesting it says "at the end"
> I wonder if placing it elsewhere in the command will circumvent Perl's
> shortcut and invoke a shell as usual.
At least with my initial implementation, only the position at the end
is special-cased.
Although your "as usual" looks suspicious. The *usual* case is a
shell-less execution. Only if shell metachars appear one is forced to
invoke the shell.
And, BTW, what would be your motivation to wish for a shell?
Yours,
Ilya
------------------------------
Date: Mon, 2 Aug 2010 00:39:14 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: piped open and shell metacharacters
Message-Id: <26dhi7-rm52.ln1@osiris.mauzo.dyndns.org>
Quoth John Kelly <jak@isp2dial.com>:
> On Sun, 1 Aug 2010 01:27:52 -0700 (PDT), "C.DeRykus" <derykus@gmail.com>
> wrote:
>
> >Yes, IIUC, it looks like there is a dup and the shell's
> >bypassed:
> >
> > From doio.c:
> >
> > /* handle the 2>&1 construct at the end */
> > if (*s == '>' && s[1] == '&' && s[2] == '1'
> > ...
> > if (!*t && (PerlLIO_dup2(1,2) != -1)) {
> > s[-2] = '\0';
> > break;
> > }
> > }
>
> Interesting it says "at the end"
>
> I wonder if placing it elsewhere in the command will circumvent Perl's
> shortcut and invoke a shell as usual.
No. Check the source if you're actually interested. '2>&1', with a space
before it and either a space or end-of-string after it, is ignored when
checking for shell special characters. It's only that exact string;
other shell redirections are left to the shell.
It may be worth noting that a command matching /^\.\s/, /^exec\s/ or
/^\w*=/ will also be passed to the shell[1].
Ben
[1] This is, of course, with *sane* semantics for \w and \s, viz.
[a-zA-Z0-9_] and [ \t\n\r\f] respectively, rather than the insane
Unicode semantics currently the default (some of the time).
------------------------------
Date: Mon, 2 Aug 2010 00:47:03 +0000 (UTC)
From: pacman@kosh.dhis.org (Alan Curry)
Subject: Re: piped open and shell metacharacters
Message-Id: <i354i7$3rp$1@speranza.aioe.org>
In article <26dhi7-rm52.ln1@osiris.mauzo.dyndns.org>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>It may be worth noting that a command matching /^\.\s/, /^exec\s/ or
>/^\w*=/ will also be passed to the shell[1].
The mention of exec made me wonder about other shell builtins. All of the
following fail on my system, where they are builtin to /bin/sh and not
available as external commands:
perl -e 'system "eval ls /"'
perl -e 'system "command ls /"'
perl -e 'system "set"'
perl -e 'system "times"'
perl -e 'system "read foo"'
All of the above would produce output (or in the last case, consume input) if
they were executed properly. Luckily, none of them are likely to be used for
any reason except to demonstrate the fact that they don't work.
--
Alan Curry
------------------------------
Date: Mon, 02 Aug 2010 01:47:09 +0000
From: John Kelly <jak@isp2dial.com>
Subject: Re: piped open and shell metacharacters
Message-Id: <4r8c56p0rl21ignhgnr0kesecm5h7m6o4c@4ax.com>
On Mon, 2 Aug 2010 00:47:03 +0000 (UTC), pacman@kosh.dhis.org (Alan
Curry) wrote:
>In article <26dhi7-rm52.ln1@osiris.mauzo.dyndns.org>,
>Ben Morrow <ben@morrow.me.uk> wrote:
>>
>>It may be worth noting that a command matching /^\.\s/, /^exec\s/ or
>>/^\w*=/ will also be passed to the shell[1].
>
>The mention of exec made me wonder about other shell builtins. All of the
>following fail on my system, where they are builtin to /bin/sh and not
>available as external commands:
>
>perl -e 'system "eval ls /"'
>perl -e 'system "command ls /"'
>perl -e 'system "set"'
>perl -e 'system "times"'
>perl -e 'system "read foo"'
>
>All of the above would produce output (or in the last case, consume input) if
>they were executed properly. Luckily, none of them are likely to be used for
>any reason except to demonstrate the fact that they don't work.
It's easy to force a shell with some no-op metacharacters:
perl -e 'system ":; eval ls /"'
--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
------------------------------
Date: Mon, 02 Aug 2010 01:50:48 +0000
From: John Kelly <jak@isp2dial.com>
Subject: Re: piped open and shell metacharacters
Message-Id: <8t8c56tq9eh69a9f6loos9fq0q7bmckhnv@4ax.com>
On Sun, 1 Aug 2010 23:17:37 +0000 (UTC), Ilya Zakharevich
<nospam-abuse@ilyaz.org> wrote:
>On 2010-08-01, John Kelly <jak@isp2dial.com> wrote:
>>> /* handle the 2>&1 construct at the end */
>>> if (*s == '>' && s[1] == '&' && s[2] == '1'
>>> ...
>>> if (!*t && (PerlLIO_dup2(1,2) != -1)) {
>>> s[-2] = '\0';
>>> break;
>>> }
>>> }
>>
>> Interesting it says "at the end"
>
>> I wonder if placing it elsewhere in the command will circumvent Perl's
>> shortcut and invoke a shell as usual.
>
>At least with my initial implementation, only the position at the end
>is special-cased.
>
>Although your "as usual" looks suspicious. The *usual* case is a
>shell-less execution. Only if shell metachars appear one is forced to
>invoke the shell.
>
>And, BTW, what would be your motivation to wish for a shell?
Most of the time, none. I was just wondering how things work. I like
the shell-less shortcut just fine.
--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
------------------------------
Date: Sun, 01 Aug 2010 22:29:56 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: piped open and shell metacharacters
Message-Id: <86sk2xoa3v.fsf@red.stonehenge.com>
>>>>> "John" == John Kelly <jak@isp2dial.com> writes:
John> It's easy to force a shell with some no-op metacharacters:
John> perl -e 'system ":; eval ls /"'
Even simpler, just append ";". Never changes the meaning, and it forces
/bin/sh in the mix.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3057
***************************************
