[32537] in Perl-Users-Digest
Perl-Users Digest, Issue: 3802 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Oct 26 16:09:21 2012
Date: Fri, 26 Oct 2012 13:09:06 -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 Fri, 26 Oct 2012 Volume: 11 Number: 3802
Today's topics:
Re: Is Perl dying or not? <c182driver9@gideon.org>
Re: Is Perl dying or not? <rweikusat@mssgmbh.com>
Net:DNS:RR (sub-)classes and undefined methods <rweikusat@mssgmbh.com>
Re: Why "Wide character in print"? johndelacour@gmail.com
Re: Why "Wide character in print"? <derykus@gmail.com>
Re: Why "Wide character in print"? <*@eli.users.panix.com>
Re: Why "Wide character in print"? <ben@morrow.me.uk>
Re: Why "Wide character in print"? <*@eli.users.panix.com>
Re: Why "Wide character in print"? <ben@morrow.me.uk>
Re: Why was suid support dropped in perl? <c182driver9@gideon.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 23 Oct 2012 23:39:02 GMT
From: Andrew Gideon <c182driver9@gideon.org>
Subject: Re: Is Perl dying or not?
Message-Id: <qUFhs.17299$Xc6.10891@fed05.iad>
On Fri, 19 Oct 2012 21:43:53 -0500, Ignoramus7380 wrote:
> Lately, I have been seeing a lot of evidence that adoption and use of
> perl declines in favor of superficially "easier" languages.
I had to spend time again today dealing with code written in one of those
"easier" languages. It was a completely hardcoded piece of crap, and the
client was unhappy that the code was no longer working following some
content - read: data - changes.
Of course, the client hired the original programmers. In theory, they
brought this upon themselves. But it's tough for non-technical people to
properly evaluate the quality of technical people. Even the quality of
the work is tough to evaluate immediately, as a lot of "quality" involved
in software is related to its ability to evolve over time.
But sometimes I think we've made programming too easy - or at least too
easy in environments not sufficiently restrictive. Clients are getting
burned by ignorant coding, and this tends to make people trust our
profession even less.
- Andrew
------------------------------
Date: Thu, 25 Oct 2012 17:30:31 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Is Perl dying or not?
Message-Id: <87vcdy3460.fsf@sapphire.mobileactivedefense.com>
Andrew Gideon <c182driver9@gideon.org> writes:
> On Fri, 19 Oct 2012 21:43:53 -0500, Ignoramus7380 wrote:
>
>> Lately, I have been seeing a lot of evidence that adoption and use of
>> perl declines in favor of superficially "easier" languages.
>
> I had to spend time again today dealing with code written in one of those
> "easier" languages. It was a completely hardcoded piece of crap, and the
> client was unhappy that the code was no longer working following some
> content - read: data - changes.
[...]
> But sometimes I think we've made programming too easy - or at least too
> easy in environments not sufficiently restrictive.
I think this is wrong. 'Making programming easy' usually (and very
incorrectly) refers to reducing the amount of code which needs to be
written in order to deal with issues arising because of 'the solution
domain', the classic example would be memory management. But what
makes programming hard is not that this awful computer contains so
much stuff which doesn't exist anywhere outside of it (such as memory
which needs to be managed) but to come up with an algorithm capable
of solving a particular problem. Getting the problem-domain specific
stuff wrong will usually not prevent a program from functioning
because of technical reasons. Consequently, when manual memory
management is required, careless or clueless programmers will learn
that well enough to keep their programs from 'crashing' (or showing
any other obvious signs of a malfunction) but they will still produce
incorrect results.
------------------------------
Date: Thu, 25 Oct 2012 17:19:35 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Net:DNS:RR (sub-)classes and undefined methods
Message-Id: <87zk3a34o8.fsf@sapphire.mobileactivedefense.com>
As I just discovered by accident (typo), when one tries to invoke an
undefined method using an object derived from Net::DNS::RR as invocant,
the code will log the following nuisance error
Oct 25 17:28:25 marsh mes-configurator[15868]: #011
Oct 25 17:28:25 marsh mes-configurator[15868]: ***
Oct 25 17:28:25 marsh mes-configurator[15868]: *** WARNING!!! The program has attempted to call the method
Oct 25 17:28:25 marsh mes-configurator[15868]: *** "" for the following RR object:
Oct 25 17:28:25 marsh mes-configurator[15868]: ***
Oct 25 17:28:25 marsh mes-configurator[15868]: *** <binary RR here>
Oct 25 17:28:25 marsh mes-configurator[15868]: ***
Oct 25 17:28:25 marsh mes-configurator[15868]: *** This object does not have a method "". THIS IS A BUG
Oct 25 17:28:25 marsh mes-configurator[15868]: *** IN THE CALLING SOFTWARE, which has incorrectly assumed that
Oct 25 17:28:25 marsh mes-configurator[15868]: *** the object would be of a particular type. The calling
Oct 25 17:28:25 marsh mes-configurator[15868]: *** software should check the type of each RR object before
Oct 25 17:28:25 marsh mes-configurator[15868]: *** calling any of its methods.
instead of causing the program to abort as it should. Consequently, it
will continue to work with incorrect data instead[*]. Using this code
seems very unwise to me because of that.
[*] To add insult to injury, what caused this brainfart to be printed
was an attempt to get the type of the RR where a $ happened to be in
front of the method name because of a typo, ie, $rr->$type() instead
of $rr->type().
------------------------------
Date: Tue, 23 Oct 2012 15:50:52 -0700 (PDT)
From: johndelacour@gmail.com
Subject: Re: Why "Wide character in print"?
Message-Id: <7e37865d-5d6b-4401-9cf9-aa02fa0342eb@googlegroups.com>
On Sunday, September 30, 2012 6:57:38 PM UTC+1, tcgo wrote:
> #!/usr/bin/perl
> use utf8;
> my $cosa =3D "Here is my =E2=98=BA r=C3=A9s=C3=BAm=C3=A9 \x{2639}!";
> print "$cosa\n";
>=20
> And it gives me a "warning" message: "Wide character in print at
> ./unicode line 4". After adding "binmode(STDOUT, ":utf8");" the
> warning disappears, but why was it showing before of adding the
> binmode?
=E2=80=9Cuse utf8=E2=80=9D means only that the script file itself is UTF-8-=
encoded;
It doesn=E2=80=99t say how to manage the output to STDOUT.
JD
------------------------------
Date: Wed, 24 Oct 2012 00:54:24 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Why "Wide character in print"?
Message-Id: <ddd2b0b0-0651-473f-985f-e84d51ed27e5@googlegroups.com>
On Sunday, September 30, 2012 10:57:38 AM UTC-7, tcgo wrote:
> Hi!
>=20
> I just made a test code with Perl, using the Pi symbol with Unicode/UTF-8=
. That's the code:
>=20
>=20
>=20
> #!/usr/bin/perl
>=20
> use utf8;
>=20
> my $cosa =3D "Here is my =E2=98=BA r=C3=A9s=C3=BAm=C3=A9 \x{2639}!";
>=20
> print "$cosa\n";
> ...
>=20
Here's a follow-on with an observation/question for someone more knowledgea=
ble about Perl unicode)
I don't know how 'use locale' affects this but I
only see the OP's expected display of characters=20
by using the "\N{U+...}" notation to force character
semantics:
#use utf8;
my $cosa =3D "Here is my \N{U+263A} r=C3=A9s=C3=BAm=C3=A9 \N{U+03C0}!";
Output: Here is my =E2=98=BA r=C3=A9s=C3=BAm=C3=A9 =CF=80!
--=20
Charles DeRykus
------------------------------
Date: Wed, 24 Oct 2012 23:31:16 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: Re: Why "Wide character in print"?
Message-Id: <eli$1210241853@qz.little-neck.ny.us>
In comp.lang.perl.misc, tcgo <tomeuari@gmail.com> wrote:
> And it gives me a "warning" message: "Wide character in print at ./unicode line 4". After
> adding "binmode(STDOUT, ":utf8");" the warning disappears, but why was it showing before of
> adding the binmode?
The question has been answered in other follow-ups, but I'm kinda curious
how come this has not made it into the FAQ yet? Or maybe it has in a newer
perl, but:
$ grep -ci wide.character /usr/share/perl/5.14.2/pod/perlfaq*pod
/usr/share/perl/5.14.2/pod/perlfaq.pod:0
/usr/share/perl/5.14.2/pod/perlfaq1.pod:0
/usr/share/perl/5.14.2/pod/perlfaq2.pod:0
/usr/share/perl/5.14.2/pod/perlfaq3.pod:0
/usr/share/perl/5.14.2/pod/perlfaq4.pod:0
/usr/share/perl/5.14.2/pod/perlfaq5.pod:0
/usr/share/perl/5.14.2/pod/perlfaq6.pod:0
/usr/share/perl/5.14.2/pod/perlfaq7.pod:0
/usr/share/perl/5.14.2/pod/perlfaq8.pod:0
/usr/share/perl/5.14.2/pod/perlfaq9.pod:0
$
The explanation in perldiag is a good start:
=item Wide character in %s
(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 C<:utf8> layer to the
output, e.g. C<binmode STDOUT, ':utf8'>. Another way to turn off the
warning is to add C<no warnings 'utf8';> but that is often closer to
cheating. In general, you are supposed to explicitly mark the
filehandle with an encoding, see L<open> and L<perlfunc/binmode>.
For example:
=head2 Why is my code generating a "Wide character in <foo>" error?
You have tried to use a "wide character" (>255) when Perl was not
expecting one. Often what you want to do to is add the C<:utf8> layer to
the output, e.g. C<binmode STDOUT, ':utf8'>. Another way to turn off the
warning is to add C<no warnings 'utf8';> but that is often closer to
cheating. In general, you are supposed to explicitly mark the
filehandle with an encoding, see L<open> and L<perlfunc/binmode>.
But that (and the docs for binmode()) doesn't address why the warning will still
happen for ":raw" streams:
echo "some binary stream with U+2639 in it" | \
perl -we 'binmode(STDOUT, ":raw");
binmode(STDIN, ":raw");
while(<>) { s/U\+2639/\x{2639}/g; print } '
I've used the "while(<>) { s///g; print; }" construct to patch binary
files in the past (rename functions in compiled programs, etc). I haven't
yet needed to sub-in wide characters, but it doesn't seem unreasonable.
I'm guessing that my binary stream situation is what "no warnings 'utf8';"
is intended to fix.
Elijah
------
javascript functions, once renamed, are not accessible by normal websites
------------------------------
Date: Thu, 25 Oct 2012 03:15:12 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Why "Wide character in print"?
Message-Id: <gujml9-rhc.ln1@anubis.morrow.me.uk>
Quoth Eli the Bearded <*@eli.users.panix.com>:
> In comp.lang.perl.misc, tcgo <tomeuari@gmail.com> wrote:
> > And it gives me a "warning" message: "Wide character in print at
> ./unicode line 4". After
> > adding "binmode(STDOUT, ":utf8");" the warning disappears, but why was
> it showing before of
> > adding the binmode?
<snip>
>
> The explanation in perldiag is a good start:
>
> =item Wide character in %s
>
> (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 C<:utf8> layer to the
> output, e.g. C<binmode STDOUT, ':utf8'>. Another way to turn off the
> warning is to add C<no warnings 'utf8';> but that is often closer to
> cheating. In general, you are supposed to explicitly mark the
> filehandle with an encoding, see L<open> and L<perlfunc/binmode>.
<snip>
>
>
> But that (and the docs for binmode()) doesn't address why the warning
> will still
> happen for ":raw" streams:
>
> echo "some binary stream with U+2639 in it" | \
> perl -we 'binmode(STDOUT, ":raw");
> binmode(STDIN, ":raw");
> while(<>) { s/U\+2639/\x{2639}/g; print } '
[You should set $/ = \1024 or something else appropriate before using <>
on a binary file. By default <> reads newline-delimited lines, and there
is no particular reason for newlines to occur in sensible places in a
binary file. Of course, if the file is small enough it may be better to
read the whole thing and skip the while loop altogether.]
If you are dealing with :raw streams then your data needs to be in
bytes. That is, you should be using
use Encode "encode";
my $u2639 = encode "UTF-8", "\x{2639}";
s/U\+2639/$u2639/g;
Imagine you were trying to perform this replacement the other way
around; a substitution like
s/\x{2639}/U+2639/;
would never match, since the :raw layer would return a UTF8-encoded
U+2639 as three bytes. (It would also return a UTF-16 U+2639 as two
bytes, and a UCS-4 U+2639 as four bytes.) If you wanted it to match you
would need to use $u2639 defined as above, and deal with the possibility
of the character being split between chunks.
> I've used the "while(<>) { s///g; print; }" construct to patch binary
> files in the past (rename functions in compiled programs, etc). I haven't
> yet needed to sub-in wide characters, but it doesn't seem unreasonable.
A binary file cannot contain 'wide characters' as such, instead it
contains some *encoding* of wide characters. Since Perl has no way to
guess which encoding you want you need to be explicit, either by using
Encode directly or by calling it indirectly using PerlIO::encoding.
> I'm guessing that my binary stream situation is what "no warnings
> 'utf8';" is intended to fix.
No, not at all. If you review the (W utf8) warnings in perldiag, you
will see they all to do with performing character operations on Unicode
codepoints which are not valid characters (UTF-16 surrogates, codepoints
which haven't been allocated yet, explicit non-characters like U+FFFF).
They have nothing to do with ordinary Unicode IO.
Ben
------------------------------
Date: Thu, 25 Oct 2012 20:56:46 +0000 (UTC)
From: Eli the Bearded <*@eli.users.panix.com>
Subject: Re: Why "Wide character in print"?
Message-Id: <eli$1210251546@qz.little-neck.ny.us>
In comp.lang.perl.misc, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Eli the Bearded <*@eli.users.panix.com>:
> > But that (and the docs for binmode()) doesn't address why the warning
> > will still happen for ":raw" streams:
> >
> > echo "some binary stream with U+2639 in it" | \
> > perl -we 'binmode(STDOUT, ":raw");
> > binmode(STDIN, ":raw");
> > while(<>) { s/U\+2639/\x{2639}/g; print } '
>
> If you are dealing with :raw streams then your data needs to be in
> bytes. That is, you should be using
>
> use Encode "encode";
> my $u2639 = encode "UTF-8", "\x{2639}";
> s/U\+2639/$u2639/g;
Hmmmm. That looks awkward, but it does make sense. My example was all
about a UTF-8 string embeded in a file without a uniform encoding.
> > I've used the "while(<>) { s///g; print; }" construct to patch binary
> > files in the past (rename functions in compiled programs, etc). I haven't
> > yet needed to sub-in wide characters, but it doesn't seem unreasonable.
> A binary file cannot contain 'wide characters' as such, instead it
> contains some *encoding* of wide characters.
I'm not the one who introduced the term "wide characters" here, Perl's
warning did. Outside of this error message, "wide characters" means
UTF-16 or UTF-32 to my mind.
> > I'm guessing that my binary stream situation is what "no warnings
> > 'utf8';" is intended to fix.
>
> No, not at all. If you review the (W utf8) warnings in perldiag, you
> will see they all to do with performing character operations on Unicode
> codepoints which are not valid characters (UTF-16 surrogates, codepoints
> which haven't been allocated yet, explicit non-characters like U+FFFF).
> They have nothing to do with ordinary Unicode IO.
"Wide character in %s" is a "S utf8", not "W utf8" condition, and it is
not about "performing character operations on Unicode codepoints which are
not valid characters". It's a difficult error message for me to wrap my
head around what it *really* means, since perl is rather confusing about
how it handles character encodings. Anything character over ord(127) is
two or more bytes in UTF-8. What makes 255 special?
=item Wide character in %s
(S utf8) Perl met a wide character (>255) when it wasn't expecting one.
My command line is UTF-8:
$ echo 'å' | od -xc
0000000 a5c3 000a
303 245 \n
0000003
So why does this happen:
$ echo 'a' | perl -Mutf8 -wne 's/a/å/;print' | od -xc
0000000 0ae5
345 \n
0000002
And why is it different for these two cases:
$ echo 'a' | perl -mutf8 -wne 's/a/å/;print' | od -xc
0000000 a5c3 000a
303 245 \n
0000003
$ echo 'a' | perl -wne 'BEGIN{use utf8;} s/a/å/;print' | od -xc
0000000 a5c3 000a
303 245 \n
0000003
$ perl -v
This is perl 5, version 14, subversion 2 (v5.14.2) built for
x86_64-linux-gnu-thread-multi (with 53 registered patches, see perl -V
for more detail)
Elijah
------
the difference between -M and -m is very slight according to perlrun
------------------------------
Date: Fri, 26 Oct 2012 03:02:39 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Why "Wide character in print"?
Message-Id: <vi7pl9-ui71.ln1@anubis.morrow.me.uk>
Quoth Eli the Bearded <*@eli.users.panix.com>:
> In comp.lang.perl.misc, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth Eli the Bearded <*@eli.users.panix.com>:
<snip>
>
> > > I've used the "while(<>) { s///g; print; }" construct to patch binary
> > > files in the past (rename functions in compiled programs, etc). I haven't
> > > yet needed to sub-in wide characters, but it doesn't seem unreasonable.
> > A binary file cannot contain 'wide characters' as such, instead it
> > contains some *encoding* of wide characters.
>
> I'm not the one who introduced the term "wide characters" here, Perl's
> warning did. Outside of this error message, "wide characters" means
> UTF-16 or UTF-32 to my mind.
Well, that's four possible encodings right there; more if you include
UCS-2 and the various BOM options.
'Wide character', in this warning, means 'a character with ordinal
greater than 255' or alternatively 'a character which won't fit into a
single byte'.
> > > I'm guessing that my binary stream situation is what "no warnings
> > > 'utf8';" is intended to fix.
> >
> > No, not at all. If you review the (W utf8) warnings in perldiag, you
> > will see they all to do with performing character operations on Unicode
> > codepoints which are not valid characters (UTF-16 surrogates, codepoints
> > which haven't been allocated yet, explicit non-characters like U+FFFF).
> > They have nothing to do with ordinary Unicode IO.
>
> "Wide character in %s" is a "S utf8", not "W utf8" condition, and it is
> not about "performing character operations on Unicode codepoints which are
> not valid characters".
You're right; I missed that.
> It's a difficult error message for me to wrap my
> head around what it *really* means, since perl is rather confusing about
> how it handles character encodings. Anything character over ord(127) is
> two or more bytes in UTF-8. What makes 255 special?
You need to reread perlunicode and/or perlunitut. Basically, since perl
5.8, a string can contain one of two entirely different things:
- a sequence of Unicode characters, suitable for character
operations such as uc() and lc(), such that ord() returns a
Unicode codepoint (a 'character string');
- a sequence of uninterpreted bytes, suitable for binary operations
such as unpack(), such that ord() returns a byte value from 0 to
255 (a 'byte string').
It's up to the programmer to keep track of which of these two any given
string is supposed to represent; there have been a great many arguments
these past several years about whether or not this is a sensible model,
but it's the model we've got and we have to work with it.
Unix IO is defined in terms of strings of bytes. This means that any
string read from or written to a file must be a byte string: there is no
way to pass a 'byte' larger than 255 to write(2). Since Perl has no way
of knowing whether any given string was supposed to be a character
string or a byte string it can't enforce this; the best it can do is
warn if you pass it a string that was supposed to be bytes which
contains a value >255.
Since all IO occurs in terms of bytes, if you wish to read or write
characters you need to convert strings of bytes into strings of
characters and vice versa. This is the job of the Encode module, which
supports pretty-much every character encoding ('charset') you are likely
to need. The PerlIO :encoding layer is a shortcut which passes all reads
through Encode::decode and all writes through Encode::encode; it's
useful when you know all IO on a particular filehandle should use a
particular encoding. If you want to mix encodings, or deal with a
mixture of binary and encoded-text data, you need to handle the encoding
and decoding yourself.
> My command line is UTF-8:
No, your *terminal* uses UTF-8, and possibly your shell. The command
line passed to executed programs is a list of strings of bytes, because
that's how execve(2) is defined. This is an important distinction,
because what perl sees initially is bytes, and if you want it to convert
them to characters you have to ask.
> $ echo 'å' | od -xc
> 0000000 a5c3 000a
> 303 245 \n
> 0000003
The command-line passed to 'echo' (ignoring for the moment the fact that
it's probably a builtin) looked like this:
65 63 68 6f 00 a5 c3 00 00
e c h o å
echo copied those two bytes to stdout, completely unaware they were
supposed to represent a single character, and added a byte of 0a. od,
similarly, read three bytes from stdin and printed out a representation
of them, again unaware that they were supposed to represent two
characters.
> So why does this happen:
>
> $ echo 'a' | perl -Mutf8 -wne 's/a/å/;print' | od -xc
> 0000000 0ae5
> 345 \n
> 0000002
'use utf8' tells Perl that the script it is running, whether it is from
-e or a file, should be decoded to characters using the UTF-8 encoding
before being passed to the Perl lexer. (In theory you can 'use encoding'
to specify a different source character encoding, but in practice that
pragma has always been buggy and is better avoided.)
[I'm going to look at this invocation, since it's a little easier to
explain
perl -Mutf8 -E'say "å"' | od -xc
but the output is exactly the same. Assume the equivalent substitutions
below.]
In this case, the complete command line passed to perl looks like
70 65 72 6c 00 2d 4d 75 74 66 38 00 2d 45 73 61 79 20 22 c3 a5 22 00 00
p e r l - M u t f 8 - E s a y " å "
The perl command-line handling code executes 'use utf8;' when it sees
the -M option, 'use feature ':5.14';' when it sees -E, then passes
73 61 79 20 22 c3 a5 22
s a y " å "
to the input-handling code. The 'use utf8' has installed a filter which
converts bytes to characters using UTF-8, so this gets translated to
0073 0061 0079 0020 0022 00e5 0022
s a y " å "
before being passed to the lexer. (I've written these with 4-digit
ordinals since they're now nominally Unicode codepoints, but as far as
perl is concerned there is no difference. In particular, notice that
they all still fit into a single byte.) The lexer converts the "å" into
a 1-character string which eventually gets passed to 'say', which
appends a newline (that is, a character with ordinal 0a) and passes it
to the STDOUT filehandle for writing.
Since this filehandle has no translation PerlIO layers on it, it assumes
that strings sent to it for writing are *byte* strings. This means that
it writes two bytes, e5 0a, to stdout. (The -x option to od then
reverses them, but that's just little-endian stupidity. -tx1 is usually
better.)
> And why is it different for these two cases:
>
> $ echo 'a' | perl -mutf8 -wne 's/a/å/;print' | od -xc
> 0000000 a5c3 000a
> 303 245 \n
> 0000003
-mutf8 is equivalent to 'use utf8 ()', which does precisely nothing
(well, it loads a little code into the utf8:: namespace, but it
*doesn't* affect the source encoding). This means the convert-from-UTF-8
step above is skipped, so say gets passed the 2-character string c3 a5.
Again it appends an 0a, and sends it to STDOUT; this time, the output is
three bytes.
> $ echo 'a' | perl -wne 'BEGIN{use utf8;} s/a/å/;print' | od -xc
> 0000000 a5c3 000a
> 303 245 \n
> 0000003
The effect of 'use utf8', like 'strict' and 'warnings', is lexically
scoped. In this case the effect lasts until the end of the BEGIN block,
so the rest of the code is entirely unaffected.
> the difference between -M and -m is very slight according to perlrun
It's exactly the difference between
use Foo;
and
use Foo ();
unless you include parameters (-mfoo=bar) in which case it is identical
to -M. That is: -m will not call the ->import method.
Ben
------------------------------
Date: Tue, 23 Oct 2012 23:29:34 GMT
From: Andrew Gideon <c182driver9@gideon.org>
Subject: Re: Why was suid support dropped in perl?
Message-Id: <yLFhs.17298$Xc6.3636@fed05.iad>
On Sat, 20 Oct 2012 09:59:11 -0700, shrike@cyberspace.org wrote:
> It turns out I have run into such a problem: running a driver written in
> perl on a remote host via SSH.
Why not permit SSH to root using a key pair with a command restriction?
Since the command runs as root, there's no su-ing required.
This does have the risks associated with the program itself running as
root, but you'd have those anyway, right?
- Andrewq
------------------------------
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 3802
***************************************
