[31537] in Perl-Users-Digest
Perl-Users Digest, Issue: 2796 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jan 29 14:09:31 2010
Date: Fri, 29 Jan 2010 11:09:16 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 29 Jan 2010 Volume: 11 Number: 2796
Today's topics:
Re: [OT] Re: Inconsistent results from (dos)glob <ben@morrow.me.uk>
Re: [OT] Re: Inconsistent results from (dos)glob <hjp-usenet2@hjp.at>
Re: [OT] Re: Inconsistent results from (dos)glob <nospam-abuse@ilyaz.org>
Re: [OT] Re: Inconsistent results from (dos)glob <nospam-abuse@ilyaz.org>
Re: [OT] Re: Inconsistent results from (dos)glob <ben@morrow.me.uk>
Re: complicated mapping sln@netherlands.com
Re: FAQ 4.44 How do I test whether two arrays or hashes <nospam-abuse@ilyaz.org>
Re: FAQ 4.44 How do I test whether two arrays or hashes <paduille.4061.mumia.w+nospam@earthlink.net>
Re: Inconsistent results from (dos)glob <hjp-usenet2@hjp.at>
Re: Inconsistent results from (dos)glob <jurgenex@hotmail.com>
Re: Inconsistent results from (dos)glob <hjp-usenet2@hjp.at>
Re: Inconsistent results from (dos)glob <jurgenex@hotmail.com>
Re: Net::SMTP vs MX (hymie!)
Re: permalink to latest devel release of perl? <no.email@please.post>
Re: permalink to latest devel release of perl? <ben@morrow.me.uk>
Re: should C<++$_ for -1..1> croak? <hjp-usenet2@hjp.at>
Re: should C<++$_ for -1..1> croak? <jurgenex@hotmail.com>
Re: should C<++$_ for -1..1> croak? <nospam-abuse@ilyaz.org>
Re: should C<++$_ for -1..1> croak? <hjp-usenet2@hjp.at>
Re: should C<++$_ for -1..1> croak? <smallpond@juno.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 29 Jan 2010 13:03:48 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [OT] Re: Inconsistent results from (dos)glob
Message-Id: <ku2b37-k5f1.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2010-01-29 00:53, sreservoir <sreservoir@gmail.com> wrote:
>
> > however, if you use one of those filesystems that let you have nulls
> > in filenames, some of the standard utilities might segfault or
> > overflow.
>
> That's impossible. All the syscalls dealing with filenames treat "\0" as
> a terminator. There is no way to create or access a file with a null in
> its name[1].
All modern Win32 filesystems (FAT32, NTFS) represent filenames
internally as UCS-2 or UTF-16, which often contain nulls. The current
official API (CreateFileW &c.) and the MS-specific stdc-like wrappers
(_wopen, _wfopen, &c.) all take 16-bit-null-delimited 16-bit strings.
The 8-bit 'ANSI' API translates filenames to and from some 8-bit or
multibyte encoding, specified as the current process 'code page'. Since
processes are not normally using a UTF-8 code page, this means some
names are untranslatable.
This is all a serious, and seriously annoying, issue for perl on Win32.
Ben
------------------------------
Date: Fri, 29 Jan 2010 17:07:19 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: [OT] Re: Inconsistent results from (dos)glob
Message-Id: <slrnhm61tq.194.hjp-usenet2@hrunkner.hjp.at>
On 2010-01-29 13:03, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>> On 2010-01-29 00:53, sreservoir <sreservoir@gmail.com> wrote:
>> > however, if you use one of those filesystems that let you have nulls
>> > in filenames, some of the standard utilities might segfault or
>> > overflow.
>>
>> That's impossible. All the syscalls dealing with filenames treat "\0" as
>> a terminator. There is no way to create or access a file with a null in
>> its name[1].
>
> All modern Win32 filesystems (FAT32, NTFS) represent filenames
> internally as UCS-2 or UTF-16, which often contain nulls.
The context (at least of the last two postings before I replied) was
Unix, not Windows. On a POSIX compatible OS, the filesystem may use
UTF-16 to actually store filenames on disk, but it needs to translate
them in the API, because the string representation in the API
(zero-terminated byte strings) doesn't allow UTF-16.
UTF-8 is the most logical choice here.
> The current official API (CreateFileW &c.) and the MS-specific
> stdc-like wrappers (_wopen, _wfopen, &c.) all take
> 16-bit-null-delimited 16-bit strings.
Yes. But note that the API here is not byte-oriented but operates on
16-bit quantities. So the strings are still zero-terminated, and you
don't have a null *character* in the file name.
> The 8-bit 'ANSI' API translates filenames to and from some 8-bit or
> multibyte encoding, specified as the current process 'code page'. Since
> processes are not normally using a UTF-8 code page, this means some
> names are untranslatable.
>
> This is all a serious, and seriously annoying, issue for perl on Win32.
On Win32, the Right Thing(TM) would probably be to always use the UTF-16
API and translate from/to Perl character strings. That would be an
incompatibility with Unix perl where filenames are byte strings, but
every alternative seems worse to me.
hp
------------------------------
Date: Fri, 29 Jan 2010 17:17:41 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: [OT] Re: Inconsistent results from (dos)glob
Message-Id: <slrnhm661l.d1k.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-01-29, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> That's impossible. All the syscalls dealing with filenames treat "\0" as
> a terminator. There is no way to create or access a file with a null in
> its name[1].
It is not a problem to create or access a file with a null in its name
on Unix. (Remember read()/write() syscalls?)
Hope this helps,
Ilya
------------------------------
Date: Fri, 29 Jan 2010 17:21:30 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: [OT] Re: Inconsistent results from (dos)glob
Message-Id: <slrnhm668q.d1k.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-01-29, Ben Morrow <ben@morrow.me.uk> wrote:
> All modern Win32 filesystems (FAT32, NTFS) represent filenames
> internally as UCS-2 or UTF-16, which often contain nulls.
The internal representation of a directory entry on a raw file system
should not matter when accessing files through the OS'es API.
> The current
> official API (CreateFileW &c.) and the MS-specific stdc-like wrappers
> (_wopen, _wfopen, &c.) all take 16-bit-null-delimited 16-bit strings.
So there is no problem: 0 terminates the name.
> The 8-bit 'ANSI' API translates filenames to and from some 8-bit or
> multibyte encoding, specified as the current process 'code page'.
Likewise.
> Since
> processes are not normally using a UTF-8 code page, this means some
> names are untranslatable.
AFAIK, any file name on Win32 is translatable to 8.3. But I might be wrong...
> This is all a serious, and seriously annoying, issue for perl on Win32.
Only due to bugs in the porting layer.
Yours,
Ilya
------------------------------
Date: Fri, 29 Jan 2010 17:37:06 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: [OT] Re: Inconsistent results from (dos)glob
Message-Id: <2vib37-a4g1.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2010-01-29 13:03, Ben Morrow <ben@morrow.me.uk> wrote:
>
> > The current official API (CreateFileW &c.) and the MS-specific
> > stdc-like wrappers (_wopen, _wfopen, &c.) all take
> > 16-bit-null-delimited 16-bit strings.
>
> Yes. But note that the API here is not byte-oriented but operates on
> 16-bit quantities. So the strings are still zero-terminated, and you
> don't have a null *character* in the file name.
True. That doesn't, IMHO, make it any less insane :).
> > The 8-bit 'ANSI' API translates filenames to and from some 8-bit or
> > multibyte encoding, specified as the current process 'code page'. Since
> > processes are not normally using a UTF-8 code page, this means some
> > names are untranslatable.
> >
> > This is all a serious, and seriously annoying, issue for perl on Win32.
>
> On Win32, the Right Thing(TM) would probably be to always use the UTF-16
> API and translate from/to Perl character strings. That would be an
> incompatibility with Unix perl where filenames are byte strings, but
> every alternative seems worse to me.
Yes. Jan Dubois is trying quite hard to get perl there without breaking
anything. The problem is that naive programs that read a filename from
the console (or the command-line) will then break, because the name will
be in the current 'ANSI' encoding and would need decoding into a perl
'character string' before passing to open. Since the local codepage is
generally not ISO8859-1, this is not something perl can easily do
automatically (since there are now two possible upgrade paths for an
8-bit-only string: from ISO8859-1 like the rest of perl, or from the
local codepage if this is supposed to be a filename).
Ben
------------------------------
Date: Fri, 29 Jan 2010 08:47:55 -0800
From: sln@netherlands.com
Subject: Re: complicated mapping
Message-Id: <rg36m5tb8inmklv2845jci2k1n6rf4g8s6@4ax.com>
On Thu, 28 Jan 2010 21:10:24 -0500, monkeys paw <user@example.net> wrote:
>Why does the output not contain the
>"private_files" element from the code
>below:
>
>my $obj;
>
>$idoc_out = [qw(IDOCRECORD1 IDOCRECORD2 IDOCRECORD3 IDOCRECORD4)];
^
No 'my' declaration of this variable.
>
>push(@{$obj}, # Shouldn't private_files be pushed onto $obj here???
>map {$_->{private_files} = [
^^^^
The 'IDOCRECORDx' strings can't be coeerced into a hash reference
>{reg_tags => [{heading => 'Insurance Documents', tag =>
^
Here, an anonymous hash reference is created with key 'headning', thats ok.
This needs to be done for the 'IDOCRECORDx' strings.
> 'All'}]}];
^
End of hash construction of {$_->{private_files} ..
but it does nothing because its not a hash reference.
> $_ }
^
This is the end of the map block, the only thing pushed
is the 'IDOCRECORDx' string but its not a hash reference.
>@{$idoc_out}
^^^^^^^^^^^^
This is just an array of strings.
------------
If you were to enable strict/warnings you would have caught the errors
above.
Probably you want something like below. This creates a single anonymous
hash for each IDOCRECORDx string, then pushes it into the $obj array.
-sln
-------------
use strict;
use warnings;
my $obj;
my $idoc_out = [qw(IDOCRECORD1 IDOCRECORD2 IDOCRECORD3 IDOCRECORD4)];
push ( @{$obj},
map {
{
$_ => {
private_files =>
[
{
reg_tags =>
[
{
heading => 'Insurance Documents',
tag => 'All'
}
]
}
]
}
}
} @{$idoc_out}
);
use Data::Dumper;die 'DDDEBUG' . Dumper($obj);
------------------------------
Date: Fri, 29 Jan 2010 17:31:56 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: FAQ 4.44 How do I test whether two arrays or hashes are equal?
Message-Id: <slrnhm66sc.d1k.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-01-29, Philip Potter <pgp@doc.ic.ac.uk> wrote:
> Wouldn't a more Perlish for loop be written like this?
>
> for my $i (0..$#$first) {
> return 0 if $first->[$i] ne $second->[$i];
> }
`return' would be more Perlish than `return 0' anyway...
Ilya
------------------------------
Date: Fri, 29 Jan 2010 09:40:21 -0600
From: "Mumia W." <paduille.4061.mumia.w+nospam@earthlink.net>
Subject: Re: FAQ 4.44 How do I test whether two arrays or hashes are equal?
Message-Id: <NNmdnYCZNqf1s_7WnZ2dnUVZ_jqdnZ2d@earthlink.com>
On 01/29/2010 03:24 AM, Philip Potter wrote:
>
> Wouldn't a more Perlish for loop be written like this?
>
> for my $i (0..$#$first) {
> return 0 if $first->[$i] ne $second->[$i];
> }
>
> Given how often newbies are told to program in Perl style rather than C
> style, shouldn't the FAQ set an example?
>
> Phil
No. The FAQ should be easy to understand. Let newbies have fun finding
the "Perlish" solutions themselves. :-)
------------------------------
Date: Fri, 29 Jan 2010 17:33:22 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Inconsistent results from (dos)glob
Message-Id: <slrnhm63ej.194.hjp-usenet2@hrunkner.hjp.at>
On 2010-01-29 03:21, Jürgen Exner <jurgenex@hotmail.com> wrote:
> John Bokma <john@castleamber.com> wrote:
>>Theo van den Heuvel <tcmvandenheuvel@gmail.com> writes:
>>
>>> the path on the spaces. (Spaces in names IMO is one of the most
>>> unfortunate design mistakes in Windows).
>>
>>Heh, I would say it the other way around: not supporting spaces in
>>filenames/directory names is a design mistake.
>
> Are there any widely used file systems that don't support spaces in file
> names?
I don't know any filesystem which doesn't support spaces (even FAT-16
back in MS-DOS 3.x days did). The problem isn't the filesystem but the
tools and applications. If the file system didn't support spaces that
wouldn't be a big deal: The user would simply use a different character
(maybe "_" or "-"). But if the filesystem does support spaces but some
tools don't, then you have a problem: The user will create files with
spaces (because he can) and then some tools will fail. (What Microsoft
really fucked up in Win95 was that although there were some important
directories with spaces in the default installation ("Program Files",
...) some core OS tools couldn't handle them. Hilarity ensued ...)
hp
------------------------------
Date: Fri, 29 Jan 2010 09:27:48 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Inconsistent results from (dos)glob
Message-Id: <mv56m5pidlfuqbbr5mfju1en3r11ej8a33@4ax.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>On 2010-01-29 03:21, Jürgen Exner <jurgenex@hotmail.com> wrote:
>> John Bokma <john@castleamber.com> wrote:
>>>Theo van den Heuvel <tcmvandenheuvel@gmail.com> writes:
>>>
>>>> the path on the spaces. (Spaces in names IMO is one of the most
>>>> unfortunate design mistakes in Windows).
>>>
>>>Heh, I would say it the other way around: not supporting spaces in
>>>filenames/directory names is a design mistake.
>>
>> Are there any widely used file systems that don't support spaces in file
>> names?
>
>I don't know any filesystem which doesn't support spaces (even FAT-16
>back in MS-DOS 3.x days did). The problem isn't the filesystem but the
>tools and applications. If the file system didn't support spaces that
>wouldn't be a big deal: The user would simply use a different character
>(maybe "_" or "-"). But if the filesystem does support spaces but some
>tools don't, then you have a problem: The user will create files with
>spaces (because he can) and then some tools will fail.
Using the same logic we should not use any characters but ASCII. After
all the user would simply use a different character and the programs
would not fail any longer on those nasty non-ASCII characters. Would
make live a lot easier for programmers, wouldn't it?
Jürgen
J Rgen
Jrgen
Jürgen
jue
------------------------------
Date: Fri, 29 Jan 2010 19:06:02 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Inconsistent results from (dos)glob
Message-Id: <slrnhm68sc.6mv.hjp-usenet2@hrunkner.hjp.at>
On 2010-01-29 17:27, Jürgen Exner <jurgenex@hotmail.com> wrote:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>>On 2010-01-29 03:21, Jürgen Exner <jurgenex@hotmail.com> wrote:
>>> John Bokma <john@castleamber.com> wrote:
>>>>Theo van den Heuvel <tcmvandenheuvel@gmail.com> writes:
>>>>> the path on the spaces. (Spaces in names IMO is one of the most
>>>>> unfortunate design mistakes in Windows).
>>>>
>>>>Heh, I would say it the other way around: not supporting spaces in
>>>>filenames/directory names is a design mistake.
>>>
>>> Are there any widely used file systems that don't support spaces in file
>>> names?
>>
>>I don't know any filesystem which doesn't support spaces (even FAT-16
>>back in MS-DOS 3.x days did). The problem isn't the filesystem but the
>>tools and applications. If the file system didn't support spaces that
>>wouldn't be a big deal: The user would simply use a different character
>>(maybe "_" or "-"). But if the filesystem does support spaces but some
>>tools don't, then you have a problem: The user will create files with
>>spaces (because he can) and then some tools will fail.
>
> Using the same logic we should not use any characters but ASCII.
Huh? Where did I say that?
What we should do of course is to write tools and applications which do
work well with arbitrary file names. Spaces in file names have been
around since at least the 1970's and common since at least the
mid-1990's. It's time that programmers (and sysadmin's) stop pretending
they don't exist.
hp
------------------------------
Date: Fri, 29 Jan 2010 10:39:32 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Inconsistent results from (dos)glob
Message-Id: <pna6m5hc0rtqt2q5r76k9mbiu9hi3j9378@4ax.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>On 2010-01-29 17:27, Jürgen Exner <jurgenex@hotmail.com> wrote:
>> "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>>>On 2010-01-29 03:21, Jürgen Exner <jurgenex@hotmail.com> wrote:
>>>> John Bokma <john@castleamber.com> wrote:
>>>>>Theo van den Heuvel <tcmvandenheuvel@gmail.com> writes:
>>>>>> the path on the spaces. (Spaces in names IMO is one of the most
>>>>>> unfortunate design mistakes in Windows).
>>>>>
>>>>>Heh, I would say it the other way around: not supporting spaces in
>>>>>filenames/directory names is a design mistake.
>>>>
>>>> Are there any widely used file systems that don't support spaces in file
>>>> names?
>>>
>>>I don't know any filesystem which doesn't support spaces (even FAT-16
>>>back in MS-DOS 3.x days did). The problem isn't the filesystem but the
>>>tools and applications. If the file system didn't support spaces that
>>>wouldn't be a big deal: The user would simply use a different character
>>>(maybe "_" or "-"). But if the filesystem does support spaces but some
>>>tools don't, then you have a problem: The user will create files with
>>>spaces (because he can) and then some tools will fail.
>>
>> Using the same logic we should not use any characters but ASCII.
>
>Huh? Where did I say that?
>
>What we should do of course is to write tools and applications which do
>work well with arbitrary file names. Spaces in file names have been
>around since at least the 1970's and common since at least the
>mid-1990's. It's time that programmers (and sysadmin's) stop pretending
>they don't exist.
My appologies, obviously I totally misunderstood the drift of your
earlier posting. I honestly thought you were blaming the file system,
not the tools. Again, my appologies.
jue
------------------------------
Date: Fri, 29 Jan 2010 13:55:33 GMT
From: hymie@lactose.homelinux.net (hymie!)
Subject: Re: Net::SMTP vs MX
Message-Id: <pNB8n.22526$mT7.21002@newsfe05.iad>
In our last episode, the evil Dr. Lacto had captured our hero,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>, who said:
>
>
>In <F8%7n.44517$s%.972@newsfe18.iad>, on 01/27/2010
> at 05:57 PM, hymie@lactose.homelinux.net (hymie!) said:
>>yahoo.com , for example, has eight different MX hosts, any number of
>>which may or may not be working at any given time. If I understand
>>correctly, I need to pick one of the 8 MX records, hard-code it into my
>>script; and when it comes time to send e-mail, hope that this particular
>>MX host is up and running.
>
>You're supposed to pick a high priority MX and to fall back to a lower
>priority MX after connect failures. See RFC 5321.
Yes, that was the point of my question. I'm going to have to implement,
on my own, without the help of my useless hosting company or many perl
modules, the selecting and re-selecting of MX records. Net::SMTP doesn't
do it on its own; I need to sepcify the MX host. I was hoping somebody
had a suggestion as to how I might do that, other than the one I originally
posted.
But no, actually, I'm *supposed* to submit my e-mail request to a
local SMTP server on the sending side and let *it* do all of the work.
That's why it's called "sendmail", you see. I shouldn't have to
re-implement my own MTA in (as it turns out, with this useless hosting
company) module-free perl. Plus, as you noted earlier, sending my own
e-mail directly to the recipient often doesn't work, although I don't
think that's my problem in this case.
--hymie! http://lactose.homelinux.net/~hymie hymie@lactose.homelinux.net
-------------------------------------------------------------------------------
------------------------------
Date: Fri, 29 Jan 2010 15:54:57 +0000 (UTC)
From: kj <no.email@please.post>
Subject: Re: permalink to latest devel release of perl?
Message-Id: <hjv0ch$2l8$1@reader1.panix.com>
In <q8o637-qeu.ln1@osiris.mauzo.dyndns.org> Ben Morrow <ben@morrow.me.uk> writes:
>Quoth kj <no.email@please.post>:
>>
>> Is there some fixed URL that always points to the latest devel
>> release of perl?
>Do you mean devel release (that is, currently 5.11.4)? Are you aware
>that these are not terribly stable, generally only slightly more so than
>a git checkout?
>Anyway, src/devel.tar.gz on any CPAN mirror.
>> Also, is there some *fixed* string (i.e. invariant irrespective of
>> the number of the latest perl version) that one could use as the
>> argument of the get/make/test/install cpan shell commands, and that
>> would download/build/test/install the latest devel release of perl?
>I'm fairly sure installing perl using CPAN.pm is not recommended any
>more. Apart from anything else, installing a dev release like this will
>attempt to overwrite your system perl, which is a *very* bad idea.
Hi Ben. My ultimate goal here is to always have the latest devel
release of perl installed locally under my subdirectory ~/develperl.
I was hoping to set up a cron job to perform this installation at
night whenever a new release comes out. The stable URL you gave
is very helpful for this.
Thanks!
~K
------------------------------
Date: Fri, 29 Jan 2010 17:30:05 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: permalink to latest devel release of perl?
Message-Id: <thib37-a4g1.ln1@osiris.mauzo.dyndns.org>
Quoth kj <no.email@please.post>:
> In <q8o637-qeu.ln1@osiris.mauzo.dyndns.org> Ben Morrow
> <ben@morrow.me.uk> writes:
> >Quoth kj <no.email@please.post>:
> >>
> >> Is there some fixed URL that always points to the latest devel
> >> release of perl?
>
> >Do you mean devel release (that is, currently 5.11.4)? Are you aware
> >that these are not terribly stable, generally only slightly more so than
> >a git checkout?
>
> >Anyway, src/devel.tar.gz on any CPAN mirror.
>
> >> Also, is there some *fixed* string (i.e. invariant irrespective of
> >> the number of the latest perl version) that one could use as the
> >> argument of the get/make/test/install cpan shell commands, and that
> >> would download/build/test/install the latest devel release of perl?
>
> >I'm fairly sure installing perl using CPAN.pm is not recommended any
> >more. Apart from anything else, installing a dev release like this will
> >attempt to overwrite your system perl, which is a *very* bad idea.
>
> Hi Ben. My ultimate goal here is to always have the latest devel
> release of perl installed locally under my subdirectory ~/develperl.
> I was hoping to set up a cron job to perform this installation at
> night whenever a new release comes out. The stable URL you gave
> is very helpful for this.
Then I would probably recommend building from git instead. Although p5p
has recently committed to monthly blead releases, they really aren't
much more than snapshots. You can checkout the source from git with
git clone git://perl5.git.perl.org/perl.git perl
cd perl
and then do a build with
git clean -dfx
git pull
./Configure -des ...
make && make test && make install
The 'git clean' is not strictly necessary, but it's best to clean
everything out if you're going to update the source in case the
dependancies have changed in a way the Makefile doesn't understand.
Ben
------------------------------
Date: Fri, 29 Jan 2010 17:20:05 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: should C<++$_ for -1..1> croak?
Message-Id: <slrnhm62lm.194.hjp-usenet2@hrunkner.hjp.at>
On 2010-01-29 08:17, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2010-01-29, sreservoir <sreservoir@gmail.com> wrote:
>> On 1/28/2010 7:40 PM, Ilya Zakharevich wrote:
>>> "sub f{ for(1..3) {print $_++ }} f; print q(==); f"
>>
>> does your shell do no substitution?
>
> There is no hope to give command line examples which would work with
> all 3 major shell types...
This is why I avoid posting Perl code in the form
perl -e '...'
It gratuitously involves some shell which may or may not do some
interpolation of its own. The reader must then guess the type of shell
and interpolation (if any) it performs.
If you just post the Perl code:
sub f{ for(1..3) {print $_++ }} f; print q(==); f
it is clear that only the behaviour of perl needs to be considered,
and any shell is irrelevant. To test this, the reader can store it in a
one-line file or use the shell with appropriate quotes.
Besides, if you aren't constrained to one line by the deficiencies of
your shell, you can make the code a bit more readable:
sub f{
for(1..3) {
print $_++
}
}
f;
print q(==);
f
hp
------------------------------
Date: Fri, 29 Jan 2010 09:29:05 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: should C<++$_ for -1..1> croak?
Message-Id: <pl66m51ap07nk2tc720k4e2dumppjuimpl@4ax.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>On 2010-01-29 08:17, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
>> On 2010-01-29, sreservoir <sreservoir@gmail.com> wrote:
>>> On 1/28/2010 7:40 PM, Ilya Zakharevich wrote:
>>>> "sub f{ for(1..3) {print $_++ }} f; print q(==); f"
>>>
>>> does your shell do no substitution?
>>
>> There is no hope to give command line examples which would work with
>> all 3 major shell types...
>
>This is why I avoid posting Perl code in the form
>perl -e '...'
>It gratuitously involves some shell which may or may not do some
>interpolation of its own. The reader must then guess the type of shell
>and interpolation (if any) it performs.
Thank you! Finally someone with some common sense to speak up!
jue
------------------------------
Date: Fri, 29 Jan 2010 17:30:16 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: should C<++$_ for -1..1> croak?
Message-Id: <slrnhm66p8.d1k.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-01-29, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>> There is no hope to give command line examples which would work with
>> all 3 major shell types...
> This is why I avoid posting Perl code in the form
> perl -e '...'
> It gratuitously involves some shell which may or may not do some
> interpolation of its own. The reader must then guess the type of shell
> and interpolation (if any) it performs.
>
> If you just post the Perl code:
>
> sub f{ for(1..3) {print $_++ }} f; print q(==); f
>
> it is clear that only the behaviour of perl needs to be considered,
> and any shell is irrelevant.
Having code which may be immediately executed overrides all other
considerations. How would the user KNOW that this is complete
snippet? How would they know the version of Perl it runs under? How
would they know what @ARGV and command-line options are required?
Perl culture is very strongly intertwined with the command-line
culture. If somebody cannot see that ""-delimiters are used, and does
not know about shell quoting semantic variability, I do not care if I
lose this person's attention in the discussion.
> To test this, the reader can store it in a
> one-line file or use the shell with appropriate quotes.
But she, most probably, won't.
> Besides, if you aren't constrained to one line by the deficiencies of
> your shell, you can make the code a bit more readable:
>
> sub f{
> for(1..3) {
> print $_++
> }
> }
>
> f;
> print q(==);
> f
Since I (and many readers) am, this does not matter much, right?
Yours,
Ilya
------------------------------
Date: Fri, 29 Jan 2010 19:00:52 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: should C<++$_ for -1..1> croak?
Message-Id: <slrnhm68ik.6mv.hjp-usenet2@hrunkner.hjp.at>
On 2010-01-29 17:30, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> Having code which may be immediately executed overrides all other
> considerations.
No.
hp
------------------------------
Date: Fri, 29 Jan 2010 13:43:57 -0500
From: Steve C <smallpond@juno.com>
Subject: Re: should C<++$_ for -1..1> croak?
Message-Id: <hjva9r$qv$1@news.eternal-september.org>
John Bokma wrote:
> Steve C <smallpond@juno.com> writes:
>
>> Dr.Ruud wrote:
>>> Should C<++$_ for -1..1> croak?
>>>
>>> Or is it better to leave it as it is?
>>>
>>>
>>>
>>> $ perl -wle'++$_ for 1..1'
>>>
>>>
>>> $ perl -wle'++$_ for 1'
>>> Modification of a read-only value attempted at -e line 1.
>> for implicitly aliases $_ to the constant 1, which cannot be
>> incremented.
>
> Note that there are two examples and only the last one complains about a
> modification of ro value.
>
perlop says:
"In the current implementation, no temporary array is created when the
range operator is used as the expression in "foreach" loops"
I assume that to mean that in the first case $_ is being set to an lvalue
by the loop code rather than aliased to a constant in a list.
Would this throw an error in older perl versions that did build a list,
or has it always worked?
------------------------------
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 2796
***************************************
