[32405] in Perl-Users-Digest
Perl-Users Digest, Issue: 3672 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Apr 22 14:09:23 2012
Date: Sun, 22 Apr 2012 11:09:07 -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 Sun, 22 Apr 2012 Volume: 11 Number: 3672
Today's topics:
Re: Optionally avoid AutoLoader <ben@morrow.me.uk>
Re: Optionally avoid AutoLoader <marc.girod@gmail.com>
Re: Perl on a Mac - again <ben@morrow.me.uk>
Re: Perl on a Mac - again <mvdwege@mail.com>
Re: Perl on a Mac - again <mvdwege@mail.com>
Re: Perl on a Mac - again <jurgenex@hotmail.com>
Re: Perl on a Mac - again <jurgenex@hotmail.com>
Re: Perl on a Mac - again <ben@morrow.me.uk>
Re: Perl on a Mac - again (Tim McDaniel)
Re: Perl on a Mac - again <m@rtij.nl.invlalid>
Re: Perl on a Mac <ben@morrow.me.uk>
Re: Perl on a Mac <ben@morrow.me.uk>
Re: Perl on a Mac <jurgenex@hotmail.com>
Re: Perl on a Mac (Jens Thoms Toerring)
Re: Perl on a Mac <uri@stemsystems.com>
Re: Perl on a Mac (Tim McDaniel)
Re: Perl on a Mac (Tim McDaniel)
Re: Perl on a Mac (Tim McDaniel)
Re: Why does this code works without cat ? <hjp-usenet2@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 22 Apr 2012 12:03:07 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <b45d69-ik4.ln1@anubis.morrow.me.uk>
Quoth Marc Girod <marc.girod@gmail.com>:
> On Apr 21, 6:40 pm, Marc Girod <marc.gi...@gmail.com> wrote:
>
> > Unfortunately not...
> > The debugger really doesn't see beyond:
> ...
> > Line 18 not breakable.
>
> Maybe a judicious 'use #line' is what I miss here...
Not 'use #line', just a line like
#line 27 /.../ClearCase/Wrapper.pm
of the sort used and produced by cpp(1).
> I thought of a problem with this approach: the strict and warnings
> reports are issued while compiling, and the compilation took place
> with autosplitting.
> Hence, I'll have already missed them...
No it didn't. AutoSplit treats the code to be split purely as text, it
doesn't compile it. In any case, if you pass the code through 'eval' or
'require' it will be compiled again, regardless of what has happened to
it in the past.
Ben
------------------------------
Date: Sun, 22 Apr 2012 09:13:07 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <2c336c5a-6f95-45a6-879d-7f06d454f605@h12g2000yqi.googlegroups.com>
On Apr 22, 12:03=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Not 'use #line', just a line like
Sorry but then... it is already there: AutoSplit put it!
I have in describe.al (line 6):
#line 2871 "blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into blib/lib/
auto/ClearCase/Wrapper/MGi/describe.al)"
Now, this seems (in this context) to create a problem for the debugger
(perl -d).
- I cannot put a breakpoint beyond this point, using either the
original or the corrected line number
- The 'v' command refuses to show any code
- However, 'c' happily continues...
> No it didn't. AutoSplit treats the code to be split purely as text, it
> doesn't compile it.
OK. Only, in the normal development lifecycle, which I'd wish to
disturb as little as possible for backwards compatibility reasons,
autosplit is invoked as part of the 'make' --a bit in an obscure/
implicit way: I can only find in the generated Makefile:
# --- MakeMaker tool_autosplit section:
# Usage: $(AUTOSPLITFILE) FileToSplit AutoDirToSplitInto
AUTOSPLITFILE =3D $(ABSPERLRUN) -e 'use AutoSplit; autosplit($
$ARGV[0], $$ARGV[1], 0, 1, 1)' --
...which matches the AutoSplit documentation:
Typical use of AutoSplit in the perl MakeMaker utility is via
the command-
line with:
perl -e 'use AutoSplit; autosplit($ARGV[0], $ARGV[1], 0, 1,
1)'
Will the splitting take place if the build fails?
As it would because of a strict/warnings report...
I cannot understand why/how these messages are lost (in my
experience...).
Looking at the AutoLoader::AUTOLOAD code, it seems to croak such
messages:
if ($@){
$@ =3D~ s/ at .*\n//;
my $error =3D $@;
require Carp;
Carp::croak($error);
}
> In any case, if you pass the code through 'eval' or
> 'require' it will be compiled again, regardless of what has happened to
> it in the past.
OK. This is what I do now, in my tentative code (following your
suggestion).
Thanks a lot for your continued attention!
Marc
------------------------------
Date: Sun, 22 Apr 2012 11:59:43 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl on a Mac - again
Message-Id: <vt4d69-ik4.ln1@anubis.morrow.me.uk>
Quoth Hacker <hacker@ace158.com>:
> On 2012-04-22 08:21:32 +0000, Peter Makholm said:
> >
> > You current working directory is not in $PATH and you end up with
> > calling /bin/test.
>
> Ok, cool - all these little things.
> Would a ~/.bashrc something with path help.
> I can not remember how you append $PATH, yuk.
*Do not* put the current directory in $PATH. Learn to write ./foo if
that's what you mean: you aren't using DOS any more.
Ben
------------------------------
Date: Sun, 22 Apr 2012 13:05:15 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Perl on a Mac - again
Message-Id: <86sjfw10yc.fsf@gaheris.avalon.lan>
Hacker <hacker@ace158.com> writes:
> On 2012-04-22 08:09:41 +0000, Martijn Lievaart said:
>
>> On Sun, 22 Apr 2012 10:03:26 +0200, Hacker wrote:
>>
>>> On 2012-04-22 06:11:26 +0000, Hacker said:
>>>
>>>> I have a little Perl program here:
>>>>
>>>> #!usr//bin/perl print "Hello World";
>>>>
>>>> it is called 'test'.
>>>>
>>>> When I write 'perl test' on the command line it works fine and comes
>>>> out with 'Hello World' just as it should, but when I write 'test' on
>>>> the command line there is no output.
>>>>
>>>> What is wrong.
>>>
>>> Considering I had written #!usr//bin/perl right as #!/usr/bin/perl but
>>> that is corrected now and there is still no output when you 'execute'
>>> the file.
>>>
>>> Any real dogs out there, or am I a moron.
>>
>> You are executing the test binary. Do a which test to see what you are
>> executing,or use ./test to start your own script.
>>
>> M4
>
> Cool, but I did not understand a thing :-(
By default your current directory is not in the shell search path for
executables. So if you execute 'test' from a shell prompt, the shell
will search its path (held in the $PATH environment variable) to search
for an executable named test. As it so happens, there is an executable
named test in the path, and it lives in /bin.
If you want to execute something from your current directory, you have
to provide an explicit path to it. The way to do that is to prepend ./
to it, or to give an absolute path from the root.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Sun, 22 Apr 2012 13:07:28 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Perl on a Mac - again
Message-Id: <86obqk10un.fsf@gaheris.avalon.lan>
Mart van de Wege <mvdwege@mail.com> writes:
>
> By default your current directory is not in the shell search path for
> executables. So if you execute 'test' from a shell prompt, the shell
> will search its path (held in the $PATH environment variable) to search
> for an executable named test. As it so happens, there is an executable
> named test in the path, and it lives in /bin.
And as someone else helpfully pointed out, 'test' is not even in the
path, it's a shell built-in.
Meh. My mistake.
As for your other question, don't edit .bashrc to add the current
directory to $PATH. That's a security risk. Just use ./ or copy your
script to a directory in $PATH.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Sun, 22 Apr 2012 04:34:19 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl on a Mac - again
Message-Id: <3hq7p75mesjjbau6oahhsdik73b0auf0de@4ax.com>
Hacker <hacker@ace158.com> wrote:
>I have a little Perl program here:
>
>#!usr//bin/perl
>print "Hello World";
>
>it is called 'test'.
>
>When I write 'perl test' on the command line it works fine and comes out with
>'Hello World' just as it should, but when I write 'test' on the command line
>there is no output.
>
>What is wrong.
You made a very typical Unix beginner's mistake by naming your program
"test". Don't do that. "test" is an existing binary or a shell built-in
command and usually takes precedence over a command in the CWD.
Use a different name for your program or call your own program by
explicitely referring to the local program as "./test".
Further details please see a Unix NG because this has nothing to do with
Perl.
jue
PS: why changing your ID? Do you really believe you can fool anybody if
you call yourself Hacker instead of Torsten Jørgensen?
You are using the same provider, same user agent, same settings, same
area of question, and same level of knowledge. That speaks much stronger
than your ID.
------------------------------
Date: Sun, 22 Apr 2012 04:43:29 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl on a Mac - again
Message-Id: <s7r7p7d6qbnlsf874h5taiji2mqfnq2m6h@4ax.com>
Hacker <hacker@ace158.com> wrote:
>> You current working directory is not in $PATH and you end up with
>> calling /bin/test.
>
>Would a ~/.bashrc something with path help.
Don't! There is a very good reason why the CWD is not included in your
search path. And least of all at the beginning.
This has been a very frequent Unix beginners complain for the past 2
decades and I suggest you consult the archives or Unix FAQs for an
explanation why it is the way it is. Once you understand the reason
behind it then you can make your own decision if you want to change the
behaviour for yourself.
And no, it doesn't have anything to do with Perl.
>I can not remember how you append $PATH, yuk.
You should first understand why the CWD is not included in the path.
Only then can you make a concious and educated decision if for you it
makes sense to add the CWD or not.
jue
------------------------------
Date: Sun, 22 Apr 2012 14:45:09 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl on a Mac - again
Message-Id: <5ked69-pr5.ln1@anubis.morrow.me.uk>
Quoth Mart van de Wege <mvdwege@mail.com>:
> Mart van de Wege <mvdwege@mail.com> writes:
>
> > By default your current directory is not in the shell search path for
> > executables. So if you execute 'test' from a shell prompt, the shell
> > will search its path (held in the $PATH environment variable) to search
> > for an executable named test. As it so happens, there is an executable
> > named test in the path, and it lives in /bin.
>
> And as someone else helpfully pointed out, 'test' is not even in the
> path, it's a shell built-in.
This is not necessarily the case. POSIX /bin/sh has neither test nor [
built in, and therefore relies on them existing as executables in /bin.
Many modern shells do provide them as builtins, and many (most? all?)
modern systems install one of these shells as /bin/sh, though, so it's
likely you will see them as builtins.
Ben
------------------------------
Date: Sun, 22 Apr 2012 17:27:38 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Perl on a Mac - again
Message-Id: <jn1f2a$pm2$1@reader1.panix.com>
In article <5ked69-pr5.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth Mart van de Wege <mvdwege@mail.com>:
>> Mart van de Wege <mvdwege@mail.com> writes:
>>
>> > By default your current directory is not in the shell search path
>> > for executables. So if you execute 'test' from a shell prompt,
>> > the shell will search its path (held in the $PATH environment
>> > variable) to search for an executable named test. As it so
>> > happens, there is an executable named test in the path, and it
>> > lives in /bin.
>>
>> And as someone else helpfully pointed out, 'test' is not even in
>> the path, it's a shell built-in.
>
>This is not necessarily the case. POSIX /bin/sh has neither test nor
>[ built in, and therefore relies on them existing as executables in
>/bin. Many modern shells do provide them as builtins, and many
>(most? all?) modern systems install one of these shells as /bin/sh,
>though,
A bad practice that I've seen decryed. If you have a script that
depends on some feature of the original Bourne shell, or strict POSIX
compatibility, it's really nasty to have /bin/sh be something else.
Better, and I think (or at least hope more common) is to simply
provide a different login shell. For example, on my ISP,
tmcd:*:<uid>:<gid>:Tim McDaniel:<home directory>:/usr/local/bin/bash
>so it's likely you will see them as builtins.
And if not, as /bin/test and such -- and "." may yet be in your PATH
but at the end, so that /bin is hit first. I don't ever put "." in
PATH because it's a security hole on multi-user systems.
All this is a lot of detail. Short form:
- don't name a test program "test"
- invoke your own test programs with a path like ./foo or ~/foo
or /home/login/foo
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 22 Apr 2012 19:59:33 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Perl on a Mac - again
Message-Id: <5htd69-jao.ln1@news.rtij.nl>
On Sun, 22 Apr 2012 17:27:38 +0000, Tim McDaniel wrote:
> A bad practice that I've seen decryed. If you have a script that
> depends on some feature of the original Bourne shell, or strict POSIX
> compatibility, it's really nasty to have /bin/sh be something else.
All serious bourne like shells emulate a POSIX sh if called as sh.
> Better, and I think (or at least hope more common) is to simply provide
> a different login shell. For example, on my ISP,
>
> tmcd:*:<uid>:<gid>:Tim McDaniel:<home directory>:/usr/local/bin/bash
Bash called as bash, all bash goodies available. On most systems I know /
bin/sh is either a symlink or a hardlink to ksh or bash. If you feel that
is a problem, you have a lot of vendors to convince.
M4
------------------------------
Date: Sun, 22 Apr 2012 11:56:34 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl on a Mac
Message-Id: <2o4d69-ik4.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <6sv6p7p0pcajnlc9accg7kp2kspn3a0ae0@4ax.com>,
> J_rgen Exner <jurgenex@hotmail.com> wrote:
> >Torsten J_rgensen <info@stconinc.com> wrote:
> >>Does it understand #!/usr/bin/perl.
> >
> >No, it doesn't. It doesn't on any OS because the shebang line is a
> >function of the shell, not of Perl.
>
> That happens not to be the case. In UNIX and UNIX derivatives,
The kernel implementation of #! is a BSD thing, though I believe it
made its way into all the SysVs eventually.
Ben
------------------------------
Date: Sun, 22 Apr 2012 11:52:54 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl on a Mac
Message-Id: <6h4d69-ik4.ln1@anubis.morrow.me.uk>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
> Torsten Jørgensen <info@stconinc.com> wrote:
> >Does it understand #!/usr/bin/perl.
>
> No, it doesn't. It doesn't on any OS because the shebang line is a
> function of the shell, not of Perl. Perl doesn't care about the shebang
> line(*).
Nonsense. #! is implemented in the kernel, and yes, the OS X kernel does
understand it.
> >Can the Terminal run shell scripts.
>
> Why not?
>
> *: actually there are hacks for some OSs where Perl will parse arguments
> from the shebang line because the command interpreter on those OSs does
> not recognize the shebang line.
Perl always parses arguments from the #! line, on all OSs. Even on OSs
which understand #!, the kernel always passes the whole of the rest of
that line (up to a fixed limit) as one argument, and on some OSs that
limit was rather small. Perl goes to some trouble to sort out the
resulting mess so you can apparently put several arguments on the #!
line and it will Just Work.
Ben
------------------------------
Date: Sun, 22 Apr 2012 04:18:42 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl on a Mac
Message-Id: <bnp7p7hojt1efhvrdihu823e83rdb79i0b@4ax.com>
Torsten Jørgensen <info@stconinc.com> wrote:
>On 2012-04-22 03:51:59 +0000, Jürgen Exner said:
>
>> Torsten Jørgensen <info@stconinc.com> wrote:
>>> Does it understand #!/usr/bin/perl.
>>
>> No, it doesn't. It doesn't on any OS because the shebang line is a
>> function of the shell, not of Perl. Perl doesn't care about the shebang
>> line(*).
>
>I know, I meant the shell...
Ok.
Sorry, I can only read what you are writing, not what you are thinking.
>>> Can the Terminal run shell scripts.
>>
>> Why not?
>
>Except that it comes out with -bash: seek.pl: command not found
>when I try to run this:
>
>#!/usr/bin/perl
>print "Hello World";
Then I would guess there is no executable program named perl at
/usr/bin. Maybe it is not installed? Maybe it is in a different
location? Maybe access rights are incorrect?
>> *: actually there are hacks for some OSs where Perl will parse arguments
>> from the shebang line because the command interpreter on those OSs does
>> not recognize the shebang line.
>
>But OSX Lion does...
That's fine. I was merely mentioning that on certain OSs there are
exceptions to the standard behaviour of Perl.
>And by the way, keep your inuendo to yourself, it is insulting.
-v, please?
jue
------------------------------
Date: 22 Apr 2012 13:12:07 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: Perl on a Mac
Message-Id: <9vied7Fh80U2@mid.uni-berlin.de>
Torsten Jørgensen <info@stconinc.com> wrote:
> On 2012-04-22 03:51:59 +0000, Jürgen Exner said:
> > Torsten Jørgensen <info@stconinc.com> wrote:
> >> Does it understand #!/usr/bin/perl.
> >
> > No, it doesn't. It doesn't on any OS because the shebang line is a
> > function of the shell, not of Perl. Perl doesn't care about the shebang
> > line(*).
> I know, I meant the shell...
> >> Can the Terminal run shell scripts.
> >
> > Why not?
> Except that it comes out with -bash: seek.pl: command not found
> when I try to run this:
I've no experience with Macs but I heard that their OS is based
on BSD. And if that's the case you may have to put "./" in front
of the scripts name when you try to run it from the shell, i.e.
use
./seek.pl
since the current directory isn't necessarily in the paths the
shell looks for programs in. And, of course, to get it to work,
you also need the "execute" flag set for the script, i.e. you
may have to set the execute permission with a command like
chmod +x seek.pl
Without the execute flag being set the "#!" won't do anything.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Sun, 22 Apr 2012 13:27:38 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Perl on a Mac
Message-Id: <87ipgroewl.fsf@stemsystems.com>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> Perl always parses arguments from the #! line, on all OSs. Even on OSs
BM> which understand #!, the kernel always passes the whole of the rest of
BM> that line (up to a fixed limit) as one argument, and on some OSs that
BM> limit was rather small. Perl goes to some trouble to sort out the
BM> resulting mess so you can apparently put several arguments on the #!
BM> line and it will Just Work.
perl gets the #! just by reading the source file it is passed. it
doesn't need any help from the kernel to see it all.
uri
------------------------------
Date: Sun, 22 Apr 2012 17:31:11 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Perl on a Mac
Message-Id: <jn1f8u$pm2$2@reader1.panix.com>
In article <bnp7p7hojt1efhvrdihu823e83rdb79i0b@4ax.com>,
J_rgen Exner <jurgenex@hotmail.com> wrote:
>Torsten J_rgensen <info@stconinc.com> wrote:
>>Except that it comes out with -bash: seek.pl: command not found
>>when I try to run this:
>>
>>#!/usr/bin/perl
>>print "Hello World";
>
>Then I would guess there is no executable program named perl at
>/usr/bin. Maybe it is not installed? Maybe it is in a different
>location? Maybe access rights are incorrect?
"type perl" or "which perl" may say where it is. For example, on my
ISP,
$ type -a perl
perl is /usr/local/bin/perl
But other systems may differ.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 22 Apr 2012 17:38:08 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Perl on a Mac
Message-Id: <jn1fm0$pm2$3@reader1.panix.com>
In article <2o4d69-ik4.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth tmcd@panix.com:
>> In article <6sv6p7p0pcajnlc9accg7kp2kspn3a0ae0@4ax.com>,
>> J_rgen Exner <jurgenex@hotmail.com> wrote:
>> >Torsten J_rgensen <info@stconinc.com> wrote:
>> >>Does it understand #!/usr/bin/perl.
>> >
>> >No, it doesn't. It doesn't on any OS because the shebang line is a
>> >function of the shell, not of Perl.
>>
>> That happens not to be the case. In UNIX and UNIX derivatives,
>
>The kernel implementation of #! is a BSD thing, though I believe it
>made its way into all the SysVs eventually.
Regardless of the history, I have not heard of any extant current UNIX
derivative that doesn't have it. Linux certainly does.
And to quibble: technically no, but effectively yes.
http://www.in-ulm.de/~mascheck/various/shebang/
The #! magic, details about the shebang/hash-bang mechanism on
various Unix flavours
2011-12-27
has a history that says it was done at Bell Labs after Version 7,
announced by Dennis Richie, but BSD 4 (not BSD 2) was the first wide
distribution to pick it up. "Among the public releases from Bell
Labs, #! was not added until SVR4 ('88) according to a TUHS list
discussion. System III and SVR1 definitely had not implemented it,
yet."
It links to http://homepages.cwi.nl/~aeb/std/hashexclam.html
#! - the Unix truth as far as I know it.
Andries Brouwer, aeb@cwi.nl
v1.2, 2002-12-05
, which gives more details about changes and implementations.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 22 Apr 2012 17:49:45 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Perl on a Mac
Message-Id: <jn1gbp$ffb$1@reader1.panix.com>
In article <6h4d69-ik4.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>Even on OSs which understand #!, the kernel always passes the whole
>of the rest of that line (up to a fixed limit) as one argument
http://homepages.cwi.nl/~aeb/std/hashexclam-1.html#ss1.3 says that
there's lots of variations on that, though I find it confusing because
he uses the present tense to refer to long-obsolete UNIX variations.
- Most systems do that.
Some split on whitespace and pass multiple arguments.
Some split on whitespace and ignore all but the first.
One line of development treated # as a comment character, but later
yanked it out.
- Systems have various limits, but "BSD/OS 4.2 does not truncate".
- Some delete trailing whitespace, some do not.
- Some systems (Linux) keep trailing \r as part of the argument.
Others (Solaris) strip it too.
- Systems differ on what arg0 that they will pass.
- Some systems do not allow a script to be on the #! line.
In short, to go by that, you can portably depend on 0 or 1 argument
if there's no whitespace in it or after it, no \r, and less than 80
bytes on modern systems.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 22 Apr 2012 16:23:43 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Why does this code works without cat ?
Message-Id: <slrnjp853f.6h8.hjp-usenet2@hrunkner.hjp.at>
On 2012-04-21 09:59, Eric Pozharski <whynot@pozharski.name> wrote:
> with <86lilpd7k6.fsf@red.stonehenge.com> Randal L. Schwartz wrote:
>> You're confusing what -s can return on a pipe vs a file. Very different.
>
> Huh? "blame me, I've got used to be guilty of anything" (c) me.
>
> p.s.
>
> {2809:5} [0:0]% perl -wle 'print -s STDIN' </etc/passwd </etc/group
> 0
>
> And who's confused now?
Ok, you just proved me wrong: You *are* confused.
I admit that this particular zsh feature (it doesn't work in bash) is a
bit confusing:
When you use one input redirection, zsh (like any other shell) opens the
file, forks a child process, dups the filedescriptor to fd 0, and
finally execs the program.
But when you use two or more redirections, zsh opens all the files,
creates a pipe and forks two child processes: The first one concatenates
the files and sends them to the pipe, the second one dups the pipe's
file descriptor to 0 and execs the program.
So i zsh, writing
perl -wle 'print -s STDIN' </etc/passwd </etc/group
is almost equivalent to writing
cat /etc/passwd /etc/group | perl -wle 'print -s STDIN'
The only difference is that zsh doesn't actually call an external
executable named cat but performs the concatentation internally. Of
course that doesn't make any difference to perl.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
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 3672
***************************************
