Don't use curses functions, use tputs instead
Add ^C reaction - reset colors
Optimization - don't turn off colors after EACH file printed.
Fix wrong ctype macro arg type in LSCOLORS parsing
this is extremely inefficient, instead write them all down at the
beginning.
The correct sequence to switch colours off is to first use 'op' if
it exists, otherwise use 'oc'. If neither of these exist then we
shouldn't be doing colour with this terminal.
Reviewed by: ache
to manage the ANSI colour sequences. Colour support is disabled
unless the TERM environment variable references a valid termcap.
* Allow optional compilation of the colour support in the Makefile,
defaulting to yes. This allows us to switch it off for fixit
floppies and other mediums where space is an issue and the extra
bloat of statically linking with ncurses isn't acceptable.
* Display a warning if colour is requested with '-G' but support
for it isn't compiled in.
It is not switched on by default and must be enabled with the -G
flag. When using ls -G the output behaviour is modified with ANSI
colour sequences wrapped around filenames to help distinguish file
types. (Colours can be redefined in the LSCOLORS environment
variable as described in the manual page.)
Colour support is silently disabled (if switched on) if stdout
isn't a tty.
Based on: asami's colorls port.
PR: bin/18900 && ports/18616.
interface, and statically link them to the programs using them.
These functions, upon reflection and discussion, are too generically
named for a library interface with such specific functionality.
Also the api that they use, whilst ok for private use, isn't good
enough for a libc function.
Additionally there were complications with the build/install-world
process. It depends heavily upon xinstall, which got broken by
the change in api, and caused bootstrap problems and general mayhem.
There is work in progress to address future problems that may be
caused by changes in install-chain tools, and better names for
{g|s}etflags can be derived when some future program requires them.
For now the code has been left in src/lib/libc/gen (it started off
in src/bin/ls).
It's important to provide library functions for manipulating file
flag strings if we ever want this interface to be adopted outside
of the source tree, but now isn't necessarily the right moment
with 4.0-release just around the corner.
Approved: jkh
string to u_long and back using two functions, flags_to_string and
string_to_flags, which co-existed with 'ls'. As time has progressed
more and more other tools have used these private functions to
manipulate the file flags.
Recently I moved these functions from /usr/src/bin/ls to libutil,
but after some discussion with bde it's been decided that they
really ought to go in libc.
There are two already existing libc functions for manipulating file
modes: setmode and getmode. In keeping with these flags_to_string
has been renamed getflags and string_to_flags to setflags.
The manual page could probably be improved upon ;)
To quote their ls(1) specification:
-n
The same as -l, except that the owner's UID and GID numbers are
written, rather than the associated character strings.
Reviewed by: green
Use an upward approximation of the number of characters required
for decimal representations of uid_t, gid_t and u_quad_t, intead
of arbitrary values that may not be safe in the future.
Fix disordering.
Requested by: bde
in a long (-l) listing.
MFC-jockies should make sure that bde's concerns regarding the number
of digits required to represent a uid_t and the use of snprintf
on the associated PR have been addressed before going wild.
PR: 12866
Reported by: Philip Kizer <pckizer@nostrum.com>
Obtained from: NetBSD
effectively overriding the dynamically-sized-column feature. This
is mostly useful for non-interactive use, where it may be necessary
to ensure that listings taken at different times have columns that
line-up correctly. I have been assured that at least one large,
well-known program will soon be taking advantage of this. :-)
PR: bin/7011
Submitted by: Joel Ray Holveck <joelh@gnu.org>
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)
