Do you know where your variables are? | |
PerlMonks |
Re: Trying to take user input as username, read etc/passwd and output user IDby afoken (Chancellor) |
on May 11, 2022 at 05:18 UTC ( [id://11143768]=note: print w/replies, xml ) | Need Help?? |
I can see only two reasons for manually parsing /etc/passwd:
To learn handling CSV files, there are much better ways. And even then, Text::CSV and Text::CSV_XS are the better way to handle CSV files, simply because those modules are prepared to handle all the nasty edge cases you didn't think about. Verifying a username and/or home directory does not seem like "very special needs". You probably just want to use getpwnam in list context, i.e.:
User::pwent wraps that into a nice object:
What's the difference to reading /etc/passwd?
The second point is important: /etc/passwd is no longer the only source of user information, since at least three decades. NSS allows to add more records from other sources (NIS, NIS+, LDAP, AD, ...), and it should also allow to ignore /etc/passwd completely. PAM allows to do even more crazy stuff. The same applies to /etc/group and the getgr... functions, and also to /etc/services (getserv...), /etc/hosts (gethost...), /etc/protocols (getproto...). At work, all user and group information resides in a Samba 4 Active Directroy database (essentialy LDAP plus some extras), and the /etc/passwd on all Linux systems is at the bare minimum, just root and some system/daemon accounts. If you had an AD account, you could login into any Linux box, but you would not find your login in /etc/passwd. getpwnam works fine, and would return your user record, because at the C library level, LDAP would be queried and return your user record. Plus, it would continue to do so if we switched from AD to NIS+ or some fancy SQL database holding user records. Alexander
-- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
In Section
Seekers of Perl Wisdom
|
|