o Added the -H and -P options for treatment of symbolic links.
o Removed the #ifdef BSD4_4_LITE, since it does not seem to do anything
useful
o Fixed up prn_octal() so its output looks more like that of AT&T Unices
when -b is given.
The next two lines apply only to the first two changes above:
PR: bin/6140
Submitted by: Max Euston
o Added a new '-b' which behaves as in AT&T Unices (show unprintables in
octal, using C escape codes when possible)
o Added '?' to the getopt() string, since the code in the switch considers
it as a valid option.
that this source is compiled against. This source is referenced by
install which is needed as a build tool and must be able to compile
against NetBSD headers and libraries if we have a hope of supporting
another architecture.
With this change, that's two working programs down and 3945 (?) to go.
The other one was make, but that didn't need any changes to work under
FreeBSD/Alpha. 8-)
These changes add the ability to specify that a UFS file/directory
cannot be unlinked. This is basically a scaled back version
of the IMMUTABLE flag. The reason is to allow an administrator
to create a directory hierarchy that a group of users
can arbitrarily add/delete files from, but that the hierarchy
itself is safe from removal by them.
If the NOUNLINK definition is set to 0
then this results in no change to what happens normally.
(and results in identical binary (in the kernel)).
It can be proven that if this bit is never set by the admin,
no new behaviour is introduced..
Several "good idea" comments from reviewers plus one grumble
about creeping featurism.
This code is in production in 2.2 based systems
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
/usr/src/bin. Note that some patches are still needed in that directory.
I (Joerg) finished most of Philippe's cleanup. /bin/sh will still
need *allot* of work, however.
Submitted by: charnier@lirmm.fr (Philippe Charnier)
