🚀 go-pugleaf

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.

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.

>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?

>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

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  |
  ----------------------------------------------------------------------------

>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.... 

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

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).
	

>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.

In the "what I'd really like to see" department, would be to get rid of the
one-level username system we have, and go to a hierarchial username system.
(For example, instead of being identified as "joe", a user might be
identified as admin/acct/joe if Joe was in the Administration Department,
Accounting Section of the company.  If there was another Joe doing working
in customer support, he'd be ops/cs/joe (for Operations/Customer Support/Joe)
There would be many passwd files, not just one: and many advantages would
result.  Search time through an excessively long passwd file would be a lot
less, a login name wouldn't have to be unique system-wide, the whole system
wouldn't die if the passwd file got corrupted (you'd be able to switch to
a different group and log in and fix it), etc.

Of course, doing this would create a lot of compatibility problems, but I think
there are probably answers to them.  It would still be useful to have a single
number correspond to a single user.  (to maintain compatibility with the file
system, and also so that a single user could be in multiple groups at once.) 

flint@gistdev.UUCP writes:

-In the "what I'd really like to see" department, would be to get rid of the
-one-level username system we have, and go to a hierarchial username system.
-(For example, instead of being identified as "joe", a user might be
-identified as admin/acct/joe if Joe was in the Administration Department,
-Accounting Section of the company.  If there was another Joe doing working
-in customer support, he'd be ops/cs/joe (for Operations/Customer Support/Joe)

What prevents you from creating usernames like that (or admin.acct.joe) ?
d.jba works fine for me.

-...: and many advantages would
-result.  Search time through an excessively long passwd file would be a lot
-less,

How often do you actually have to search the passwd file?

-... the whole system
-wouldn't die if the passwd file got corrupted (you'd be able to switch to
-a different group and log in and fix it), etc.

Don't you keep a copy of passwd.old around?
---
Jan B. Andersen, Datalogi 19.1     .---------------------------.       /^^^\
Roskilde Universitetscenter       ( "SIMULA does it with CLASS" )     { o_o }
Postbox 260,                       `---------------------------'  <--- \ o /
DK-4000  Roskilde (Denmark)       IfUmust: +45 46 75 77 11            -mm--mm-
-- 
Jan B. Andersen, Datalogi 19.1     .---------------------------.       /^^^\
Roskilde Universitetscenter       ( "SIMULA does it with CLASS" )     { o_o }
Postbox 260,                       `---------------------------'  <--- \ o /
DK-4000  Roskilde (Denmark)       IfUmust: +45 46 75 77 11            -mm--mm-

/* Written 12:05 pm  May 22, 1989 by harald.ruc.dk!d.jba in gistdev:comp.bugs.sys5 */

What prevents you from creating usernames like that (or admin.acct.joe) ?
d.jba works fine for me.

- I want the hierarchy, not the more complex names: unfortunately, I don't
- know any good alternatives to the longer names.  If everybody belongs to
- a group, what's wrong with asking them to tell you which group it is when
- they login?  Hypothetical situtation: I would like to have 3 different
- groups of users on the machine, and I want to have one person from each of
- those groups responsible for login management of each group.  However, I
- don't want the manager of group A to be able to screw up the logins of
- people in group B.

How often do you actually have to search the passwd file?

- Try putting 5K names in your password file for a day.  Linear searches are
- a lot of fun, and you search the file more than you think.

Don't you keep a copy of passwd.old around?

- Yes, so?  When you can't login, you have to screw around in order to
- put it back.  Most importantly, this one file getting corrupted makes
- the whole system unuseable, and 100 users are sitting on their hands,
- as opposed to just 10 people from one group.

Flint Pellett, Global Information Systems Technology, Inc.
1800 Woodfield Drive, Savoy, IL  61874     (217) 352-1165
INTERNET: flint%gistdev@uxc.cso.uiuc.edu
UUCP:     {uunet,pur-ee,convex}!uiucuxc!gistdev!flint