Perl unitialized variable

[Nishan Sandhar]

A perl script that USED to work all of a sudden stopped working recently (no known changes involved), with an "uninitialized variable" error message. Even the following fails:

#!/opt/perl5/bin/perl -w
#

$userid = getlogin;
print $userid;

HOWEVER, the exact same script works on OTHER servers, with the same version of Perl installed (ver. 5.6.1).

[Eric Ladner]

My guess is that on the other system, /opt/perl5/bin/perl isn't really perl version 5 or is a lower version of perl5.

Try a perl -V on both systems and compare the version.

I was able to reproduce this using my perl5 install (which is perl 5.03) to run your test program. Perl 5.03 worked fine. When I switched to /usr/contrib/bin/perl (version 4.something) I got the exact message you did.

It's possible that the getlogin wasn't implemented in 4.0 (I couldn't find a man page to validate this).

[Nishan Sandhar]

The path is the same on both servers - /opt/perl5/bin. I did a "perl -V" on both machines, and compared the output:
$ ls -al perl*
-rw-r--r-- 1 nsandhar cmsi 1723 Feb 27 10:50 perl.V.out
-rw-r--r-- 1 nsandhar cmsi 1723 Feb 27 10:50 perl.V.out.atlas
$ diff perl.V.out perl.V.out.atlas
$

The output file is exactly the same. It also shows the version as 5.6.1:

Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:

[harry d brown jr]

Although you might have the same version, it does not mean you have the same "modules" added to perl on each machine. Of course the "-w" tells perl to issue warnings for things that are normally ignored.

live free or die
harry

[A. Clay Stephenson · Accepted solution]

Hi:

You are not quite playing by the rules. First of all, getlogin requires that stdin be associated with a terminal device. Secondly, getlogin returns the current login name from /etc/utmp, it returns a null value if that fails and you should then use the getpwuid function.

This should work:

$userid = getlogin || getpwuid($<) || "Unknown";

Regards, Clay

[Eric Ladner]

Nice catch Clay!

[Nishan Sandhar]

HOWEVER - why would the same code work on some systems, but not others.

Additionally, I've found that I cannot execute the passwd command - the response is "Usage: passwd [ -F file ] [ name ]".

The perl code mentioned in the original query above works properly if executed from a Telnet window, but fails if executed from an hpterm Xwindow created via a Rexec in Hummingbird eXceed product.

Any ideas?

[A. Clay Stephenson]

The getlogin Perl function relies on the underlying getlogin() libc function. It depends upon the build of the code and the platform that it's running on. The real answer (though you are not going to like it) is that your Perl was working by accident. You really have to assume that getlogin will fail and act accordingly. By the way, this is exactly what you should do in C as well. Call getlogin() first, it that fails, call getpwuid(). That is how I knew the answer as soon as I saw your post.

As to your ExCeed problem, I don't know but I avoid PC based X-emulators like the plague. I find that they work 'almost perfectly' and that is the worst kind of problem to fight. I suspect that passwd is failing because it can't set echo to off.

Food for thought, Clay

[Ralph Grothe]

Just an aside to Clay's solution.
Nishan could have found this if he only would have RTFM or in Perl-speach the POD
Nishan, at the shell prompt simply issue the following:

perldoc -f getlogin
perldoc -f getpwuid
perldoc perlvar

Clay has given a thorough explanation.
Maybe just to add,
$> is Perl's eff. UID, $< real UID, $) eff. GID, $( real GID (consult POD above)

getpwuid $<
returns a list of entries in /etc/passwd for the passed UID.
In scalar context however, as in the POD's or Clay's example, it only returns the first field of the matching entry in /etc/passwd.
This could also be accomplished by taking a slice
(getpwuid $<)[0]