ccea3@rivm.UUCP (Adri Verhoef) (05/05/89)
The command 'ls -n' fails with '/etc/passwd file cannot be opened for reading' if the password file is missing, or it fails with '/etc/group file cannot be opened for reading' if the group file is missing. -Flame on- 'ls -n' does not need to open any password or group file! -Flame off- -- 19:89 - TIME TO WAKE UP!
frank@hpuamsa.UUCP (Frank Slootweg) (05/11/89)
Works fine on HP-UX (300 and 800 (Oops, not on 500 :-)).
This shows again that "sys5" *can* be better than "sys5.att".
Moral: Please mention supplier, OS name and release.
Frank Slootweg, Hewlett-Packard, The Netherlands.
HP fixed *thousands* of bugs in ATT code (and we are still not there :-))
Disclaimers : No offense to anyone. Don't sue me (my most valuable
possesion is a defective ZX81). I love UNIX(tm) and ATT
*did* "give" it to the world.frank@hpuamsa.UUCP (Frank Slootweg) (05/12/89)
I wrote :
> HP fixed *thousands* of bugs in ATT code (and we are still not there :-))
A (mild) apology :
I should have made no comments about the quality of ATT software. It
was not relevant and not really called for (the basenote poster only
mentioned a single (presumed) bug).
I *did* "sneer" at ourselves, put a smiley at the end, said 'No
offense to anyone.' and 'I love UNIX(tm) and ATT *did* "give" it to the
world.' but still at least one person was somewhat annoyed/offended.
I am sorry about that. I will try to be more carefull in my wording in
the future.
Frank Slootweg, HP, The Netherlands.ked@garnet.berkeley.edu (Earl H. Kinmonth) (05/12/89)
>I should have made no comments about the quality of ATT software. It >I am sorry about that. I will try to be more carefull in my wording in >the future. Corporate big brother is watching? Or is corporate big mother is listening?
ccea3@rivm.UUCP (Adri Verhoef) (05/12/89)
>Works fine on HP-UX (300 and 800 (Oops, not on 500 :-)). > >Moral: Please mention supplier, OS name and release. ``ls -n'' failing to work: 3b2 sVr2.0 2.0.4 2.0.5 M380 XENIX sVr2.2.1 VAX UNIQ sVr3.0 Working: BSD 4.1 PDP11/73 XENIX 3.0 altos 986 XENIX 2.5a
jeff@softop.UUCP (Jeff) (05/12/89)
In article <1326@rivm05.UUCP>, ccea3@rivm.UUCP (Adri Verhoef) writes: > The command 'ls -n' fails with '/etc/passwd file cannot be > opened for reading' if the password file is missing, or it > fails with '/etc/group file cannot be opened for reading' > if the group file is missing. > > -Flame on- > 'ls -n' does not need to open any password or group file! > -Flame off- I had never considered this before. Inspection of inode.h (Xenix 2860 shows that the inode contains uid & gid, not username and groupname. Surely then 'ls -n' is the only version that should work if the files ARE missing????? -- ---------------------------------------------------------------------------- | Jeff Tate | 2425 Pandora Street, Vancouver, BC, Canada | | van-bc!softop!jeff | (604) 254-4583 | ----------------------------------------------------------------------------
guy@auspex.auspex.com (Guy Harris) (05/16/89)
>I had never considered this before. Inspection of inode.h (Xenix 2860 >shows that the inode contains uid & gid, not username and groupname. Well, you should have looked at "stat.h", since "ls" looks at what it gets back from "stat" - it doesn't look directly at the inode - but you get the same answer, and will get it for any other version of UNIX as well. >Surely then 'ls -n' is the only version that should work if the files >ARE missing????? Yes, but so what? He said, quite specifically: 'ls -n' does not need to open any password or group file! he didn't say anything about "ls" without the "-n" flag or with other flags. I presume he has a legitimate reason for wanting to do an "ls -n" on a system with either "/etc/passwd" or "/etc/group" missing....
bink@aplcen.apl.jhu.edu (Ubben Greg) (05/16/89)
In article <1622@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > he didn't say anything about "ls" without the "-n" flag or with other > flags. I presume he has a legitimate reason for wanting to do an "ls > -n" on a system with either "/etc/passwd" or "/etc/group" missing.... Speaking of "ls -n" ... (INFORMATION ARTICLE) For Bourne shell programmers, the following script magnifies the speed difference between using "ls -n" and "ls -l" on System V: mkdir a && cd a # Build playpen # Create a lot of files with different owners to make ls work hard sed 's/:.*//; s/.*/chown & & >&/' /etc/passwd | sh - timex ls -l # Really slow (might want to >/dev/null) timex ls -n # Much faster (though less portable) cd .. && rm -fr a # Clean up (be careful) You can instead just try LS on one of the more popular parents of home directories for the same effect. For this reason, I never use "ls -l" in scripts when I don't need the actual owner or group names. -- Greg Ubben bink@aplcen.apl.jhu.edu
jgy@cbnewsh.ATT.COM (john.g.young) (05/16/89)
Another problem with 'ls' is with nameless userids. Try creating a few files with userids which don't have entries in the password file. Use the same userid for each, if your password file is of a reasonable length you will be treated to a considerable delay between each line of output as ls parses the entire file for each output line. Two possible improvements: 1) ls currently (svr3) remembers the last uid & gid searched for an SUCCESFULLY found in the /etc/(passwd|group) file. This "buffer :)" should be enlarged and also include unfound ids. 2) This would elliviate the need for a larger buffer; use some kind of database system to speed up access to the password file (I belive some BSD systems may do this) and/or keep it in a shared memory segment (locked in core).
guy@auspex.auspex.com (Guy Harris) (05/18/89)
>Two possible improvements: > 1) ls currently (svr3) remembers the last uid & gid > searched for an SUCCESFULLY found in the /etc/(passwd|group) > file. This "buffer :)" should be enlarged and also include > unfound ids. The SunOS S5 "ls" ("/usr/5bin/ls"), as I remember, has the same UID/GID lookup cache as does the SunOS 4BSD "ls" ("/usr/bin/ls", or "/bin/ls" on older versions), which is derived from the 4.xBSD version, and which handles multiple UIDs and GIDs. The BSD version doesn't handle missing IDs, though; I don't remember whether the SunOS one does. (Oh, and while you're doing this, fix it to use "getpwuid" and "getgrgid", as mentioned in a previous article....) > 2) This would elliviate the need for a larger buffer; > use some kind of database system to speed up access to > the password file (I belive some BSD systems may do this) Yes, 4.3BSD uses an "ndbm" index to the password file in "getpw*"; since their "ls" uses "getpwuid", it picks up the improvement automatically.