[32404] in Perl-Users-Digest
Perl-Users Digest, Issue: 3671 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Apr 22 06:09:30 2012
Date: Sun, 22 Apr 2012 03:09:10 -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: 3671
Today's topics:
Re: Optionally avoid AutoLoader <ben@morrow.me.uk>
Re: Optionally avoid AutoLoader <marc.girod@gmail.com>
Re: Optionally avoid AutoLoader <marc.girod@gmail.com>
Re: Optionally avoid AutoLoader <marc.girod@gmail.com>
Re: Optionally avoid AutoLoader <ben@morrow.me.uk>
Re: Optionally avoid AutoLoader <marc.girod@gmail.com>
Perl on a Mac - again <hacker@ace158.com>
Re: Perl on a Mac - again <hacker@ace158.com>
Re: Perl on a Mac - again <rvtol+usenet@xs4all.nl>
Re: Perl on a Mac - again <m@rtij.nl.invlalid>
Re: Perl on a Mac - again <peter@makholm.net>
Re: Perl on a Mac - again <hacker@ace158.com>
Re: Perl on a Mac - again <hacker@ace158.com>
Re: Perl on a Mac - again <hacker@ace158.com>
Re: Perl on a Mac - again <rvtol+usenet@xs4all.nl>
Re: Perl on a Mac - again (Tim McDaniel)
Perl on a Mac <info@stconinc.com>
Re: Perl on a Mac <jurgenex@hotmail.com>
Re: Perl on a Mac <info@stconinc.com>
Re: Perl on a Mac <info@stconinc.com>
Re: Perl on a Mac (Tim McDaniel)
Re: Perl on a Mac <rvtol+usenet@xs4all.nl>
Re: Why does this code works without cat ? <hjp-usenet2@hjp.at>
Re: Why does this code works without cat ? <whynot@pozharski.name>
Re: Why does this code works without cat ? <xhoster@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 21 Apr 2012 14:30:11 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <3cpa69-ion2.ln1@anubis.morrow.me.uk>
Quoth Marc Girod <marc.girod@gmail.com>:
>
> My idea for the 'wrapdebug' driver would be to define there an
> AUTOLOAD routine, and to inject its name into the space of
> ClearCase::Wrapper (preempting AutoLoader::AUTOLOAD, which is 'used'
> explicitely, in the standard way).
What does this new AUTOLOAD do? Can you not just call
AutoLoader::AUTOLOAD when you want to define the actual sub?
> The problem I hit right away is that then, I'd need to access code
> beyond the __END__ tag in the modules...
Well, AutoSplit has handily split that code up into *.al files for you,
which can simply be required as you need them. You could also open the
file in $INC{"ClearCase/Wrapper.pm"} and search for __END__ yourself,
then string-eval the rest of the file. Unfortnately once perl sees
__END__ in a .pm file, it closes the filehandle, so you can't avoid
opening a new file.
(If you look in %INC, be aware that coderef hooks in @INC produce paths
like "/loader/0xdeadbeef/...", which obviously aren't valid filenames.)
Ben
------------------------------
Date: Sat, 21 Apr 2012 09:07:18 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <08ce94b4-b841-4a03-93d4-ef67c2debc89@r9g2000yqd.googlegroups.com>
On Apr 21, 2:30=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> What does this new AUTOLOAD do? Can you not just call
> AutoLoader::AUTOLOAD when you want to define the actual sub?
It would (I didn't write it yet: decided to check first...) do what
you described below: ignore the *.al files, and load instead the pm
files (not only ClearCase/Wrapper.pm, but also ClearCase/Wrapper/
MGi.pm), by-passing the __END__ tags.
It has to compute the paths itself (doesn't it?) because it will be
called before the $INC hash has been updated...
> Well, AutoSplit has handily split that code up into *.al files for you,
> which can simply be required as you need them. You could also open the
> file in $INC{"ClearCase/Wrapper.pm"} and search for __END__ yourself,
> then string-eval the rest of the file. Unfortnately once perl sees
> __END__ in a .pm file, it closes the filehandle, so you can't avoid
> opening a new file.
There are (at least) two problems with the autoload mechanism in
development mode:
- use strict and use warnings are ignored
- debugging is hard: one must navigate through the code to the
invocations, and step through the autoloader code: it is impossible to
put breakpoints because the code is first not loaded, and then not
loaded into the same (file) space (line numbers are corrected to match
the original source, but only valid in the *.al files).
Will string-eval produce strict/warning reports?
> (If you look in %INC, be aware that coderef hooks in @INC produce paths
> like "/loader/0xdeadbeef/...", which obviously aren't valid filenames.)
I guess I have to try before I understand this...
Thanks,
Marc
------------------------------
Date: Sat, 21 Apr 2012 10:35:13 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <9553f52e-7cd2-407a-b7b1-9ddbb5ca1902@h20g2000yqd.googlegroups.com>
On Apr 21, 2:30=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Well, AutoSplit has handily split that code up into *.al files for you,
> which can simply be required as you need them.
Actually, I first explored this idea, and it seems to works...
I.e. I looked at all the registered packages, and required all the
*.al files.
This relies on the fact that the installation directory is clean from
removed functions.
my (%pkg, %seen); #seen functions were overridden: skip the next
occurrences
$pkg{$_}++ for values %ClearCase::Wrapper::ExtMap;
for (reverse sort keys %pkg) {
s%::%/%g;
my $as =3D catfile($_, 'autosplit.ix');
my ($fas) =3D grep /\Q$as\E$/, keys %INC;
die "Could not find $as in \%INC" unless $fas;
my $dir =3D dirname($fas);
opendir DIR, $dir or die "Could not open $dir";
for (grep /\.al$/, readdir DIR) {
next if $seen{$_}++;
my $f =3D catfile($dir, $_);
require $f;
}
closedir DIR;
}
I'll have to practice a bit to see if it buys me the expected
advantages...
Looking at the breakpoint:
main::(./wrapdebug:125): my $status;
DB<1> b 2882
Line 2882 not breakable.
DB<2> c 142
main::(./wrapdebug:142): if (scalar @ARGV =3D=3D 1 && $ARGV[0] eq '-
status') {
DB<3> b 2882
Line 2882 not breakable.
DB<4> x grep m%ClearCase/Wrapper/MGi/describe.al$%, keys %INC
0 '/home/emagiro/perl/lib/auto/ClearCase/Wrapper/MGi/describe.al'
DB<5> f describe.al
Choosing /home/emagiro/perl/lib/auto/ClearCase/Wrapper/MGi/describe.al
matching `describe.al':
1 # NOTE: Derived from blib/lib/ClearCase/Wrapper/MGi.pm.
2 # Changes made here will be lost when autosplit is run again.
3 # See AutoSplit.pm.
4 package ClearCase::Wrapper::MGi;
5
6 #line 2871 "blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into blib/
lib/auto/ClearCase/Wrapper/MGi/describe.al)"
DB<6> b 2882
Line 2882 not breakable.
DB<7> v 2880
Argh... Now, the line numbers are *not* autocorrected...
Maybe only a minor nuisance...
Thanks,
Marc
------------------------------
Date: Sat, 21 Apr 2012 10:40:58 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <bfc2b352-1045-4a6b-aec7-8532f1406959@e42g2000yqa.googlegroups.com>
On Apr 21, 6:35=A0pm, Marc Girod <marc.gi...@gmail.com> wrote:
> Maybe only a minor nuisance...
Unfortunately not...
The debugger really doesn't see beyond:
DB<10> v
3 # See AutoSplit.pm.
4 package ClearCase::Wrapper::MGi;
5
6 #line 2871 "blib/lib/ClearCase/Wrapper/MGi.pm (autosplit into blib/
lib/auto/ClearCase/Wrapper/MGi/describe.al)"
DB<10> b 18
Line 18 not breakable.
Marc
------------------------------
Date: Sun, 22 Apr 2012 01:49:32 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <s51c69-8gt2.ln1@anubis.morrow.me.uk>
Quoth Marc Girod <marc.girod@gmail.com>:
> On Apr 21, 2:30 pm, Ben Morrow <b...@morrow.me.uk> wrote:
>
> > What does this new AUTOLOAD do? Can you not just call
> > AutoLoader::AUTOLOAD when you want to define the actual sub?
>
> It would (I didn't write it yet: decided to check first...) do what
> you described below: ignore the *.al files, and load instead the pm
> files (not only ClearCase/Wrapper.pm, but also ClearCase/Wrapper/
> MGi.pm), by-passing the __END__ tags.
>
> It has to compute the paths itself (doesn't it?) because it will be
> called before the $INC hash has been updated...
The %INC hash is updated before the required file starts compiling. I'm
not clear exactly when you will be defining this alternative AUTOLOAD:
in fact, it sounds like you don't want to redefine AUTOLOAD at all, you
just want to preload all the autoloadable subs. If the subs are defined
AUTOLOAD won't get called at all.
> > Well, AutoSplit has handily split that code up into *.al files for you,
> > which can simply be required as you need them. You could also open the
> > file in $INC{"ClearCase/Wrapper.pm"} and search for __END__ yourself,
> > then string-eval the rest of the file. Unfortnately once perl sees
> > __END__ in a .pm file, it closes the filehandle, so you can't avoid
> > opening a new file.
>
> There are (at least) two problems with the autoload mechanism in
> development mode:
> - use strict and use warnings are ignored
> - debugging is hard: one must navigate through the code to the
> invocations, and step through the autoloader code: it is impossible to
> put breakpoints because the code is first not loaded, and then not
> loaded into the same (file) space (line numbers are corrected to match
> the original source, but only valid in the *.al files).
>
> Will string-eval produce strict/warning reports?
String eval is considered to be within the lexical scope of the code
that calls it, so it will inherit pragma settings from the outside. You
want to be careful about this: if your eval is in the scope of, say,
'feature', that will be applied to the evaled code. It will also see any
lexicals which are visible outside the eval, which may make for some
rather strange bugs if you pick one up accidentally.
It might be worth using a trick I've used in the past, and using the
coderef-in-@INC hook to let you load the code with require rather than
eval. Required code gets a fresh lexical scope, so there is less chance
for things to go wrong: if you want an example of how to do this, I've
probably got one lying around somewhere. You will also probably want to
use #line to make the line numbers and filenames come out right: see the
very end of perlsyn.
> > (If you look in %INC, be aware that coderef hooks in @INC produce paths
> > like "/loader/0xdeadbeef/...", which obviously aren't valid filenames.)
>
> I guess I have to try before I understand this...
(I was incorrect about what appears in %INC: the value in %INC is the
actual coderef or object that was in @INC. The "/loader/0x..." name is
what will appear in stack traces and the like, unless it was overridden
with a #line directive.)
There's nothing really to understand: under some (slightly obscure)
circumstances, you will find values in %INC which aren't valid filenames
(in fact, which aren't strings at all). You just need to make sure your
code doesn't do anything stupid in that case; if you really wanted to
you could call the coderef or invoke the object's ->INC method to reread
the file, but it probably isn't worth it. See perldoc -f require for all
the details.
This only usually applies when, say, a program has been packed with PAR,
or something else is being clever about fetching module files from
somewhere unusual, so it shouldn't be a major problem in practice.
Ben
------------------------------
Date: Sun, 22 Apr 2012 00:57:54 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Optionally avoid AutoLoader
Message-Id: <31d9df0e-50ab-4cf0-9e7b-562b4e1d0552@r13g2000vbg.googlegroups.com>
Hi,
I acknowledge your reply to a previous message of mine.
On Apr 21, 6:40=A0pm, 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...
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...
It is indeed autosplit, not autoload which I ought to by-pass (or to
alter)!
Marc
------------------------------
Date: Sun, 22 Apr 2012 08:11:26 +0200
From: Hacker <hacker@ace158.com>
Subject: Perl on a Mac - again
Message-Id: <2012042208112666557-hacker@ace158com>
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.
--
Nobody dies in WarZone!
------------------------------
Date: Sun, 22 Apr 2012 10:03:26 +0200
From: Hacker <hacker@ace158.com>
Subject: Re: Perl on a Mac - again
Message-Id: <2012042210032643459-hacker@ace158com>
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.
--
Nobody dies in WarZone!
------------------------------
Date: Sun, 22 Apr 2012 10:07:39 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Perl on a Mac - again
Message-Id: <4f93bc49$0$6858$e4fe514c@news2.news.xs4all.nl>
On 2012-04-22 08:11, Hacker wrote:
> I have a little Perl program here:
>
> #!usr//bin/perl
You mixed up some separators there.
> 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.
Show us what 'ls -a test' reports. Is it executable?
Try also to run it as './test'.
--
Ruud
ch: Lazy Sunday Afternoon
------------------------------
Date: Sun, 22 Apr 2012 10:09:41 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Perl on a Mac - again
Message-Id: <5vqc69-paj.ln1@news.rtij.nl>
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
------------------------------
Date: Sun, 22 Apr 2012 10:21:32 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: Perl on a Mac - again
Message-Id: <8762csjhwz.fsf@vps1.hacking.dk>
Hacker <hacker@ace158.com> writes:
> 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.
You current working directory is not in $PATH and you end up with
calling /bin/test.
//Makholm
------------------------------
Date: Sun, 22 Apr 2012 10:42:23 +0200
From: Hacker <hacker@ace158.com>
Subject: Re: Perl on a Mac - again
Message-Id: <2012042210422324563-hacker@ace158com>
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 :-(
--
This time machine is really funky...
------------------------------
Date: Sun, 22 Apr 2012 10:44:38 +0200
From: Hacker <hacker@ace158.com>
Subject: Re: Perl on a Mac - again
Message-Id: <2012042210443896722-hacker@ace158com>
On 2012-04-22 08:07:39 +0000, Dr.Ruud said:
> On 2012-04-22 08:11, Hacker wrote:
>> I have a little Perl program here:
>>
>> #!usr//bin/perl
>
> You mixed up some separators there.
>
>
>> 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.
>
> Show us what 'ls -a test' reports. Is it executable?
> Try also to run it as './test'.
./test works! Why is ./ (this directory this) a cool thing? Thanks.
--
This time machine is really funky...
------------------------------
Date: Sun, 22 Apr 2012 10:47:24 +0200
From: Hacker <hacker@ace158.com>
Subject: Re: Perl on a Mac - again
Message-Id: <2012042210472448196-hacker@ace158com>
On 2012-04-22 08:21:32 +0000, Peter Makholm said:
> Hacker <hacker@ace158.com> writes:
>
>> 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.
>
> You current working directory is not in $PATH and you end up with
> calling /bin/test.
>
> //Makholm
Ok, cool - all these little things.
Would a ~/.bashrc something with path help.
I can not remember how you append $PATH, yuk.
--
Get your widget out of my way.
------------------------------
Date: Sun, 22 Apr 2012 10:52:17 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Perl on a Mac - again
Message-Id: <4f93c6c1$0$6974$e4fe514c@news2.news.xs4all.nl>
On 2012-04-22 10:44, Hacker wrote:
> ./test works! Why is ./ (this directory this) a cool thing? Thanks.
So it is not a Perl issue. Best ask in some sh group.
--
Ruud
------------------------------
Date: Sun, 22 Apr 2012 09:01:12 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Perl on a Mac - again
Message-Id: <jn0hco$6h$1@reader1.panix.com>
In article <8762csjhwz.fsf@vps1.hacking.dk>,
Peter Makholm <peter@makholm.net> wrote:
>Hacker <hacker@ace158.com> writes:
>
>> 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.
>
>You current working directory is not in $PATH and you end up with
>calling /bin/test.
"test" is a builtin command in bash and probably in other shells.
It doesn't matter what PATH is set to: it always checks for builtins
before checking anything in PATH.
In bash, you can run
type test
and it will tell you what it will run for that command.
In this case, the output is
test is a shell builtin
You could run your program as "./test", if it has the execute bit set,
but if you ever forgot, it would silently run the shell builtin
again. Bastically, naming a test program "test' is a classic UNIX
error.
If you want to run it as a command, then
- rename the file. Do not rename it to one of the reserved builtin
commands or such. No builtin has "." in the middle fo text, so
that's always safe, like "test.pl".
Suppose below you rename it test1
- make sure it has the execute bit set, via
chmod u+x test1
- run it via
./test1
You may already have "." as an item in $PATH, in which case you can
run it as "test1", but if you are explicit about the path to the
file, like "./test1", then there's no question about confusing it
with a builtin.
Builtin commands and such:
.
source
alias
bg
bind
break
builtin
caller
cd
command
compgen
complete
compopt
continue
declare
typeset
dirs
disown
echo
enable
eval
exec
exit
export
fc
fg
getopts
hash
help
history
jobs
kill
let
local
logout
mapfile
popd
printf
pushd
pwd
read
readonly
return
set
shift
shopt
suspend
test
[
times
trap
type
ulimit
umask
unalias
unset
wait
!
case
do
done
elif
else
esac
fi
for
function
if
in
select
then
until
while
{
}
time
[[
]]
(
((
coproc
------------------------------
Date: Sun, 22 Apr 2012 05:36:55 +0200
From: =?iso-8859-1?Q?Torsten_J=F8rgensen?= <info@stconinc.com>
Subject: Perl on a Mac
Message-Id: <2012042205365514329-info@stconinccom>
Does it understand #!/usr/bin/perl.
Can the Terminal run shell scripts.
--
Sterling Consulting Incorporated
Torsten Jorgensen
Hedevangen 16, Rebild
9520 Skorping
Denmark
info@stconinc.com
www.stconinc.com
------------------------------
Date: Sat, 21 Apr 2012 20:51:59 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl on a Mac
Message-Id: <6sv6p7p0pcajnlc9accg7kp2kspn3a0ae0@4ax.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(*).
>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.
jue
------------------------------
Date: Sun, 22 Apr 2012 06:08:18 +0200
From: =?iso-8859-1?Q?Torsten_J=F8rgensen?= <info@stconinc.com>
Subject: Re: Perl on a Mac
Message-Id: <2012042206081825994-info@stconinccom>
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:
#!/usr/bin/perl
print "Hello World";
>
> *: 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...
> jue
And by the way, keep your inuendo to yourself, it is insulting.
--
Sterling Consulting Incorporated
Torsten Jorgensen
Hedevangen 16, Rebild
9520 Skorping
Denmark
info@stconinc.com
www.stconinc.com
------------------------------
Date: Sun, 22 Apr 2012 07:07:24 +0200
From: =?iso-8859-1?Q?Torsten_J=F8rgensen?= <info@stconinc.com>
Subject: Re: Perl on a Mac
Message-Id: <2012042207072441151-info@stconinccom>
On 2012-04-22 04:08:18 +0000, Torsten Jørgensen said:
> 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:
>
> #!/usr/bin/perl
> print "Hello World";
>
>>
>> *: 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...
>
>> jue
>
> And by the way, keep your inuendo to yourself, it is insulting.
Just this one little thing.
A lot of the comotion here on USENET seems to be about people who wants
to vent:
"I am smarter than you. You are a dork."
Whatever happened to nice people.
--
Sterling Consulting Incorporated
Torsten Jorgensen
Hedevangen 16, Rebild
9520 Skorping
Denmark
info@stconinc.com
www.stconinc.com
------------------------------
Date: Sun, 22 Apr 2012 06:08:23 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Perl on a Mac
Message-Id: <jn078n$luk$1@reader1.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
system detects when the first two characters of the file are "#!".
"man 2 execve" on Ubuntu (one version back), where "2" means it's a
system call:
execve() executes the program pointed to by filename. filename
must be either a binary executable, or a script starting with a
line of the form:
#! interpreter [optional-arg]
For details of the latter case, see "Interpreter scripts" below.
<http://kernel.org/doc/man-pages/online/pages/man2/execve.2.html> has
a Linux man page, including implementations details and how different
systems differ in their implementations of it.
Below is an example program showing a binary (100, compiled from
100.c) executing a script (100.cat) without any shell being involved.
In the 1980s, if you were using csh and a file began with "#" (not
"#!), then csh would interpret it as a csh script instead of calling
the kernel. That is no longer the case on current Linux or NetBSD
5.1.2, the two systems I can check conveniently. There, the correct
interpreter (/bin/cat, if I re-use the example script below) gets
called, though I can't easily test to see whether csh caused it or the
kernel.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ cat 100.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
char *newargv[] = { "100.cat", (char *) NULL };
char *newenviron[] = { (char *) NULL };
execve("100.cat", newargv, newenviron);
perror("execve"); /* execve() only returns on error */
exit(EXIT_FAILURE);
}
$ cat 100.cat
#! /bin/cat
Hello, world!
$ cc -o 100 100.c
$ chmod u+x 100.cat
$ ./100
#! /bin/cat
Hello, world!
------------------------------
Date: Sun, 22 Apr 2012 10:34:51 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Perl on a Mac
Message-Id: <4f93c2ac$0$6971$e4fe514c@news2.news.xs4all.nl>
On 2012-04-22 06:08, Torsten Jørgensen wrote:
> And by the way, keep your inuendo to yourself, it is insulting.
A big lesson that many usenet users still need to learn, again and
again, is that you are what you read.
If you feel that something you read, annoys you, then realize that you
were already annoyed before you started reading it.
In am not interested in people that show behavior like Torsten just did,
with the exception of close family. For usenet that is easy to express,
I just create a filter and he's being plonked. I don't actually have a
plonk sound for every plonk that my filters do, I prefer the silence.
--
Ruud
------------------------------
Date: Sat, 21 Apr 2012 19:16:28 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Why does this code works without cat ?
Message-Id: <slrnjp5qrd.d5c.hjp-usenet2@hrunkner.hjp.at>
On 2012-04-21 04:37, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Eric" == Eric Pozharski <whynot@pozharski.name> writes:
>
>Eric> However, redirection comes with little bonuses:
>
>Eric> {23:1} [0:0]% perl -wle 'print -s STDIN' </etc/passwd
>Eric> 1814
>Eric> {2048:2} [0:0]% cat /etc/passwd | perl -wle 'print -s STDIN'
>Eric> 0
>
> You're confusing what -s can return on a pipe vs a file. Very different.
I don't think that Eric is confusing anything. He is pointing out that
in the first example STDIN is a file handle to the file /etc/passwd So
you can determine its size, you can seek around in it, determin its
owner and permissions, etc.
Whereas in the second example STDIN is a file handle to a pipe. All you
can do with a pipe is read it sequentially.
They are, as you say, very different. Which is exactly what Eric was
showing, so I don't understand why you think he was confusing something.
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: Sat, 21 Apr 2012 12:59:44 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Why does this code works without cat ?
Message-Id: <slrnjp518g.29b.whynot@orphan.zombinet>
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?
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Sat, 21 Apr 2012 14:50:58 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Why does this code works without cat ?
Message-Id: <4f932e1b$0$7569$ed362ca5@nr5-q3a.newsreader.com>
On 04/20/2012 09:37 PM, Randal L. Schwartz wrote:
>>>>>> "Eric" == Eric Pozharski<whynot@pozharski.name> writes:
>
> Eric> However, redirection comes with little bonuses:
>
> Eric> {23:1} [0:0]% perl -wle 'print -s STDIN'</etc/passwd
> Eric> 1814
> Eric> {2048:2} [0:0]% cat /etc/passwd | perl -wle 'print -s STDIN'
> Eric> 0
>
> You're confusing what -s can return on a pipe vs a file. Very different.
I'm pretty sure that that was his point.
Xho
------------------------------
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 3671
***************************************
