[31115] in Perl-Users-Digest
Perl-Users Digest, Issue: 2360 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 22 18:09:41 2009
Date: Wed, 22 Apr 2009 15: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 Wed, 22 Apr 2009 Volume: 11 Number: 2360
Today's topics:
Re: F<utf8.pm> is evil (was: XML::LibXML UTF-8 toString <hjp-usenet2@hjp.at>
Re: Is there a better way to convert foreign characters <jurgenex@hotmail.com>
Re: Is there a better way to convert foreign characters <nospam-abuse@ilyaz.org>
Re: Is there a module to transliterate Russian and Ukra <benkasminbullock@gmail.com>
Re: Perl Opportunity <nat.k@gm.ml>
Re: Perl Opportunity <tadmc@seesig.invalid>
Re: Perl Opportunity <nat.k@gm.ml>
Re: split-like thing <smallpond@juno.com>
sudo perl script with environment variables on linux <wong_powah@yahoo.ca>
Re: sudo perl script with environment variables on linu <smallpond@juno.com>
Re: sudo perl script with environment variables on linu <nat.k@gm.ml>
Re: sudo perl script with environment variables on linu <smallpond@juno.com>
Re: sudo perl script with environment variables on linu <nat.k@gm.ml>
Re: sudo perl script with environment variables on linu <smallpond@juno.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 22 Apr 2009 12:58:42 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: F<utf8.pm> is evil (was: XML::LibXML UTF-8 toString() -vs- nodeValue())
Message-Id: <slrngutu33.ji6.hjp-usenet2@hrunkner.hjp.at>
On 2009-04-22 00:32, Eric Pozharski <whynot@pozharski.name> wrote:
> On 2009-04-20, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>> On 2009-04-17 00:23, Eric Pozharski <whynot@pozharski.name> wrote:
>>> On 2009-04-15, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>>>> On 2009-04-14 23:45, Eric Pozharski <whynot@pozharski.name> wrote:
> *SKIP*
>>> I'm puzzled. However, I should admit, that I've yet found those dark
>>> corners of C<use encoding 'utf8';>.
>>
>> I found quite a few of them, but that was in the early times of 5.8.x,
>> so some of them may have been bugs which have since been fixed and some
>> of them may have been caused by my lack of understanding how the (at the
>> time) new "utf8" strings were supposed to work. However, I think that
>> Encoding.pm (the module itself and its documentation) added
>> significantly to my confusion instead of lessening it. It took me some
>> time to figure things out.
>>
>> But a couple of points which immediatly come to mind while scrolling
>> through perldoc encoding:
[...]
>
>> * utf8::upgrade and utf8::downgrade aren't symmetric.
>
> I've noted, but... F<encoding.pm> is wrong exactly how?
It isn't "wrong". It is documented. But it is surprising and illogical
behaviour. A source of subtle bugs because the programmer most likely
won't think of that. And I think encoding.pm is full of such crannies. I
learned to avoid it pretty quickly.
> *SKIP*
>>> I fail to see how utfizing both literals and symbols makes F<utf8.pm>
>>> doing one thing. I don't say that it doesn't do it well.
>>
>> It doesn't utf8ize "both literals and symbols", it simply reads the
>> complete source text in character mode (with :encoding(utf8)). A very
>> simple operation, and everything else is a logical consequence from
>> that. So "\x{D0}\x{BF}" is still a string of 2 bytes (because it
>> reads "double-quote backslash open-brace capital D 0
>> closed-brace backslash ..." and that parses to two bytes by the normal
>> perl parsing rules, but "п" parses as one character because that reads
>> "double-quote cyrillic-small-letter-pe double-quote". And a variable $п
>> is allowed because п is a letter and Perl allows letters, digits and the
>> underscore in variable names. No surprises there.
>
> So F<utf8.pm> utfizes symbols by accident. At least that wasn't an
> intention.
I'm not sure what you mean by "utfize", but if you mean: "Symbols can
contain all Unicode letters and digits, not just A-Z, a-z, 0-9", then
that's quite intentional, not an accident. But it is a logical
consequence of interpreting the source code as a sequence of Unicode
characters instead of a sequence of ASCII characters. So, as a
programmer you don't have to remember that "use utf8" decodes string
constants from UTF-8 *and* that it allows all Unicode letters and digits
in symbols *and* that the DATA stream has an ':encoding(utf8)' layer
*and* whatever else may be affected. You have to remember one thing
only: Your source code consists of Unicode characters encoded in UTF-8
(or UTF-EBCDIC). Period. Nothing else. Clean and simple.
> *SKIP*
>>> So you suggest that localizing Perl (or actually any other language) is
>>> kind of online dictionary providers conspiracy?
>>
>> No, not at all. What I am saying is that people will use localized
>> variable and subroutine names, and write comments in their native
>> language, no matter if the programming language makes it easy or not.
>> Sometimes this is because they don't speak English too well, sometimes
>> it's because the problem domain is language-specific (for example, when
>
> Then they must. I don't say "should". I'm unaware of any other
> language that nicely fits in 7bit. Calling it "US-ASCII" is pure accident.
You are contradicting yourself. First you say that English is the only
language that fits nicely into US-ASCII, then you say that US-ASCII is
called US-ASCII by accident. It isn't. US-ASCII was developed by an
American institute to write English texts. It is no accident at all that
it only contains characters which are frequently used in English
(technical) texts. And it is no accident that it is called ASCII -
"American Standard Code for Information Interchange". The US- in front
is somewhat redundant, but there were a lot variants of ASCII (e.g., the
ISO-646 encodings), so that serves as a reminder that this is indeed the
orginal American version of the American code.
> That seemingly contradicts my point of having an option. Yes, but there
> must be something common for all. By an accident -- it's English.
Yes. English. Not ASCII. If you write Russian in ASCII I understand it
just as little than if you write in in Cyrillic.
If you can write your programs in English, please do. Especially if you
plan to make it open source. Almost every programmer on the world has at
least a basic grasp of English. But if for some reason you have to write
in Russian, then I think you should use the Cyrillic alphabet, not the
Latin alphabet. That will make it easier for those who understand
Russian and even for those who don't (because then at least they can
paste the stuff into an online dictionary and get a translation).
>> I was a teaching assistant at the university, we often wrote programs to
>> help in some administrative task - students here are identified by a
>> "Matrikelnummer". According to the dictionary, that's "enrollment
>> number" in English, but it simply didn't make sense to use a variable
>> $enrollment_number, because *nobody* who had to maintain that program
>> would know what an "enrollment number" is, but everybody would know what
>> $matrikelnummer means (you simply can't study or work at an Austrian
>> university without knowing that)). Now, using German variable names is
>> simple: We use only 7 non-ASCII letters, and there are standardized and
>> well-known transliterations for all of them. So it isn't a great
>> inconvenience if we need to write $uebung instead of $übung. But in
>> Russian (or Greek, or Japanese, or Hindi, ...) the entire Alphabet is
>> non-ASCII, and there are usually many transliteration systems. So if a
>> Russian (or Greek, or Japanese, or Indian, ...) programmer wants to use
>> some word from their native tongue, they need to choose one
>> transliteration which is not natural to them and may be almost
>> unreadable for the next programmer who has to maintain it.
>
> So you have no real experience with alphabetical mix.
No, for several reasons:
* I only speak German and English. Both use the Latin alphabet.
(German uses a handful of extra letters)
* Most open source software is in English, and our own software is in
English, too.
* Until a few years ago, most programming languages were US-ASCII only
(I think Java was the first popular programming language which
defined a larger source character set, except for specialized
languages like APL - that was in 1996).
> My point isn't language mix; I have no problem with this.
I have. A program where all the identifiers, comments etc. are written
in Portugese or Polish is hard to figure out if you don't speak the
language. That they use the latin alphabet doesn't help much (except
that I have an inuitive (though very probably wrong) idea how to
pronounce them).
> A symbol is no more than a
> letter sequence (+digits, +underscore). If someone is going to fight
> some code (being it written by anyone), then this one must understand
> the problem. Reading variable names is the least problem then.
Reading variable names (and subroutine names, and comments) is the
*first* step to figuring out what a program does. The most effective
step in an obfuscation program is to replace all identifiers with
meaningless identifiers like 'a0001', 'a0002', etc. and to strip
comments. Everything else is easily reverted.
>>>>> I bet you've seen this before,
>>>>
>>>> I've seen German versions of BASIC in the 1980's. They weren't a huge
>>>> success, to put it mildly. About the only successful localization of a
>>>> programming language i can think of is MS-Excel (and I guess it's
>>>> debatable if this is even a programming language (without VBA) - is it
>>>> turing-complete?).
>>>
>>> That's in case you have an option. There're places you have no option.
>>
>> I don't understand your objection. I was relating the historic fact that
>> localized programming languages (i.e., programming languages where the
>> keywords (and to a lesser amount, the grammar) were localized, so that
>> you would write "wenn ... dann ... sonst ..." instead of "if ... then
>> ... else") were a failure. People had the option to use them, but they
>> didn't want to.
>
> Then read it again (maybe my English failed this time, again). Those
> provided with germanized (is it right?) had an option. The option to
> reject it. Sometimes there's no option. You just don't know what does
> it mean having no option.
I didn't mean that every single programmer had this option. If you work
in a shop which writes software in FORTRAN-77 (I was talking about the
1980's, remember) you don't have the option to choose your programming
language. C or COBOL is just as unavailble as a germanized version of
FORTRAN.
But the industry as a whole had the option, and it rejected it (with the
single exception of spreadsheet formula languages). The industry still
has the option. There are new scripting languages all the time, and
every few years one of them becomes really popular. So introducing
new languages in general is still possible. But all the popular
programming languages are based on English. Obviously there is no need
to localize the few dozen keywords - even if you don't speak English at
all, learning what "if" and "sub" do is not a problem (and the latter
isn't a proper English word anyway, so the English speaker has to learn
it as well).
hp
------------------------------
Date: Wed, 22 Apr 2009 03:23:29 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <8urtu4t45dr6j86ndsf4eddv30636e0733@4ax.com>
bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
>Jürgen Exner wrote:
>> bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
>>> Jürgen Exner wrote:
>>>> First of all how would you react, if someone is mangling your name?
>>>> There is no "English version" of my first name.
>>> But an English speaker might well search for "Jurgen Exner"
>>> and hope to find you.
>>
>> And my name may come up as the closest hit with a 91% match.
>>
>>> Accent folding is a key component of "loose" matching.
>>
>> Having a second, closer look you are right. The OPs character set is
>> indeed very restricted to just simple accented characters and doesn't
>> include any of the more complex or additional characters found in the
>> other Latin-X sets.
>
>Of course, accent folding only helps searching in a limited context.
>
>If you have (e.g.) Japanese, Thai, Arabic data,
>you're stuffed.
Not even talking about those but simple Skandinavian, Baltic, and even
German or Polish letters.
jue
------------------------------
Date: Wed, 22 Apr 2009 20:45:32 GMT
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <slrnguv0fc.f0m.nospam-abuse@chorin.math.berkeley.edu>
On 2009-04-22, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
> Unicode only helps with representation of data; manipulation
> is still down to the application.
I strongly disagree. Unicode has its weak points, but it is still
incomparably better that any scheme a Joe Xispack would invent
herself.... Witness the disaster with Emacs Internationalization.
Just:
existence of the notion of "Unicode character",
a possibility of specifying a character unambiguously (with some
minor hair-splitting needed sometimes, as in o-trema vs o-umlaut, or
in CJK), and
having a list of "property" *names* (which is, basically, the
information about how other people look at individual characters)
should be, IMO, an enormous help in the design of what you call
"manipulations". And I did not even touch "tables", i.e., the *values*
of these properties: it is a major work in itself...
Yours,
Ilya
------------------------------
Date: 22 Apr 2009 13:52:08 GMT
From: Ben Bullock <benkasminbullock@gmail.com>
Subject: Re: Is there a module to transliterate Russian and Ukrainian cyrillic unicode to phonetic ASCII?
Message-Id: <49ef2108$0$736$c5fe31e7@read01.usenet4all.se>
On Wed, 22 Apr 2009 10:03:16 +0200, News123 wrote:
> I'd like to translate some cyrillic file names into file names, that are
> ASCII only.
>
>
> Is there any perl module / command line tool / official transliteration
> algorithm?
I find many on search.cpan.org.
I don't vouch for their quality.
------------------------------
Date: Wed, 22 Apr 2009 11:58:51 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Perl Opportunity
Message-Id: <LNJHl.46041$g%5.43584@newsfe23.iad>
Peter Wyzl wrote:
> "lala" <yolandaref@gmail.com> wrote in message
>
news:15a920fd-312e-4487-aec6-ebb863919027@r34g2000vbi.googlegroups.com...
>> Any very strong Perl Developers looking for contracting please
>> contact yolanda@refcomputer.com
>
> Where's sln when you need 'm?
>
> P
I believe the ad asked for "strong Perl Developers", so there's your
answer.
------------------------------
Date: Wed, 22 Apr 2009 14:29:41 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Perl Opportunity
Message-Id: <slrnguus15.7qq.tadmc@tadmc30.sbcglobal.net>
Nathan Keel <nat.k@gm.ml> wrote:
> Peter Wyzl wrote:
>
>> "lala" <yolandaref@gmail.com> wrote in message
>>
> news:15a920fd-312e-4487-aec6-ebb863919027@r34g2000vbi.googlegroups.com...
>>> Any very strong Perl Developers looking for contracting please
>>> contact yolanda@refcomputer.com
>>
>> Where's sln when you need 'm?
>>
>> P
>
> I believe the ad asked for "strong Perl Developers", so there's your
> answer.
But he is an Experl Perl Developer.
Just ask him!
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Wed, 22 Apr 2009 14:10:09 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: Perl Opportunity
Message-Id: <RILHl.80805$qO1.47118@newsfe13.iad>
Tad J McClellan wrote:
> Nathan Keel <nat.k@gm.ml> wrote:
>> Peter Wyzl wrote:
>>
>>> "lala" <yolandaref@gmail.com> wrote in message
>>>
>>
news:15a920fd-312e-4487-aec6-ebb863919027@r34g2000vbi.googlegroups.com...
>>>> Any very strong Perl Developers looking for contracting please
>>>> contact yolanda@refcomputer.com
>>>
>>> Where's sln when you need 'm?
>>>
>>> P
>>
>> I believe the ad asked for "strong Perl Developers", so there's your
>> answer.
>
>
> But he is an Experl Perl Developer.
>
> Just ask him!
>
>
He's also Napoleon Bonaparte, but both of his secrets are safe with me.
------------------------------
Date: Wed, 22 Apr 2009 06:14:19 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: split-like thing
Message-Id: <c9edbc41-7031-4716-916e-b4395ae7fd23@s20g2000yqh.googlegroups.com>
On Apr 21, 6:14 pm, Lars Eighner <use...@larseighner.com> wrote:
> In our last episode, <slrngusenq.cjb.nos...@nospam.invalid>, the lovely and
> talented john broadcast on comp.lang.perl.misc:
>
> > Hi,
> > If I have a string "abcdefgh", what's the best way to get an array with
> > the characters in pairs? ("ab", "cd", "ef", "gh")
>
> sed
>
sed does not have an array data type. awk would be better,
although regexp are not as powerful as perl's.
------------------------------
Date: Wed, 22 Apr 2009 09:18:39 -0700 (PDT)
From: powah <wong_powah@yahoo.ca>
Subject: sudo perl script with environment variables on linux
Message-Id: <57ff5ed9-4475-42c1-b576-82be8fc83db9@m19g2000yqk.googlegroups.com>
How to use sudo to run a perl script with the environment variable
JAVA_HOME on linux?
Running testenv.pl as sudo do not pickup the environment variable
JAVA_HOME
value.
$ echo $JAVA_HOME
/home/powah/jdk1.6.0_13
testenv.pl is:
#!/usr/bin/perl
print "begin JAVA_HOME = $JAVA_HOME\n";
$J_HOME = $ENV{'JAVA_HOME'};
print "$ENV{'JAVA_HOME'} JAVA_HOME = $J_HOME\n";
$ perl testenv.pl
begin JAVA_HOME =
/home/powah/jdk1.6.0_13 JAVA_HOME = /home/powah/jdk1.6.0_13
$ sudo perl testenv.pl
begin JAVA_HOME =
JAVA_HOME =
------------------------------
Date: Wed, 22 Apr 2009 11:16:01 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: sudo perl script with environment variables on linux
Message-Id: <9f6d2019-96ee-4bbd-b92b-ff69b1392c07@t21g2000yqi.googlegroups.com>
On Apr 22, 12:18 pm, powah <wong_po...@yahoo.ca> wrote:
> How to use sudo to run a perl script with the environment variable
> JAVA_HOME on linux?
> Running testenv.pl as sudo do not pickup the environment variable
> JAVA_HOME
> value.
>
> $ echo $JAVA_HOME
> /home/powah/jdk1.6.0_13
>
> testenv.pl is:
> #!/usr/bin/perl
> print "begin JAVA_HOME = $JAVA_HOME\n";
> $J_HOME = $ENV{'JAVA_HOME'};
> print "$ENV{'JAVA_HOME'} JAVA_HOME = $J_HOME\n";
>
> $ perl testenv.pl
> begin JAVA_HOME =
> /home/powah/jdk1.6.0_13 JAVA_HOME = /home/powah/jdk1.6.0_13
>
> $ sudo perl testenv.pl
> begin JAVA_HOME =
> JAVA_HOME =
perl -e 'print sort join " ",sort keys %ENV'
CVSROOT CVS_RSH DISPLAY EDITOR G_BROKEN_FILENAMES HISTSIZE HOME
HOSTNAME INPUTRC LANG LESSOPEN LOGNAME MAIL OLDPWD PATH PWD SHELL
SHLVL SSH_CLIENT SSH_CONNECTION SSH_TTY TERM USER _
sudo perl -e 'print sort join " ",sort keys %ENV'
DISPLAY HISTSIZE HOME HOSTNAME INPUTRC LANG LOGNAME MAIL PATH SHELL
SUDO_COMMAND SUDO_GID SUDO_UID SUDO_USER TERM USER
sudo seems to change or unset many environment variables.
This is not a perl issue -- perl just tells what it sees.
------------------------------
Date: Wed, 22 Apr 2009 11:59:48 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: sudo perl script with environment variables on linux
Message-Id: <EOJHl.46042$g%5.18676@newsfe23.iad>
powah wrote:
> How to use sudo to run a perl script with the environment variable
> JAVA_HOME on linux?
> Running testenv.pl as sudo do not pickup the environment variable
> JAVA_HOME
> value.
>
> $ echo $JAVA_HOME
> /home/powah/jdk1.6.0_13
>
> testenv.pl is:
> #!/usr/bin/perl
> print "begin JAVA_HOME = $JAVA_HOME\n";
> $J_HOME = $ENV{'JAVA_HOME'};
> print "$ENV{'JAVA_HOME'} JAVA_HOME = $J_HOME\n";
>
> $ perl testenv.pl
> begin JAVA_HOME =
> /home/powah/jdk1.6.0_13 JAVA_HOME = /home/powah/jdk1.6.0_13
>
> $ sudo perl testenv.pl
> begin JAVA_HOME =
> JAVA_HOME =
Because powah's environment is not root's.
------------------------------
Date: Wed, 22 Apr 2009 14:03:12 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: sudo perl script with environment variables on linux
Message-Id: <6bdce08e-ac31-40bc-8ba5-6dd02e84303f@t11g2000vbc.googlegroups.com>
On Apr 22, 2:59 pm, Nathan Keel <na...@gm.ml> wrote:
> powah wrote:
> > How to use sudo to run a perl script with the environment variable
> > JAVA_HOME on linux?
> > Running testenv.pl as sudo do not pickup the environment variable
> > JAVA_HOME
> > value.
>
> > $ echo $JAVA_HOME
> > /home/powah/jdk1.6.0_13
>
> > testenv.pl is:
> > #!/usr/bin/perl
> > print "begin JAVA_HOME = $JAVA_HOME\n";
> > $J_HOME = $ENV{'JAVA_HOME'};
> > print "$ENV{'JAVA_HOME'} JAVA_HOME = $J_HOME\n";
>
> > $ perl testenv.pl
> > begin JAVA_HOME =
> > /home/powah/jdk1.6.0_13 JAVA_HOME = /home/powah/jdk1.6.0_13
>
> > $ sudo perl testenv.pl
> > begin JAVA_HOME =
> > JAVA_HOME =
>
> Because powah's environment is not root's.
FOO=baz
sudo echo $FOO
baz
Note that I did not even need to export FOO.
sudo runs in the existing environment except for variables
it deems "unsafe".
------------------------------
Date: Wed, 22 Apr 2009 14:17:49 -0700
From: Nathan Keel <nat.k@gm.ml>
Subject: Re: sudo perl script with environment variables on linux
Message-Id: <GQLHl.84523$qO1.79448@newsfe13.iad>
smallpond wrote:
> On Apr 22, 2:59 pm, Nathan Keel <na...@gm.ml> wrote:
>> powah wrote:
>> > How to use sudo to run a perl script with the environment variable
>> > JAVA_HOME on linux?
>> > Running testenv.pl as sudo do not pickup the environment variable
>> > JAVA_HOME
>> > value.
>>
>> > $ echo $JAVA_HOME
>> > /home/powah/jdk1.6.0_13
>>
>> > testenv.pl is:
>> > #!/usr/bin/perl
>> > print "begin JAVA_HOME = $JAVA_HOME\n";
>> > $J_HOME = $ENV{'JAVA_HOME'};
>> > print "$ENV{'JAVA_HOME'} JAVA_HOME = $J_HOME\n";
>>
>> > $ perl testenv.pl
>> > begin JAVA_HOME =
>> > /home/powah/jdk1.6.0_13 JAVA_HOME = /home/powah/jdk1.6.0_13
>>
>> > $ sudo perl testenv.pl
>> > begin JAVA_HOME =
>> > JAVA_HOME =
>>
>> Because powah's environment is not root's.
>
> FOO=baz
> sudo echo $FOO
> baz
>
> Note that I did not even need to export FOO.
> sudo runs in the existing environment except for variables
> it deems "unsafe".
I wasn't thinking when I replied before. Anyway, unless it's exported,
it won't exist in $ENV{NAME} for Perl to see, I believe?
------------------------------
Date: Wed, 22 Apr 2009 15:01:46 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: sudo perl script with environment variables on linux
Message-Id: <8a6d7eec-1258-422e-8b55-dcf475762240@k41g2000yqh.googlegroups.com>
On Apr 22, 5:17 pm, Nathan Keel <na...@gm.ml> wrote:
> smallpond wrote:
> > On Apr 22, 2:59 pm, Nathan Keel <na...@gm.ml> wrote:
> >> powah wrote:
> >> > How to use sudo to run a perl script with the environment variable
> >> > JAVA_HOME on linux?
> >> > Running testenv.pl as sudo do not pickup the environment variable
> >> > JAVA_HOME
> >> > value.
>
> >> > $ echo $JAVA_HOME
> >> > /home/powah/jdk1.6.0_13
>
> >> > testenv.pl is:
> >> > #!/usr/bin/perl
> >> > print "begin JAVA_HOME = $JAVA_HOME\n";
> >> > $J_HOME = $ENV{'JAVA_HOME'};
> >> > print "$ENV{'JAVA_HOME'} JAVA_HOME = $J_HOME\n";
>
> >> > $ perl testenv.pl
> >> > begin JAVA_HOME =
> >> > /home/powah/jdk1.6.0_13 JAVA_HOME = /home/powah/jdk1.6.0_13
>
> >> > $ sudo perl testenv.pl
> >> > begin JAVA_HOME =
> >> > JAVA_HOME =
>
> >> Because powah's environment is not root's.
>
> > FOO=baz
> > sudo echo $FOO
> > baz
>
> > Note that I did not even need to export FOO.
> > sudo runs in the existing environment except for variables
> > it deems "unsafe".
>
> I wasn't thinking when I replied before. Anyway, unless it's exported,
> it won't exist in $ENV{NAME} for Perl to see, I believe?
hmmm. No. I was stupid. $FOO is being expanded before calling sudo.
export FOO
sudo perl -e 'print $ENV{"FOO"}'
no output.
So FOO is not in the environment in the sudo command.
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 2360
***************************************
