On Thu, 8 Jun 2000, Greg A. Woods wrote:

[mv/ln/cp linked; okay it was those three...]
[mkdir/mknod not; i remember now it was that mkdir had to be setuid
 because the _rename_ call hadn't been implemented yet, that was it!
 so mkdir was, more or less (modulo GC and error checking)

	char *cp;
 	mkdir(path);
	link(path, cp = strspl(path, "/."));
	link(getcwd(), cp = strspl(path, "/.."));
	
# (I think they were all separate in 4.2BSD too, but I've only the
# AT&T-free 4.3 distributions online at the moment.)

Yes, they were separate in BSD.

# Note how small those programs are too!  ;-)  And note that V7 had more
# error checking in mv.c than sysIII.

Hm.

# > In the above cases, it makes a LOT of sense to have the hooks
# > in a single binary, otherwise code is duplicated, space is wasted,
# > cache is lost (if you think cache isn't important, you have never had
# > to run a shell script which did a lot of chown/chgrp and other linked-
# > binary stuff on a BIG tree or a lot of files, and you had the script
# > handy but no time to write another one).
# 
# There are at least two kinds of code sharing and I really do not like
# the one you describe above where everything is linked together.  If I
# wanted that then I'd run some big monolithic system (like Multics! ;-).

I didn't say that EVERYTHING should be linked, but if the operations are
_similar enough_, they should be linked.

Would you, for example, have a separate program to handle symbolic links?

Would you write chown and chgrp to be separate programs?

I'd keep cp/mv/rm separate, obviously.

But there are places where code sharing makes sense.

# Shared libraries are bad enough but shared static binaries are horrid
# hacks suitable only for extreme situations like the boot floppy or
# embedded systems!

"Shared libraries are bad enough."  And you say *I* resist progress?!?

I think shared libs are saving us from overrunning disks and memory.

				--*greywolf;
--
BSD: The cure for the common OS.