[32552] in Perl-Users-Digest
Perl-Users Digest, Issue: 3818 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Nov 13 14:09:25 2012
Date: Tue, 13 Nov 2012 11:09:08 -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, 13 Nov 2012 Volume: 11 Number: 3818
Today's topics:
Re: CGI NET::SSH browser problem <justin.1211@purestblue.com>
Re: IO::Socket::INET hostname restrictions? <ben@morrow.me.uk>
Re: Is Perl dying or not? <cwilbur@chromatico.net>
Re: lerning perl <cartercc@gmail.com>
Re: lerning perl <cartercc@gmail.com>
Re: Net::IDN::Encode Build procedure in external dir.? <ben@morrow.me.uk>
Re: Net::IDN::Encode Build procedure in external dir.? <tuxedo@mailinator.com>
static variable problem <dave@invalid.invalid>
Static variable problem <dave@invalid.invalid>
Re: static variable problem <rweikusat@mssgmbh.com>
Re: static variable problem <ben@morrow.me.uk>
Re: static variable problem <rweikusat@mssgmbh.com>
Re: Why "Wide character in print"? <ben@morrow.me.uk>
Re: Why "Wide character in print"? <whynot@pozharski.name>
Re: Why "Wide character in print"? <hjp-usenet2@hjp.at>
Re: Why "Wide character in print"? <whynot@pozharski.name>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 12 Nov 2012 10:04:21 +0000
From: Justin C <justin.1211@purestblue.com>
Subject: Re: CGI NET::SSH browser problem
Message-Id: <56u6n9-tta.ln1@zem.masonsmusic.co.uk>
On 2012-11-10, karraso <gkrasinski@gmail.com> wrote:
> Hello,
> It is my first post to this group, any way.
> I wrote script in perl and it is working fine with cmdline, but in cgi it doesn't.
> The browser doesn't print any outputs.
> ###################################################
**ALWAYS**
use warnings;
use strict;
and let Perl help you.
> open(wynik, ">plik.txt");
Always test whether your 'open' command succeeds:
my $filename = 'plik.txt';
open my $FILEHANDLE, ">", $filename or die "Cannot open $filename: $!";
> use Net::SSH qw(sshopen2);
>
> $user = "user";
> $host = "host";
> $cmd = "/bin/bash";
my ($user, $host, $cmd) = ('user', 'host', '/bin/bash');
> @commands = ('ls -l');
my @commands...
Have you checked the server logs? My guess at the reason it's not
working is that you've not given a password, which you've probably done
because you have pre-shared keys set up. But the web-server, which is
the 'user' that runs your program, does not likely run as you and
therefore does not use your pre-shared key. I think you need
authentication of some kind in your program.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Sun, 11 Nov 2012 22:14:02 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: IO::Socket::INET hostname restrictions?
Message-Id: <aik5n9-anf1.ln1@anubis.morrow.me.uk>
Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <j5eas8-8dd.ln1@anubis.morrow.me.uk>, on 12/22/2011
> at 01:36 AM, Ben Morrow <ben@morrow.me.uk> said:
>
> >Now I've got confirmation this works properly I'll submit a bug
> >report (when I get to it...). I'm afraid I don't know if or when
> >this'll make its way into a release.
>
> Have you submitted a bug report on this? If not, should I submit one
> and cite this thread, noting that your patch worked, at least in OS/2?
> Thanks.
Ack, no I haven't, sorry. It just kept slipping down my list of things
to do... (I was intending to properly test the patch on several
platforms before submitting it.)
Yes, you should probably submit one yourself. <perlbug@perl.org>.
Ben
------------------------------
Date: Mon, 12 Nov 2012 19:46:22 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Is Perl dying or not?
Message-Id: <87625a5nz5.fsf@new.chromatico.net>
>>>>> "cc" == ccc31807 <cartercc@gmail.com> writes:
cc> Randal, I keep my finger on the pulse of the job market, and all
cc> I see are jobs in .NET, Java jobs, and a goodly number of Python
cc> and PHP jobs. Perl jobs seem to be mostly six month contracts. I
cc> trust that you know what you're talking about, but I don't see
cc> it, probably because I don't have your connections. If one were
cc> to look for Perl jobs, where do you suggest that one start?
YAPC::NA. I thought Asheville in 2011 was insane with the number of
people hiring. And then in Madison in 2012, I realized it could be MORE
insane.
(To be honest, one of the reasons that in my perception Perl is thriving
but it's still damn hard to find a Perl job is that Perl, and especially
CPAN,are extremely powerful levers that can even be applied to
themselves. If there's a common problem pattern in Java, often the best
that can be hoped for is some scaffolding and template code to be added
to Eclipse, and as there's no CPAN-equivalent, most developers who run
into that problem wind up solving it again. With Perl, it's very likely
that such a problem will be solved a couple times badly by people
feeling their way around it, and then someone smart solves it well and
shares the solution - either internally to his or her colleagues at that
company, or on CPAN for the entire world to benefit.)
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Mon, 12 Nov 2012 08:27:30 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: lerning perl
Message-Id: <568dfe26-c412-4c5c-87d5-578ecbb26e0f@m4g2000yqb.googlegroups.com>
On Nov 9, 11:18=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> I'm sure you won't like me saying this, and it is certainly *not*
> directed at anyone in particular, but there are far too many bad
> programmers in the world and they do far more damage than they realise.
> The entire PHP ecosystem (language, interpreter, libraries, the lot) is
> a scary example of the way code written by people who really had no
> business writing code can end up being used for important and security-
> sensitive applications. (Many of the CGI scripts written in Perl and
> copied from one site to another before PHP came along were an earlier
> example.)
I don't object to this at all, and would subscribe to it. My point
was, to use an analogy, that while there might be a huge difference
between a master stone mason and a bricklayer in making a work of art,
you don't need a master mason to build a brick wall -- a bricklayer
will do just as good a job and maybe a better job BECAUSE he might
have a strong back but a weak mind.
To put it another way, 'People' and 'Cosmopolitan' and 'Playboy' sell
a lot more product than ACM or IEEE SIGS, even though you can call
contributors to both kinds 'writers.' You don't need advanced literary
skill or heightened aesthetic to write for 'People' et al, but that
doesn't mean that you don't serve a useful function in the writing
ecosystem.
Your point is that those with limited abilities should not do language
design, but that's a different issue. I fully agree with you here.
CC.
------------------------------
Date: Mon, 12 Nov 2012 08:36:11 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: lerning perl
Message-Id: <ff30f696-90bd-4f07-a59a-39cc75714404@o8g2000yqh.googlegroups.com>
On Nov 11, 7:39=A0am, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> There are really bad programmers, you can write code, but it's buggy and
> clumsy and they take a long time to solve even simple problems.
Maybe one of the things I had in the back of my mind was the
difference between professionals and amateurs. The word 'amateur' is
Latin, and refers to someone who does something out of love for it. A
professional is a mercenary who does something simply for the money.
There are plenty of bad musicians, or golfers, who make music or play
golf because they love to do it -- and there are also professional
musicians and golfers.
Unfortunately, we all know the difference between bad musicians and
golfers who do it out of love, and those that are really good.
Customers and employers don't (or can't) make the same distinction
with programmers.
> And there's the geniuses who whip out complex, non-trivial software
> systems over the weekend, with few bugs and elegant solutions.
Absolutely! And this is another critical problem. We as a
technological/managerial culture have a decided preference for ten
code monkeys over one brilliant genius, even though one brilliant
genius might produce more than a hundred code monkeys.
CC.
------------------------------
Date: Sun, 11 Nov 2012 22:21:31 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Net::IDN::Encode Build procedure in external dir.?
Message-Id: <b0l5n9-anf1.ln1@anubis.morrow.me.uk>
Quoth Tuxedo <tuxedo@mailinator.com>:
> The Net::IDN::Encode module converts IDN domains into ASCII and vice versa:
> http://search.cpan.org/~cfaerber/Net-IDN-Encode-2.003/lib/Net/IDN/Encode.pm
>
> The documented build procedure is:
> perl Build.PL
> ./Build
> ./Build test
> ./Build install
>
> However, I'm not sure how to install this particular module in an non-root
> owned directory, if at all possible. My installation procedure for modules
> on typical Unix and Linux systems usually include a PREFIX argument, as in:
> perl Makefile.PL PREFIX=/some/external/directory
>
> As noted in Net::IDN::Encode's README at
> http://cpansearch.perl.org/src/CFAERBER/Net-IDN-Encode-2.003/README the
> module depends on Unicode::Stringprep, which has the same build procedure:
> http://search.cpan.org/dist/Unicode-Stringprep/
>
> Without quite expecting it to work, I tried: ...
> perl Build.PL PREFIX=/some/external/directory
> ... but PREFIX is obviously unrecognised here, so for both modules the
> installation failed at the last 'Build install' step with an expected
> permission error:
> ERROR: Can't create '/usr/lib/perl5/site_perl/5.14.2/Unicode'
> mkdir /usr/lib/perl5/site_perl/5.14.2/Unicode: Permission denied at
> /usr/lib/perl5/5.14.2/ExtUtils/Install.pm line 494
>
> While I can usually install as root that is not always the case, so I
> prefer to place most non-core modules in non-root directories.
For Build.PL the argument is '--install_base /some/dir'; see the
Module::Build documentation. Note that this won't always install things
in quite the same place as MakeMaker's PREFIX parameter, since PREFIX is
a little weird; in fact, MakeMaker's documentation currently recommends
using INSTALL_BASE instead of PREFIX, which matches Module::Build's
--install_base and is more predictable than PREFIX.
If you are maintaining a repository of modules under your home
directory, you may also want to look at the local::lib module, which
will help you set up your environment so modules are installed to and
loaded from there automatically. This also means you can use a CPAN
client to install modules with their dependencies automatically; cpanm
(on CPAN as App::cpanminus) has explicit support for installing into a
local::lib-managed directory.
Ben
------------------------------
Date: Mon, 12 Nov 2012 20:13:05 +0100
From: Tuxedo <tuxedo@mailinator.com>
Subject: Re: Net::IDN::Encode Build procedure in external dir.?
Message-Id: <k7rho4$ubp$1@news.albasani.net>
Ben Morrow wrote:
>
> Quoth Tuxedo <tuxedo@mailinator.com>:
> > The Net::IDN::Encode module converts IDN domains into ASCII and vice
> > versa:
> >
http://search.cpan.org/~cfaerber/Net-IDN-Encode-2.003/lib/Net/IDN/Encode.pm
> >
> > The documented build procedure is:
> > perl Build.PL
> > ./Build
> > ./Build test
> > ./Build install
> >
> > However, I'm not sure how to install this particular module in an
> > non-root owned directory, if at all possible. My installation procedure
> > for modules on typical Unix and Linux systems usually include a PREFIX
> > argument, as in: perl Makefile.PL PREFIX=/some/external/directory
> >
> > As noted in Net::IDN::Encode's README at
> > http://cpansearch.perl.org/src/CFAERBER/Net-IDN-Encode-2.003/README the
> > module depends on Unicode::Stringprep, which has the same build
> > procedure: http://search.cpan.org/dist/Unicode-Stringprep/
> >
> > Without quite expecting it to work, I tried: ...
> > perl Build.PL PREFIX=/some/external/directory
> > ... but PREFIX is obviously unrecognised here, so for both modules the
> > installation failed at the last 'Build install' step with an expected
> > permission error:
> > ERROR: Can't create '/usr/lib/perl5/site_perl/5.14.2/Unicode'
> > mkdir /usr/lib/perl5/site_perl/5.14.2/Unicode: Permission denied at
> > /usr/lib/perl5/5.14.2/ExtUtils/Install.pm line 494
> >
> > While I can usually install as root that is not always the case, so I
> > prefer to place most non-core modules in non-root directories.
>
> For Build.PL the argument is '--install_base /some/dir'; see the
> Module::Build documentation. Note that this won't always install things
> in quite the same place as MakeMaker's PREFIX parameter, since PREFIX is
> a little weird; in fact, MakeMaker's documentation currently recommends
> using INSTALL_BASE instead of PREFIX, which matches Module::Build's
> --install_base and is more predictable than PREFIX.
>
> If you are maintaining a repository of modules under your home
> directory, you may also want to look at the local::lib module, which
> will help you set up your environment so modules are installed to and
> loaded from there automatically. This also means you can use a CPAN
> client to install modules with their dependencies automatically; cpanm
> (on CPAN as App::cpanminus) has explicit support for installing into a
> local::lib-managed directory.
>
> Ben
>
Installing by Build.PL --install_base flag works perfectly and so does the
methods offered by Net::IDN::Encode to convert IDN strings to/from ASCII.
I will bear the module management techniques in mind for future use.
Thank you for the clear and detailed explanation!
Tuxedo
------------------------------
Date: Tue, 13 Nov 2012 13:38:07 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: static variable problem
Message-Id: <fV45K0OBJxbE-pn2-l0DOsOblSoed@localhost>
Please why does this throw an error?
[T:\tmp]cat try.pl
use strict;
use warnings;
foo("Hello World");
exit;
{
my $bar = 1;
sub foo
{
my $a = shift;
print "$bar $a\n"; # <== line 12
return;
}
}
[T:\tmp]try.pl
Use of uninitialized value in concatenation (.) or string at try.pl
line 12.
Hello World
So $bar is private to foo - but you can't initialise it?
TIA
--
Regards
Dave Saville
------------------------------
Date: Tue, 13 Nov 2012 15:15:21 +0000 (UTC)
From: "Dave Saville" <dave@invalid.invalid>
Subject: Static variable problem
Message-Id: <fV45K0OBJxbE-pn2-h93YGr77Rel7@localhost>
Apologies if this appears twice but I have not seen it and my sent
posts folder does not have a copy - but I would swear I hit send :-)
Please can someone explain why the following throws an error?
[T:\tmp]cat try.pl
use strict;
use warnings;
foo("Hello World");
exit;
{
my $bar = 1;
sub foo
{
my $a = shift;
print "$bar $a\n"; <== line 12
return;
}
}
[T:\tmp]try.pl
Use of uninitialized value in concatenation (.) or string at try.pl
line 12.
Hello World
$bar is private to foo - yes? So you can't initialize it?
--
Regards
Dave Saville
------------------------------
Date: Tue, 13 Nov 2012 14:28:18 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: static variable problem
Message-Id: <87obj1shkt.fsf@sapphire.mobileactivedefense.com>
"Dave Saville" <dave@invalid.invalid> writes:
> Please why does this throw an error?
>
> [T:\tmp]cat try.pl
> use strict;
> use warnings;
>
> foo("Hello World");
> exit;
> {
> my $bar = 1;
>
> sub foo
> {
> my $a = shift;
> print "$bar $a\n"; # <== line 12
> return;
> }
> }
>
> [T:\tmp]try.pl
> Use of uninitialized value in concatenation (.) or string at try.pl
> line 12.
> Hello World
Because $bar = 1 is never executed: The compiler compiles this, then
the program invokes the foo subroutine and exits before the $bar = 1.
You can move the foo("Hello World") below the block or use BEGIN or
INIT to ensure that $bar is actually initialized:
----------
use strict;
use warnings;
foo("Hello World");
exit;
{
my $bar;
INIT {
$bar = 1;
}
sub foo
{
my $a = shift;
print "$bar $a\n"; # <== line 12
return;
}
}
------------------------------
Date: Tue, 13 Nov 2012 14:45:03 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: static variable problem
Message-Id: <f03an9-bup2.ln1@anubis.morrow.me.uk>
Quoth "Dave Saville" <dave@invalid.invalid>:
> Please why does this throw an error?
>
> [T:\tmp]cat try.pl
> use strict;
> use warnings;
>
> foo("Hello World");
> exit;
> {
> my $bar = 1;
>
> sub foo
> {
> my $a = shift;
> print "$bar $a\n"; # <== line 12
> return;
> }
> }
>
> [T:\tmp]try.pl
> Use of uninitialized value in concatenation (.) or string at try.pl
> line 12.
This is not an error, it is a warning.
> Hello World
>
> So $bar is private to foo - but you can't initialise it?
You call foo() before $bar is initialised. Move the call after the block
and it will do what you expect.
Ben
------------------------------
Date: Tue, 13 Nov 2012 19:01:21 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: static variable problem
Message-Id: <87pq3hqqda.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> "Dave Saville" <dave@invalid.invalid> writes:
>> Please why does this throw an error?
>>
>> [T:\tmp]cat try.pl
>> use strict;
>> use warnings;
>>
>> foo("Hello World");
>> exit;
>> {
>> my $bar = 1;
>>
>> sub foo
>> {
>> my $a = shift;
>> print "$bar $a\n"; # <== line 12
>> return;
>> }
>> }
>>
>> [T:\tmp]try.pl
>> Use of uninitialized value in concatenation (.) or string at try.pl
>> line 12.
>> Hello World
>
> Because $bar = 1 is never executed: The compiler compiles this, then
> the program invokes the foo subroutine and exits before the $bar =
> 1.
Additional explanation: Generally, running a Perl program is comprised
of two phases: A compilation step where the Perl compiler reads all
the source code files and transforms the code into some internal
representation (AFAIK called 'an optree') and an execution phase where
the Perl interpreter evaluates/ executes this 'optree'. This means any
statement in a Perl program may have run time or compile time effects
or both and the run time effects aren't visible during compile
time. For this example, this means the compiler creates a compiled
subroutine 'foo' which refers to the $bar defined in the outer block
because 'creating my variables' has the compile-time effect of making
the corresponding names visible to the compiler (so that it can
generated code accessing the proper objects). But the assignment to
$bar does not happen at compile-time, it happens at run-time when the
corresponding statement is executed. An execution of the 'content' of
a file is top-to-bottom: By the time the foo("...:") is executed, a
subroutine referencing the proper $bar has been created but the value
of $bar hasn't yet been set.
So-called 'BEGIN block' can be used to execute Perl code at
compile-time and alternatively, so-called 'INIT blocks' can be used to
run Perl code after the compilation phase has finished and before any
of the 'general' code ran (details are in the perlmod manpage).
------------------------------
Date: Sun, 11 Nov 2012 23:07:03 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Why "Wide character in print"?
Message-Id: <nln5n9-39g1.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2012-11-06 23:26, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> >> The main problem I have with UTF-16 is of a psychological nature: It is
> >> extremely tempting to assume that it's a constant-width encoding because
> >> "nobody uses those funky characters above U+FFFF anyway". Basically the
> >> "all the world uses US-ASCII" trap reloaded.
> >
> > The main problem *I* have is the fact the surrogates are allocated out
> > of the Unicode character space, so everyone doing anything with Unicode
> > has to take account of them, even if they won't ever be touching UTF-16
> > data. UTF-8 doesn't do that: it has magic bits indicating the
> > variable-length sections, but they are kept away from the data bits
> > representing the actual characters encoded.
> >
> > The same could have been done with UTF-16. If I'm reading the charts
> > right, Unicode 1.1.5 (the last version before the change) allocated
> > characters from 0000-9FA5 and from F900-FFFF, which leaves Axxx-Exxx
> > free to represent multi-word characters. So, for instance, they could
> > have used the following scheme: A word matching one of
> >
> > 0xxxxxxxxxxxxxxx
> > 1001xxxxxxxxxxxx
> > 1111xxxxxxxxxxxx
> >
> > is a single-word character. Other characters are represented as two
> > words, encoded as
> >
> > 101ppppphhhhhhhh 110pppppllllllll
> >
> > which represents the 26-bit character
> >
> > pppppppppphhhhhhhhllllllll
>
> That takes a huge chunk (25%, or even 37.5% if you include the ranges
> which you have omitted above) out of the BMP. These codepoints would
> either not be assigned at all (same as with UTF-16) or have to be
> represented as four bytes.
Obviously I meant the latter. My whole point is that the Unicode
character list should not contain references to any particular encoding
scheme.
> > but IMHO reducing that to 26 would have been a lesser evil than
> > stuffing a whole lot of encoding rubbish into the application- visible
> > character set.
>
> The only thing that's visible in the character set is that there is a
> chunk of 2048 reserved code points which will never be assigned. How is
> that different from other chunks of unassigned code points which may or
> may not be assigned in the future?
Surrogates in decoded Unicode text have to be handled differently from
other currently-unassigned characters. A program which processes
arbitrary Unicode text can reasonably pass through unrecognised
characters, on the grounds that the sender may be using a more recent
version of Unicode, but surrogates should always signal an error and so
have to be explicitly checked for. For instance, a grep for 'surrogate'
in the perl source reveals a whole lot of code for checking for and
warning about surrogates, which simply shouldn't have been necessary.
Ben
------------------------------
Date: Mon, 12 Nov 2012 18:58:04 +0200
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Why "Wide character in print"?
Message-Id: <slrnka2aks.bmm.whynot@orphan.zombinet>
with <slrnk9v4nu.6j5.hjp-usenet2@hrunkner.hjp.at> Peter J. Holzer wrote:
> On 2012-11-06 19:19, Eric Pozharski <whynot@pozharski.name> wrote:
*SKIP*
>> As of your explanation. It's not precise. encoding.pm does what it
>> always does. It doesn't mangle scalars itself, it *hints* Encode.pm
>> (and friends) for decoding from encoding specified to utf8. (How
>> Encode.pm comes into play is beyond my understanding for now.)
> Maybe you should be less confident about stuff which is beyond your
> understanding.
Here's the deal. Explain me what's complicated in this:
[quote encoding.pm on]
[producing $enc and $name goes above]
unless ( $arg{Filter} ) {
DEBUG and warn "_exception($name) = ", _exception($name);
_exception($name) or ${^ENCODING} = $enc;
$HAS_PERLIO or return 1;
}
[dealing wit Filter option and STDIN/STDOUT goes below]
[quote encoding.pm off]
and I grant you and Ben unlimited right to spread FUD on encoding.pm
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Mon, 12 Nov 2012 22:30:03 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Why "Wide character in print"?
Message-Id: <slrnka2qir.5cu.hjp-usenet2@hrunkner.hjp.at>
On 2012-11-12 16:58, Eric Pozharski <whynot@pozharski.name> wrote:
> with <slrnk9v4nu.6j5.hjp-usenet2@hrunkner.hjp.at> Peter J. Holzer wrote:
>> On 2012-11-06 19:19, Eric Pozharski <whynot@pozharski.name> wrote:
>>> As of your explanation. It's not precise. encoding.pm does what it
>>> always does. It doesn't mangle scalars itself, it *hints* Encode.pm
>>> (and friends) for decoding from encoding specified to utf8. (How
>>> Encode.pm comes into play is beyond my understanding for now.)
>> Maybe you should be less confident about stuff which is beyond your
>> understanding.
>
> Here's the deal. Explain me what's complicated in this:
>
> [quote encoding.pm on]
> [producing $enc and $name goes above]
> unless ( $arg{Filter} ) {
> DEBUG and warn "_exception($name) = ", _exception($name);
> _exception($name) or ${^ENCODING} = $enc;
> $HAS_PERLIO or return 1;
> }
> [dealing wit Filter option and STDIN/STDOUT goes below]
> [quote encoding.pm off]
So after reading 400 lines of perldoc encoding (presumably not for the
first time) and a rather long discussion thread you are starting to read
the source code to find out what “use encoding” does?
I think you are proving my point that “use encoding” is too complicated
rather nicely.
You will have to read the source code of perl, however. AFAICS
encoding.pm is just a frontend which sets up stuff for the parser to
use. I'm not going to follow you there - the perl parser has too many
tentacles for my taste.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Tue, 13 Nov 2012 09:09:46 +0200
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: Why "Wide character in print"?
Message-Id: <slrnka3shq.7js.whynot@orphan.zombinet>
with <slrnka2qir.5cu.hjp-usenet2@hrunkner.hjp.at> Peter J. Holzer wrote:
*SKIP*
> I'm not going to follow you there - the perl parser has too many
> tentacles for my taste.
I don't feel any better. Pity.
--
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 3818
***************************************
