in reply to SCALAR output instead of attribute name.

my @attrs = \($nam, $pwd, $uid, $gid, $dsc, $hom, $shl);

You're assigning a refernce to an array into an array. I think what you wanted was:

my @attr = ($nam, $pwd, $uid, $gid, $dsc, $hom, $shl);

You also appear to be attempting to make a symbolic ref when you assign to the hash. Symoblic refs are generally something to be avoided, and in any case will only work with package variables (such as those declared with our) not lexicals (like my vars).

Because we don't allow root logins over ssh, using a module such as Unix::PasswdFile is not an option . . .

  1. Disallowing root logins over ssh is fine, but don't they even allow su or sudo? In fact, you should be using those even if you're logging in locally.
  2. Even if you can't get root access, you can install modules to an unprivileged directory and point Perl to it, or you can copy-and-paste the source from the module.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Re: SCALAR output instead of attribute name.
by chromatic (Archbishop) on Dec 18, 2003 at 19:12 UTC
    You're assigning a refernce to an array into an array.

    No; there's only one array in that line. The reference operator distributes over a list, returning a list of references, not an anonymous array.

Re: Re: SCALAR output instead of attribute name.
by !1 (Hermit) on Dec 18, 2003 at 19:23 UTC
    You're assigning a refernce to an array into an array.

    Ummm, no. He's assigning a list of references into an array.

    #!/usr/bin/perl -l my @a = qw(a b c); my @b = \(@a); print "\@a contains: @a"; print "\@b contains: @b"; __END__ @a contains: a b c @b contains: SCALAR(0x811b15c) SCALAR(0x811b240) SCALAR(0x811b294)

    What you are thinking of is [ LIST ].

Re: Re: SCALAR output instead of attribute name.
by sschneid (Deacon) on Dec 18, 2003 at 18:45 UTC
    1. Disallowing root logins over ssh is fine, but don't they even allow su or sudo? In fact, you should be using those even if you're logging in locally.

    Yes, absolutely. But I'm looking to grab a giant list of users from our 90-some *nix boxes. I could use a client-server design, but decided it'd be just as easy to cat /etc/passwd over a (non-privileged) ssh connection and parse the return results on whatever machine the script is being run from.

    Make more sense? I'm avoiding Unix::PasswdFile becuase it requires root privileges to use, and I don't want the script to be run as root.

    -s.

      Actually, after looking over some of the source code to Unix::PasswdFile and its parent Unix::Configfile, I wouldn't use it either. It's internals are awful.

      I don't know why you need to be root to use it, though. In any case, there are other /etc/passwd parsing modules on CPAN.

      ----
      I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
      -- Schemer

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated