[32502] in Perl-Users-Digest
Perl-Users Digest, Issue: 3767 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 27 09:09:23 2012
Date: Mon, 27 Aug 2012 06:09:08 -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, 27 Aug 2012 Volume: 11 Number: 3767
Today's topics:
Re: [OT] Re: still good extant newsgroups Re: Man, has <kst-u@mib.org>
Re: [OT] Re: still good extant newsgroups Re: Man, has <cal@example.invalid>
check for exact # of digits <bjlockie@lockie.ca>
Re: check for exact # of digits <klaus03@gmail.com>
Re: check for exact # of digits <josef.moellers@invalid.invalid>
Re: check for exact # of digits <ben@morrow.me.uk>
Re: check for exact # of digits <jwkrahn@example.com>
Re: check for exact # of digits <ben@morrow.me.uk>
Re: check for exact # of digits <rweikusat@mssgmbh.com>
Re: magic installation woes [OT] <cal@example.invalid>
Re: magic installation woes [OT] <rweikusat@mssgmbh.com>
Semi-random sentence generator <ignoramus11402@NOSPAM.11402.invalid>
Re: Very simple hash/regex question <ben@morrow.me.uk>
Re: Very simple hash/regex question <hjp-usenet2@hjp.at>
Re: Very simple hash/regex question (Tim McDaniel)
Re: Very simple hash/regex question <rweikusat@mssgmbh.com>
Re: Very simple hash/regex question <jwkrahn@example.com>
Re: Very simple hash/regex question <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 26 Aug 2012 14:26:07 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: [OT] Re: still good extant newsgroups Re: Man, has this newsgroup shrunk. Why? Where gone to?
Message-Id: <ln1uite45s.fsf@nuthaus.mib.org>
Cal Dershowitz <cal@example.invalid> writes:
[...]
> Would you indulge me by allowing me to ask you, Keith, the other Keith,
> my good old friend, how do people mix C and Perl with installations?
That's a decent question for this newsgroup; addressing it to me
personally isn't particularly useful, partly because I don't have a
good answer. You might want to post a new question with a clearer
subject (people who can answer might be ignoring this thread).
I'm also not 100% sure what you're asking. Clarifying what "with
installations" adds to the question would be helpful.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Sun, 26 Aug 2012 02:05:53 -0600
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: [OT] Re: still good extant newsgroups Re: Man, has this newsgroup shrunk. Why? Where gone to?
Message-Id: <XdKdnTDS2IZDRaTNnZ2dnUVZ_rCdnZ2d@supernews.com>
On 08/20/2012 04:06 AM, Keith Thompson wrote:
> Cal Dershowitz <cal@example.invalid> writes:
> [...]
>> Curious how circumstances find me asking you a question again.
>>
>> It's been a lot of ticks on the real world clock since I did a lot with
>> usenet, so I wonder, where are the good groups leftover? I think the
>> pride of the pack is comp.lang.fortran , but that might just be another
>> extension to you.
>>
>> My question is whether there's still that good windows group with a dash
>> in it? lots of syllables.
>
> (I would have replied by e-mail, since this isn't particularly
> Perl-related, but you didn't provide a valid address. I'll be
> brief.)
>
> comp.lang.c and comp.std.c are far from dead, though the former is
> still somewhat infested with trolls. comp.unix.programmer is also
> doing reasonably well. I think the Windows group you're referring
> to is comp.os.ms-windows.programmer.win32; I haven't visited lately.
>
> There are likely others, but I can't read everything.
>
Thx, keith. Lange Zeit...viel Wasser.
Would you indulge me by allowing me to ask you, Keith, the other Keith,
my good old friend, how do people mix C and Perl with installations?
--
Cal
------------------------------
Date: Sat, 25 Aug 2012 02:56:19 -0700 (PDT)
From: bjlockie <bjlockie@lockie.ca>
Subject: check for exact # of digits
Message-Id: <54ff9036-1aaa-45d4-8953-e7803b756bbc@googlegroups.com>
I have this at the beginning of a sub ($checkDate is an input parameter).
I want to check for exactly 8 digits.
This works for less than 8 but doesn't work for more than 8.
if ($checkDate !~ /^\d{1,8}/) {
return "Date ($checkDate) must be YYYYMMDD\n";
}
------------------------------
Date: Sat, 25 Aug 2012 03:40:16 -0700 (PDT)
From: Klaus <klaus03@gmail.com>
Subject: Re: check for exact # of digits
Message-Id: <fe916411-9ba6-42a4-bb79-178eeb7b84c7@e14g2000yqm.googlegroups.com>
On 25 ao=FBt, 11:56, bjlockie <bjloc...@lockie.ca> wrote:
> I have this at the beginning of a sub ($checkDate is an input parameter).
> I want to check for exactly 8 digits.
> This works for less than 8 but doesn't work for more than 8.
>
> =A0 =A0if ($checkDate !~ /^\d{1,8}/) {
> =A0 =A0 =A0 =A0 return "Date ($checkDate) must be YYYYMMDD\n";
> =A0 =A0}
You should anchor (with $) the end of the string as well:
if ($checkDate !~ /^\d{1,8}$/) {
------------------------------
Date: Sat, 25 Aug 2012 13:16:11 +0200
From: Josef Moellers <josef.moellers@invalid.invalid>
Subject: Re: check for exact # of digits
Message-Id: <a9rqfsFpceU1@mid.individual.net>
On 08/25/2012 12:40 PM, Klaus wrote:
> On 25 août, 11:56, bjlockie <bjloc...@lockie.ca> wrote:
>> I have this at the beginning of a sub ($checkDate is an input parameter).
>> I want to check for exactly 8 digits.
>> This works for less than 8 but doesn't work for more than 8.
>>
>> if ($checkDate !~ /^\d{1,8}/) {
>> return "Date ($checkDate) must be YYYYMMDD\n";
>> }
>
> You should anchor (with $) the end of the string as well:
> if ($checkDate !~ /^\d{1,8}$/) {
>
If you want to check for *exactly* 8, also leave out the "1,":
if ($checkDate !~ /^\d{8}$/) {
You could also check *and* split:
if (my ($y, $m, $d) = ($checkdate =~ /^(\d{4})(\d{2})(\d{2})$/)) {
print "$d.$m.$y\n";
}
Josef
------------------------------
Date: Sat, 25 Aug 2012 17:59:22 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: check for exact # of digits
Message-Id: <ascng9-3au.ln1@anubis.morrow.me.uk>
Quoth bjlockie <bjlockie@lockie.ca>:
> I have this at the beginning of a sub ($checkDate is an input parameter).
> I want to check for exactly 8 digits.
> This works for less than 8 but doesn't work for more than 8.
>
> if ($checkDate !~ /^\d{1,8}/) {
Be a little careful with \d, \s and \w. If there is any chance your
strings might contain Unicode characters, they will match a lot more
than you might expect. If you have perl 5.14, you can avoid this with
the /a modifier; otherwise, I would recommend using [0-9] instead.
Ben
------------------------------
Date: Sun, 26 Aug 2012 23:25:02 -0700
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: check for exact # of digits
Message-Id: <9pE_r.416$Vf1.143@newsfe23.iad>
bjlockie wrote:
> I have this at the beginning of a sub ($checkDate is an input parameter).
> I want to check for exactly 8 digits.
> This works for less than 8 but doesn't work for more than 8.
>
> if ($checkDate !~ /^\d{1,8}/) {
> return "Date ($checkDate) must be YYYYMMDD\n";
> }
if ( 8 == $checkDate =~ tr/0-9// ) {
return "Date ($checkDate) must be YYYYMMDD\n";
}
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Mon, 27 Aug 2012 12:47:26 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: check for exact # of digits
Message-Id: <eb3sg9-5ik1.ln1@anubis.morrow.me.uk>
Quoth jwkrahn@shaw.ca:
> bjlockie wrote:
> > I have this at the beginning of a sub ($checkDate is an input parameter).
> > I want to check for exactly 8 digits.
> > This works for less than 8 but doesn't work for more than 8.
> >
> > if ($checkDate !~ /^\d{1,8}/) {
> > return "Date ($checkDate) must be YYYYMMDD\n";
> > }
>
> if ( 8 == $checkDate =~ tr/0-9// ) {
> return "Date ($checkDate) must be YYYYMMDD\n";
> }
That's not the same. For one thing I believe you have the condition the
wrong way around; for another, the OP's pattern is anchored (at the
beginning, and should be at the end), which cannot be emulated with
tr///.
Something along the lines of
unless (length $checkDate == 8 and $checkDate =~ tr/0-9// == 8) {
or
if (length $checkDate != 8 or $checkDate =~ tr/0-9//c) {
might work, but is more cumbersome than a pattern match.
Ben
------------------------------
Date: Mon, 27 Aug 2012 12:55:34 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: check for exact # of digits
Message-Id: <87d32ctuq1.fsf@sapphire.mobileactivedefense.com>
"John W. Krahn" <jwkrahn@example.com> writes:
> bjlockie wrote:
>> I have this at the beginning of a sub ($checkDate is an input parameter).
>> I want to check for exactly 8 digits.
>> This works for less than 8 but doesn't work for more than 8.
>>
>> if ($checkDate !~ /^\d{1,8}/) {
>> return "Date ($checkDate) must be YYYYMMDD\n";
>> }
>
> if ( 8 == $checkDate =~ tr/0-9// ) {
Please do not copy this style. The justification for that is that -
occasionally - this will result in a compiler error when some
mathematically inclined newbie forgot that = is the assignment
operator and not the one which tests for equality. But in reality,
it's just another stylistic byzantinism[*] some people love to use
because the very notion of doing anything in straight-forward way just
feels wrong to them.
[*] In real languages, one asks for the value of an attribute (Is the
color red?) and not for the attribute of a value (Is red the color?,
aka 'She is your sister' vs 'Your sister she is').
------------------------------
Date: Sun, 26 Aug 2012 00:39:00 -0600
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: magic installation woes [OT]
Message-Id: <qrCdnU4zgrwfWaTNnZ2dnUVZ_gednZ2d@supernews.com>
On 08/23/2012 03:47 AM, Rainer Weikusat wrote:
> Cal Dershowitz <cal@example.invalid> writes:
>
> [...]
>
>> Q1) What does it mean to be "processing triggers?"
>
> [...]
>
>> Processing triggers for libc-bin ...
>> ldconfig deferred processing now taking place
>>
>> Q2) What's that now? ^^^^
>
> Please consider to stop crossposting general Linux-related questions
> to completely unrelated newsgroups.
>
> Answer: One part of the installation of a Debian package is running
> the so-called 'postinstall' script. As the name might suggest, this
> script runs after all files the package is composed of have been
> installed. Its purpose is to configure whatever needs to be configured
> in order to integrate the package into the system. One example of this
> is what the 'ldconfig deferred processing' refers to: Shared libraries
> can be installed in any number of different filesystem locations (in
> the most simple case, the system uses /lib and /usr/lib). Whenever a
> process using a particular shared library needs to be started, the
> file corresponding with this libray needs to be loaded in addition to
> the file containing the main program (simplification). Often, the same
> library is used by many running processes (eg, the C library is used
> by all of them). In order to avoid searching the filesystem for the
> same file still residing in the same location over and over again, the
> system maintains a cache which records the location of all installed
> shared libraries. Whenever a new shared library is installed, this
> cache needs to be updated so that the runtime linker knows where to
> find he corresponding file. This is accomplished by running the
> ldconfig command. When installing multiple shared libraries, running
> ldconfig once after all the files are installed is sufficient to
> update the cache. Because of this, a package which needs this doesn't
> run ldconfig directly from its postinstall script but 'triggers' a
> ldconfig run instead. This means it informs the installation system
> that ldconfig needs to be executed before this particular package will
> be in a usable state. The installation system records this fact and
> executes all actions triggered during installation of a series of
> packages after all of them have been installed.
>
Das habe ich ueberhaupt nicht verstanden. Ich glaube dass die Spuren da
sind, z. B, mit ldconfig. Das siehst mormonisch aus. Tja.
--
Cal
--
Cal
------------------------------
Date: Sun, 26 Aug 2012 11:29:51 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: magic installation woes [OT]
Message-Id: <87txvqt080.fsf@sapphire.mobileactivedefense.com>
Cal Dershowitz <cal@example.invalid> writes:
> On 08/23/2012 03:47 AM, Rainer Weikusat wrote:
>> Cal Dershowitz <cal@example.invalid> writes:
>>
>> [...]
>>
>>> Q1) What does it mean to be "processing triggers?"
>>
>> [...]
>>
>>> Processing triggers for libc-bin ...
>>> ldconfig deferred processing now taking place
>>>
>>> Q2) What's that now? ^^^^
>>
>> Please consider to stop crossposting general Linux-related questions
>> to completely unrelated newsgroups.
>>
>> Answer: One part of the installation of a Debian package is running
>> the so-called 'postinstall' script.
[...]
> Das habe ich ueberhaupt nicht verstanden.
"Wer hoeren will muss schweigen koennen".
------------------------------
Date: Sun, 26 Aug 2012 20:06:43 -0500
From: Ignoramus11402 <ignoramus11402@NOSPAM.11402.invalid>
Subject: Semi-random sentence generator
Message-Id: <a6idnaN2uae-VafNnZ2dnUVZ_vKdnZ2d@giganews.com>
I want to generate some sentences that would seem random enough to look
different, but would, in fact, convey the same message.
For example:
* Please provide a phone number in your response
* You should provide a telephone number in your email
* I want you to include your phone number in your messages, please
You are getting the idea. What I would like is to vary the phrasing a
little bit, add "please" or "You should" and so on, but keep the core
meaning of "provide phone number".
I can write something of this sort myself, probably based on BNF and
config files.
Before I embark on writing a module for this sort of thing, I wanted
to check if perhaps am existing module could be used for this. Are
there any perl modules that do this "sentence variation"?
Thanks.
i
------------------------------
Date: Sat, 25 Aug 2012 02:59:33 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Very simple hash/regex question
Message-Id: <55olg9-4el.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
> In article <pjlig9-r06.ln1@anubis.morrow.me.uk>,
> Ben Morrow <ben@morrow.me.uk> wrote:
> >Quoth tmcd@panix.com:
> >>
> >> 2: I don't believe Perl defines an order of operations in this case,
> >> where one part of the expression modifies $_ and another part uses
> >> it. If it evaluates left to right, then $hash{$_} will try to use the
> >> transformed $_, so it won't find the value. (This bit me on my first
> >> attempt too.)
> >
> >I believe the order of operations is always well-defined in Perl: that
> >is, I don't know of any cases where it's been changed, nor any cases
> >where changing the order wouldn't be considered a bug.
>
> TL;DR: show me where Perl systematically talks about order of
> evaluation, except implicitly in some places, or talks about anything
> like "sequence points".
>
> I don't know of any place that Perl explicitly defines the order of
> evaluation and refers to anything like C's "sequence points", except
> where implied by things like "If the argument before the ? is true,
> the argument before the : is returned, otherwise the argument after
> the : is returned.".
I don't either, but in practice the order of evalution is well-defined,
does not change between perl versions, and can be determined by
experiment if nothing else. A great deal of Perl code implicitly relies
on the current evaluation order; therefore, any perl release which
changed it would fail the rather comprehensive compatibility testing
done before a release, and the change would almost certainly be
considered a bug.
You have to remember that Perl is not like C: there is only one
implementation, and the documentation is a description of the behaviour
of that implementation rather than a prescriptive standard implementors
must follow. IME discrepancies are more commonly resolved by changing
the documentation to match the actual behaviour than the other way
around, except in cases where the behaviour makes no sense.
> For example, for ++ and --, man perlop has
>
> Note that just as in C, Perl doesn't define when the variable is
> incremented or decremented. You just know it will be done sometime
> before or after the value is returned. This also means that
> modifying a variable twice in the same statement will lead to
> undefined behavior. Avoid statements like:
>
> $i = $i ++;
> print ++ $i + $i ++;
>
> Perl will not guarantee what the result of the above statements
> is.
As I believe I have said before, IMHO this passage of the documentation
is just FUD, and it shouldn't be there. Perl does not have the concept
of 'sequence points', because it has a completely defined order of
evaluation instead. Given the way the perl compiler compiles those
statements into optrees, there is only one possible result.
In the first case, the post-increment happens before the assignment, but
returns the old value, so $i is unchanged; in the second, the
pre-increment happens first and returns an alias to $i, then the
post-increment happens and returns the previous value of $i, then the
add happens, then the print, so the result is equivalent to
$i = $i + 1; # pre-increment returns an alias
my $j = $i; $i = $i + 1; # post-increment returns a copy
print $i + $j;
The fact that pre-increment returns an alias, rather than a copy of the
new value, is certainly a little confusing, and may be why someone added
that passage to the docs in the first place, but IMHO it's better to
explain how things work than to hide behind language stolen from the C
standard.
Note that adding a 'sequence point' here makes no difference:
my $i = 2;
my $j;
$j = \++$i, $i = 10, say $$j;
will print '10' despite the assignment to $j happening before the
assignment to $i. The ref is needed because normal scalar assignment
makes a copy of the assigned value, again regardless of 'sequence points'.
> >In this case, '=>' is just sugar for ',', so the order would be
> >well-defined even in C.
>
> No it would not. In the map above, the tokens "=>" and "," are not
> comma operators, which in C would cause a sequence point. The only
> place I know of in C where "," represents a list of values is in
> initializations of arrays or structs or the like, and the draft I saw
> (can't find the real standard) has "The evaluations of the
> initialization list expressions are indeterminately sequenced with
> respect to one another and thus the order in which any side effects
> occur is unspecified."
There is only one comma operator in Perl. (It's called OP_LIST,
incidentally, even in scalar context.) It evaluates its arguments in
order; in list context all are in list context, and the return value is
the concatenation of the returned lists; in void context all are in void
context; and in scalar context all but the last are in void context, the
last is in scalar context, and the return value is that of the final
expression. There is no special behaviour attached to comma-in-scalar-
context which would cause it to be a sequence point; in fact, you can
see there can't be, because in a construction like
sub foo { 1, 2, 3 }
the context is not determined until after the sub has been compiled.
Ben
------------------------------
Date: Sat, 25 Aug 2012 12:23:44 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Very simple hash/regex question
Message-Id: <slrnk3h9tj.fde.hjp-usenet2@hrunkner.hjp.at>
On 2012-08-23 20:22, Tim McDaniel <tmcd@panix.com> wrote:
> In article <3d7894ea-712f-44ba-b266-d72614f0a7c5@e29g2000vbm.googlegroups.com>,
> Klaus <klaus03@gmail.com> wrote:
>>On 23 août, 20:03, Tuxedo <tux...@mailinator.com> wrote:
>>> What is a simple way to copy a hash into for example %hash_copy and change
>>> all characters in the keys of the copied hash to lowercases and all
>>> whitespaces to underscores?
>>
>>use 5.014;
>>my %hash = ('My first subject key' => 'my first value',
>> 'my second Subject key' => 'my second value');
>>
>>my %hash_copy = map { lc($_ =~ s/ /_/gr) => $hash{$_} } %hash;
>
> Fundamental problem 0: You didn't test the proposal.
>
> 1: %hash returns both keys and values, so hash_copy would get two
> hashes for each one in the original table, one of them being
> "transformed value => undef". You want "map{...}keys %hash".
Yup.
> 2: I don't believe Perl defines an order of operations in this case,
> where one part of the expression modifies $_ and another part uses
> it. If it evaluates left to right, then $hash{$_} will try to use the
> transformed $_, so it won't find the value. (This bit me on my first
> attempt too.)
$_ isn't transformed because of the /r modifier. So the order doesn't
matter (although I agree with Ben that it's well-defined in this case).
> My correction to that:
>
> use 5.014;
> my %hash_copy = map { my $key = $_; lc(s/\s/_/gr) => $hash{$key} } keys %hash;
>
> But since you need a temp anyway (or so I think), there's no need for
> s///r, so no need to require 5.014.
The /r avoids the need for the temporary variable. You either need a
temporary variable (then it works with any version of perl) or /r (then
you need 5.14), but not both.
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, 25 Aug 2012 14:46:35 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Very simple hash/regex question
Message-Id: <k1aoga$hor$1@reader1.panix.com>
In article <slrnk3h9tj.fde.hjp-usenet2@hrunkner.hjp.at>,
Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>On 2012-08-23 20:22, Tim McDaniel <tmcd@panix.com> wrote:
>> 2: I don't believe Perl defines an order of operations in this case,
>> where one part of the expression modifies $_ and another part uses
>> it. If it evaluates left to right, then $hash{$_} will try to use the
>> transformed $_, so it won't find the value. (This bit me on my first
>> attempt too.)
>
>$_ isn't transformed because of the /r modifier. So the order doesn't
>matter (although I agree with Ben that it's well-defined in this case).
I am not familiar with s///r, as $ORKPLACE doesn't have the current
Perl. Thank you for the correction.
Were it to depend on the order of effects (if there were not explicit
definition as, for example, && and || provide), I would intensely
dislike it, even if experimentally it were to work.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sat, 25 Aug 2012 18:27:53 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Very simple hash/regex question
Message-Id: <871uiuubja.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
> my $i = 2;
> my $j;
> $j = \++$i, $i = 10, say $$j;
>
> will print '10' despite the assignment to $j happening before the
> assignment to $i.
Eh ... considering that the value of $j is a reference to $i, what
else should $$j print except the current value of $i?
------------------------------
Date: Sun, 26 Aug 2012 23:19:54 -0700
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: Very simple hash/regex question
Message-Id: <gkE_r.2170$Wh5.1950@newsfe14.iad>
Tuxedo wrote:
> What is a simple way to copy a hash into for example %hash_copy and change
> all characters in the keys of the copied hash to lowercases and all
> whitespaces to underscores?
>
> my %hash = ('My first subject key' => 'my first value',
> 'my second Subject key' => 'my second value');
>
> my %hash_copy = %hash;
>
> ..?
$ perl -e'
use Data::Dumper;
my %hash = (
q/My first subject key/ => q/my first value/,
q/my second Subject key/ => q/my second value/,
);
my %hash_copy = %hash;
print Dumper \%hash_copy;
for my $key ( keys %hash_copy ) {
( my $new_key = lc $key ) =~ s/\s/_/g;
$hash_copy{ $new_key } = delete $hash_copy{ $key };
}
print Dumper \%hash_copy;
'
$VAR1 = {
'My first subject key' => 'my first value',
'my second Subject key' => 'my second value'
};
$VAR1 = {
'my_first_subject_key' => 'my first value',
'my_second_subject_key' => 'my second value'
};
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Mon, 27 Aug 2012 12:39:53 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Very simple hash/regex question
Message-Id: <9t2sg9-5ik1.ln1@anubis.morrow.me.uk>
Quoth jwkrahn@shaw.ca:
> Tuxedo wrote:
> > What is a simple way to copy a hash into for example %hash_copy and change
> > all characters in the keys of the copied hash to lowercases and all
> > whitespaces to underscores?
> >
> > my %hash = ('My first subject key' => 'my first value',
> > 'my second Subject key' => 'my second value');
> >
> > my %hash_copy = %hash;
> >
> > ..?
>
> $ perl -e'
> use Data::Dumper;
> my %hash = (
> q/My first subject key/ => q/my first value/,
> q/my second Subject key/ => q/my second value/,
> );
> my %hash_copy = %hash;
> print Dumper \%hash_copy;
> for my $key ( keys %hash_copy ) {
> ( my $new_key = lc $key ) =~ s/\s/_/g;
> $hash_copy{ $new_key } = delete $hash_copy{ $key };
> }
> print Dumper \%hash_copy;
> '
my %hash_copy = map { (state $p ^= 1) ? lc =~ s/\s/_/gr : $_ } %hash;
(Requires 5.14, obviously.) Though it may be an accident that 'state'
can be used like that, so it might be better to write
my %hash_copy = map {
state $p;
($p ^= 1) ? lc =~ s/\s/_/gr : $_;
} %hash;
Certainly, if you try to initialise the state variable you get 'Can't
modify 'once' in bitwise xor', which is a little irritating but not
entirely surprising.
(Oddly, the expression
(++$p) %= 2
gives 'Can't modify preincrement in modulus', which, given the
discussion xthread about the fact that preincrement returns the
incremented variable, is a little surprising. Expanding the ++ to
($p += 1) %= 2
works as expected.)
Ben
------------------------------
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 3767
***************************************
