[33058] in Perl-Users-Digest
Perl-Users Digest, Issue: 4334 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Dec 23 14:09:19 2014
Date: Tue, 23 Dec 2014 11:09:06 -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 Tue, 23 Dec 2014 Volume: 11 Number: 4334
Today's topics:
Re: Both substitute and filter <bauhaus@futureapps.invalid>
Re: Both substitute and filter <bauhaus@futureapps.invalid>
Re: Both substitute and filter <rweikusat@mobileactivedefense.com>
Re: Both substitute and filter <bauhaus@futureapps.invalid>
Re: Both substitute and filter <rweikusat@mobileactivedefense.com>
Re: Both substitute and filter <bauhaus@futureapps.invalid>
Re: Both substitute and filter <rweikusat@mobileactivedefense.com>
Re: Both substitute and filter <mvdwege@gmail.com>
Re: Both substitute and filter <rweikusat@mobileactivedefense.com>
fields separation <gravitalsun@hotmail.foo>
Re: fields separation <rweikusat@mobileactivedefense.com>
Re: fields separation <rweikusat@mobileactivedefense.com>
Re: fields separation <rweikusat@mobileactivedefense.com>
Re: Read and place lines in key/value list <rweikusat@mobileactivedefense.com>
Re: Read and place lines in key/value list <hjp-usenet3@hjp.at>
Re: Read and place lines in key/value list <rweikusat@mobileactivedefense.com>
Sort on regexp match (Tim McDaniel)
Wide character in setenv <jidanni@jidanni.org>
Re: Wide character in setenv <rweikusat@mobileactivedefense.com>
Re: Wide character in setenv <whynot@pozharski.name>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 22 Dec 2014 17:59:33 +0100
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Subject: Re: Both substitute and filter
Message-Id: <m79il0$dm7$1@dont-email.me>
On 18.12.14 09:45, Mart van de Wege wrote:
> Georg Bauhaus <bauhaus@futureapps.invalid> writes:
>
>>
>>> As above, in
>>>
>>> my $xyz = 0;
>> there might be a few lines of code here!
>>> ++$xys;
>>>
>>> the = 0 is useless.
>>
>> “= 0” tells us the kind of the scalar! That's quite a use, I'd say.
>> $xyz is an int, it's not a string, and not a ref.
>
> And all that might have been more clearly communicated by picking a more
> obvious variable name, instead of adding a superfluous assignment.
A claim about communication, without any indication, unfortunately,
of why it might be clear or not.
my $chocolates_in_the_box;
is missing something. Now, guess what.
> Conciseness is a virtue in helping understanding too.
my @foo = ();
is a concise way of reporting the initial value to the (presumed)
average programmer.
my $foo = [];
is a concise way of saying a very similar thing. Do you suggest
to write
my $list_of_foo;
instead? And then
push @{ $list_of_foo }, ...;
Or, maybe
my $foo; # ref ARRAY
It's good to see remarks about "author being the most frequent reader",
because whenever that's true, there is an authority. It's not us.
But if no one else reads his "technically superfluous assignments",
then there is no issue whatsoever. Again, it's not for me to comment.
------------------------------
Date: Mon, 22 Dec 2014 18:10:54 +0100
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Subject: Re: Both substitute and filter
Message-Id: <m79ja8$h22$1@dont-email.me>
On 18.12.14 00:14, Rainer Weikusat wrote:
> Georg Bauhaus <bauhaus@futureapps.invalid> writes:
>
> [...]
>
>>> The thing is, code isn't solely written for machines but also for other
>>> people.
>>
>> Precisely. Written by and for people like the people arguing here
>> for either way of expressing ideas.
>
> It's not possible to express anything in an intelligible way by uttering
> meaningless statements.
I have found it a good idea to not valuate something I don't understand.
But I see you find the subject of more than one ordinary programmer
unintelligible.
------------------------------
Date: Mon, 22 Dec 2014 17:34:49 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Both substitute and filter
Message-Id: <87egrrh9l2.fsf@doppelsaurus.mobileactivedefense.com>
Georg Bauhaus <bauhaus@futureapps.invalid> writes:
> On 18.12.14 00:14, Rainer Weikusat wrote:
>> Georg Bauhaus <bauhaus@futureapps.invalid> writes:
>>
>> [...]
>>
>>>> The thing is, code isn't solely written for machines but also for other
>>>> people.
>>>
>>> Precisely. Written by and for people like the people arguing here
>>> for either way of expressing ideas.
>>
>> It's not possible to express anything in an intelligible way by uttering
>> meaningless statements.
>
> I have found it a good idea to not valuate something I don't
> understand.
Than consider acting in this way: You apparently don't understand that
something which doesn't have a meaning outside of your head cannot
communicate anything to anyone else ...
> But I see you find the subject of more than one ordinary programmer
> unintelligible.
... hence, you shouldn't assume that people who have to deal with both
'other programmers' and 'code written by other programmers' don't know
what they're talking about when they point this out to you.
------------------------------
Date: Mon, 22 Dec 2014 19:14:47 +0100
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Subject: Re: Both substitute and filter
Message-Id: <m79n21$k5$1@dont-email.me>
On 22.12.14 18:34, Rainer Weikusat wrote:
> You apparently don't understand that
> something which doesn't have a meaning outside of your head
The meaning has been communicated. Maybe you missed it?
------------------------------
Date: Mon, 22 Dec 2014 18:23:05 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Both substitute and filter
Message-Id: <87a92fh7cm.fsf@doppelsaurus.mobileactivedefense.com>
Georg Bauhaus <bauhaus@futureapps.invalid> writes:
> On 22.12.14 18:34, Rainer Weikusat wrote:
>> You apparently don't understand that
>> something which doesn't have a meaning outside of your head
[can't communicate anything to anyone]
> The meaning has been communicated. Maybe you missed it?
AFAIK, I'm not on topic here.
Some more expert tips you might consider useful:
http://gutenberg.spiegel.de/buch/die-kunst-recht-zu-behalten-4994/1
------------------------------
Date: Mon, 22 Dec 2014 19:49:59 +0100
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Subject: Re: Both substitute and filter
Message-Id: <m79p41$9mv$1@dont-email.me>
On 22.12.14 19:23, Rainer Weikusat wrote:
> Georg Bauhaus <bauhaus@futureapps.invalid> writes:
>> On 22.12.14 18:34, Rainer Weikusat wrote:
>>> You apparently don't understand that
>>> something which doesn't have a meaning outside of your head
>
> [can't communicate anything to anyone]
>
>> The meaning has been communicated. Maybe you missed it?
>
> AFAIK, I'm not on topic here.
>
> Some more expert tips you might consider useful:
>
> http://gutenberg.spiegel.de/buch/die-kunst-recht-zu-behalten-4994/1
>
Not this time. It is too important to exculpate anyone who writes
my [$@%]foo = ...;
when they want to. This isn't "wrong", and they are not "wrong".
Doing so just has consequences, some of which are technical, and some of
which influence human readers, including authors.
No single Perl programmer should suffer from the language's contraptions
when that's not necessary. (One could adduce a language design flaw
in syntax in view of symbol tables vs programmers.) The actual
solution that a working Perl program is expressing can, I think,
be considered more important than the purity of language based
exegesis and guidance based upon it.
The latter is helpful. It may be appreciated. But it is no absolute,
given the notion of programming situation. TIMTOWTDI is a reality
because of programming situations. The ways include introductions of
variables and their values.
------------------------------
Date: Mon, 22 Dec 2014 19:19:02 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Both substitute and filter
Message-Id: <873887h4rd.fsf@doppelsaurus.mobileactivedefense.com>
Georg Bauhaus <bauhaus@futureapps.invalid> writes:
> On 22.12.14 19:23, Rainer Weikusat wrote:
>> Georg Bauhaus <bauhaus@futureapps.invalid> writes:
>>> On 22.12.14 18:34, Rainer Weikusat wrote:
>>>> You apparently don't understand that
>>>> something which doesn't have a meaning outside of your head
>>
>> [can't communicate anything to anyone]
>>
>>> The meaning has been communicated. Maybe you missed it?
>>
>> AFAIK, I'm not on topic here.
>>
>> Some more expert tips you might consider useful:
>>
>> http://gutenberg.spiegel.de/buch/die-kunst-recht-zu-behalten-4994/1
>>
>
> Not this time. It is too important to exculpate anyone who writes
>
> my [$@%]foo = ...;
>
> when they want to. This isn't "wrong", and they are not "wrong".
[more philosophical statements on 'wrongness' and 'purity' and ...]
I'm sorry but I'm going to ignore that as I'm not interested in
'fighting' this (or anything) in order to 'win it' and I see only
general statements in here I'm not in the mood to try to dispute
regardless of what I'm thinking of them.
------------------------------
Date: Mon, 22 Dec 2014 20:31:39 +0100
From: Mart van de Wege <mvdwege@gmail.com>
Subject: Re: Both substitute and filter
Message-Id: <86sig7mqg4.fsf@gaheris.avalon.lan>
Georg Bauhaus <bauhaus@futureapps.invalid> writes:
>
>> Conciseness is a virtue in helping understanding too.
>
> my @foo = ();
>
> is a concise way of reporting the initial value to the (presumed)
> average programmer.
>
> my $foo = [];
>
> is a concise way of saying a very similar thing. Do you suggest
> to write
>
> my $list_of_foo;
>
> instead?
No, because those two case are not similar at all.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Mon, 22 Dec 2014 22:33:17 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Both substitute and filter
Message-Id: <87oaqvfh76.fsf@doppelsaurus.mobileactivedefense.com>
Georg Bauhaus <bauhaus@futureapps.invalid> writes:
[...]
> my @foo = ();
>
> is a concise way of reporting the initial value to the (presumed)
> average programmer.
It isn't:
my @foo = ();
is a Perl expression statement and it doesn't have any 'natural' meaning
outside of the semantics assigned to it by the language.
my @foo
means '@foo is to be a name of an array only valid in the enclosing
lexical scope' (actually, it's "valid from the beginning of the next
statement until the end of the enclosing scope").
@foo = ()
is a list assignment: The contents of @foo are to be replaced with
what's on the list. Since the list is empty, that's
"nothing". But since @foo didn't have any contents, the assignment has
no effect. And "this doesn't do anything" provides no information about
the reason why it was written nevertheless.
Of course, someone with a list a bit of experience with other
programming languages than Perl (whether or not this is true for 'an
average Perl programmer' is a good question) will easily come up with a
couple of probable conjectures about the motivation behind this, eg
'knee-jerk addition made by someone more used to languages where all
local variables have to be initialized prior to first use' but that's
only a conjecture and certainty can only be provided by 'real'
documentation explaining the reasoning behind the meaningless
assignment. Not only doesn't this document anything, since it defies
reason, it better be documented itself.
------------------------------
Date: Tue, 23 Dec 2014 01:36:40 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: fields separation
Message-Id: <m7a9ul$2hsm$1@news.ntua.gr>
Find fields using any separator e.g <*> if the input text is
aaaa<
*>bb<*>1
23<*
>cc
c<*>dddd<*>
<
*
>
ee
<*
><
*>
ee
<*>
ffff
<*
>
the correct output should be
aaaa
bb
123
ccc
dddd
ee
ee
ffff
a working but slow solution is
my $separator = '<*>';
my $file = 'test.txt';
open FILE, '<:raw', 'test.txt' or die $!;
my ($data, $field, $lensep) = ('', '', length $separator);
while (read FILE, $data, 1)
{
if ($separator eq substr $field, -$lensep)
{
seek FILE, -1 ,1;
$field = substr $field, 0, -$lensep;
print "*$field*\n";
$field = ''
}
elsif ( $data !~/r|\n/ )
{
$field .= $data
}
}
close FILE;
if ($separator eq substr $field, -$lensep)
{
$field = substr $field, 0, -$lensep;
print "*$field*\n"
}
------------------------------
Date: Tue, 23 Dec 2014 18:26:38 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: fields separation
Message-Id: <87h9wmrzmp.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> Find fields using any separator e.g <*> if the input text is
>
> aaaa<
> *>bb<*>1
> 23<*
>
>>cc
> c<*>dddd<*>
> <
> *
>
>>
> ee
> <*
>><
> *>
>
> ee
>
> <*>
> ffff
> <*
>>
>
>
> the correct output should be
>
> aaaa
> bb
> 123
> ccc
> dddd
>
> ee
>
> ee
> ffff
A cute little problem. For the code below, I've assumed that whitespace
except \n should become part of fields while any number of consecutive
\ns should be ignored. Since I don't Windows, I don't have to deal with
carriages returning at inconvenient times.
Something I believe to work within these limits (this may still be
terribly wasteful if perl can't delete characters at the beginning of a
string efficiently which it probably can't):
-----
use constant BLOCK => 64;
sub make_reader
{
my $fh = $_[0];
return sub {
my $rc;
$rc = sysread($fh, $_[0], BLOCK);
unless ($rc) {
$rc // die("$!");
return;
}
return 1;
};
}
sub find_fields
{
my ($next_block, $sep) = @_;
my ($in, $field, $gather, $sp, $re);
my @fields;
$gather = 1;
$re = '^([^'.substr($sep, 0, 1).'\n]+)';
OUTER:
while ($in || $next_block->($in)) {
if ($gather) {
$in =~ /$re/ and do {
$field .= $1;
substr($in, 0, length($1), '');
next;
};
$in =~ /^(\n+)/ and do {
substr($in, 0, length($1), '');
next;
};
$sp = 1;
$gather = 0;
substr($in, 0, 1, '');
next;
}
while (substr($in, 0, 1) eq substr($sep, $sp, 1)) {
substr($in, 0, 1, '');
if (++$sp == length($sep)) {
push(@fields, $field);
$field = '';
$gather = 1;
next OUTER;
}
next OUTER unless $in;
}
$in =~ /^(\n+)/ and do {
substr($in, 0, length($1), '');
next;
};
$field .= substr($sep, 0, $sp);
$gather = 1;
}
$field .= substr($sep, 0, $sp) unless $gather;
push(@fields, $field) if $field;
return @fields;
}
print(map { $_, "\n" } find_fields(make_reader(\*STDIN), '<*>'));
------------------------------
Date: Tue, 23 Dec 2014 18:31:52 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: fields separation
Message-Id: <87d27arzdz.fsf@doppelsaurus.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>> Find fields using any separator e.g <*> if the input text is
[...]
> Something I believe to work within these limits
First bug: '0' (string of length 1 containing a '0 character') counts as
false in Perl.
--- a.pl 2014-12-23 18:29:36.779777954 +0000
+++ b.pl 2014-12-23 18:29:18.852332886 +0000
@@ -27,7 +27,7 @@
$re = '^([^'.substr($sep, 0, 1).'\n]+)';
OUTER:
- while ($in || $next_block->($in)) {
+ while (length($in) || $next_block->($in)) {
if ($gather) {
$in =~ /$re/ and do {
$field .= $1;
@@ -59,7 +59,7 @@
next OUTER;
}
- next OUTER unless $in;
+ next OUTER unless length($in);
}
$in =~ /^(\n+)/ and do {
------------------------------
Date: Tue, 23 Dec 2014 18:51:00 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: fields separation
Message-Id: <878uhyryi3.fsf@doppelsaurus.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>> Find fields using any separator e.g <*> if the input text is
>
> [...]
>
>> Something I believe to work within these limits
>
> First bug: '0' (string of length 1 containing a '0 character') counts as
> false in Perl.
[...]
Second bug: In case the separator starts with \, it needs to be escaped
in $re so that it doesn't escape the \ of the \n:
$re = substr($sep, 0, 1);
$re = '\\\\' if $re eq '\\';
$re = '^([^'.$re.'\n]+)';
------------------------------
Date: Sun, 21 Dec 2014 19:13:02 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Read and place lines in key/value list
Message-Id: <87bnmwolz5.fsf@doppelsaurus.mobileactivedefense.com>
Tuxedo <tuxedo@mailinator.com> writes:
> key1 value1
> key2 value two
> key3
>
> What is a good way to import this into a list, so it would be the same as:
>
> %list = ('key1' => 'value1',
> 'key2' => 'value two'
> 'key3' => '');
>
> Each line of the text file represents a key and optional value.
>
> The separator is the first whitespace on each line.
Assuming the test data is available in a file name t, two methods would
be
-----------
use Data::Dumper;
open($fh, '<', 't');
%a_hash = map { chomp; split(' ', $_, 2); } <$fh>;
print Dumper(\%a_hash);
seek($fh, 0, 0);
%another_hash = map { /(\S+)\s*(.*)/ } <$fh>;
print Dumper(\%another_hash);
-----------
The first removes the newline from the input line and then splits it
into at most two fields separated by any number of whitespace
characters. The second uses a regex-match with two capture expressions
capturing the key and the value (if there is a value). It doesn't have
to deal with the line separator as \s matches \n but . doesn't (this
can be changed by using the /m flag). If there's only a key on an input
line, it will be associated with undef for #1 and with an empty string
for #2.
------------------------------
Date: Sun, 21 Dec 2014 20:33:57 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Read and place lines in key/value list
Message-Id: <slrnm9e855.ngu.hjp-usenet3@hrunkner.hjp.at>
On 2014-12-21 19:13, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> Tuxedo <tuxedo@mailinator.com> writes:
>> key1 value1
>> key2 value two
>> key3
[...]
> Assuming the test data is available in a file name t, two methods would
> be
>
> -----------
> use Data::Dumper;
>
> open($fh, '<', 't');
>
> %a_hash = map { chomp; split(' ', $_, 2); } <$fh>;
> print Dumper(\%a_hash);
>
> seek($fh, 0, 0);
>
> %another_hash = map { /(\S+)\s*(.*)/ } <$fh>;
> print Dumper(\%another_hash);
> -----------
>
> The first removes the newline from the input line and then splits it
> into at most two fields separated by any number of whitespace
^^^^^^^^^^^
This is a problem. If split returns only one field then the rest
of the input will be misaligned.
[...]
> If there's only a key on an input line, it will be associated with
> undef for #1
Only because it happened on the last line. Here is the output if I add
another line "key4 final\n":
$VAR1 = {
'key1' => 'value1',
'key3' => 'key4',
'final' => undef,
'key2' => 'value two'
};
(It works correctly if there is some whitespace after "key3", but then
the value is "", not undef)
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpat. -- Ralph Babel
------------------------------
Date: Sun, 21 Dec 2014 19:47:52 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Read and place lines in key/value list
Message-Id: <873888okd3.fsf@doppelsaurus.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2014-12-21 19:13, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>> Tuxedo <tuxedo@mailinator.com> writes:
>>> key1 value1
>>> key2 value two
>>> key3
> [...]
>> Assuming the test data is available in a file name t, two methods would
>> be
>>
>> -----------
>> use Data::Dumper;
>>
>> open($fh, '<', 't');
>>
>> %a_hash = map { chomp; split(' ', $_, 2); } <$fh>;
>> print Dumper(\%a_hash);
[...]
>> The first removes the newline from the input line and then splits it
>> into at most two fields separated by any number of whitespace
> ^^^^^^^^^^^
> This is a problem. If split returns only one field then the rest
> of the input will be misaligned.
Indeed. I didn't think of that. Another reason to prefer the
regex. Provided each line is guaranteed to end with a \n, two
workarounds could be
map { map { chomp; $_ } split(' ', $_, 2); } <$fh>
or
map { map { $i ^= 1 or chomp; $_ } split(' ', $_, 2); } <$fh>
Whether or not it is sensible to avoid chomping the keys in this way
would be an interesting question ...
------------------------------
Date: Tue, 23 Dec 2014 04:39:06 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Sort on regexp match
Message-Id: <m7arla$m5q$1@reader1.panix.com>
Yeah, another "what's the smoothest way to do this in Perl?" question.
I have a bunch of elements in an array along the lines of
{IDENTIFIER}{SUFFIX} was last touched on {DATE}
E.g.
FROBx3 was last touched on 2014-04-11
FROBx1 was last touched on 2014-03-17
NARFj5 was last touched on 2014-06-01
Fixed-width at the moment, as it happens, but certainly
I wanted to sort by the suffix, and then by the line.
I tried something along the lines of
sort {
($::a ~= /(..) /) cmp ($::b ~= /(..) /) ||
$::a cmp $::b
}
But the first comparison did nothing. I'd forgotten that m// in a
scalar context returns just a boolean.
Thing is, I can't think of a slick way to evaluate it in a list
context ("goatse operator!") and get the items returned ("er, not
goatse then").
sort {
my @vals = ($::a ~= /(..) /, $::b ~= /(..) /);
$vals[0] cmp $vals[1] || $::a cmp $::b
}
is doable but doesn't feel elegant. What I did pro tem was use
substr, but if I wanted to use FORTRAN WATFIV stuff, I'd use FORTRAN,
and I'd like to accomodate variable-width fields.
More generally, I think I'd like to try sorting by date (assume a nice
format like this where lexical sort works), and/or by suffix, and/or
by the identifier+suffix.
I think the coolest Perly way is probably just to do a Schwartzian
transform. Can anyone think of a better way?
(If anyone here is not familiar with a Schwartzian transform: a map or
other loop to transform each row into something like
{
LINE => 'FROBx3 was last touched on 2014-04-11',
SUFFIX => 'x3',
FULLID => 'FROBx3',
DATE => '2014-04-11',
}
then sort using $::a->{WHATEVER} and $::b->{WHATEVER}, then a map or
other loop to just grab the LINE value. Untested, something like
map {
$_->{LINE}
}
sort {
$::a->{DATE} cmp $::b->{DATE} ||
$::a->{SUFFIX} cmp $::b->{SUFFIX} ||
$::a->{FULLID} cmp $::b->{FULLID}
}
map {
my @bits = /^((.+)(..) was last touched on (.*))$/;
{ LINE => $1, SUFFIX => $3, FULLID => "$2$3", DATE => $4 }
}
@array
)
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Sun, 21 Dec 2014 19:22:12 +0000 (UTC)
From: Dan Jacobson <jidanni@jidanni.org>
Subject: Wide character in setenv
Message-Id: <m776l4$lac$1@news.datemas.de>
http://perl.developpez.com/documentations/en/5.18.0/perl5180delta.html says
Wide character in setenv
Attempts to put wide characters into environment variables via %ENV now provoke this warning.
$ perl -we 'use diagnostics; use utf8; $ENV{f}="哇";'
Wide character in setenv at -e line 1 (#1)
(S utf8) Perl met a wide character (>255) when it wasn't expecting
one. This warning is by default on for I/O (like print). The easiest
way to quiet this warning is simply to add the :utf8 layer to the
output, e.g. binmode STDOUT, ':utf8'. Another way to turn off the
warning is to add no warnings 'utf8'; but that is often closer to
cheating. In general, you are supposed to explicitly mark the
filehandle with an encoding, see open and "binmode" in perlfunc.
I need to use the use utf8 for other reasons.
Will any methods mentioned work?
------------------------------
Date: Sun, 21 Dec 2014 19:34:29 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Wide character in setenv
Message-Id: <877fxkokze.fsf@doppelsaurus.mobileactivedefense.com>
Dan Jacobson <jidanni@jidanni.org> writes:
> http://perl.developpez.com/documentations/en/5.18.0/perl5180delta.html says
> Wide character in setenv
> Attempts to put wide characters into environment variables via %ENV now provoke this warning.
The same text also states that
A value stored in an environment variable has always been
stringified. In this release, it is converted to be only a byte
string. First, it is forced to be only a string. Then if the
string is utf8 and the equivalent of utf8::downgrade() works,
that result is used; otherwise, the equivalent of utf8::encode()
is used, and a warning is issued about wide characters
An obvious way to avoid the warning would therefore be to ut8::encode or
utf8::downgrade the string yourself. OTOH, just disabling the 'perl does
the right thing and we hate this' warning seems like a sensible
approach, too.
------------------------------
Date: Mon, 22 Dec 2014 09:55:14 +0200
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Wide character in setenv
Message-Id: <slrnm9fjj2.q5j.whynot@orphan.zombinet>
with <m776l4$lac$1@news.datemas.de> Dan Jacobson wrote:
> http://perl.developpez.com/documentations/en/5.18.0/perl5180delta.html says
> Wide character in setenv
> Attempts to put wide characters into environment variables via %ENV
> now provoke this warning.
Probably, diagnostics.pm will be updated accordingly.
> $ perl -we 'use diagnostics; use utf8; $ENV{f}="哇";'
*SKIP*
> I need to use the use utf8 for other reasons.
> Will any methods mentioned work?
No. Layers are for IO::Handle and friends. You should do it old-style:
explicitly decode after you read and explicitly encode before you write.
perluniintro.pod and friends have more.
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
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 4334
***************************************
