| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
than the LOMAC-specific interfaces for listing MAC labels. This permits
ls to view MAC labels in a manner similar to getfmac, when ls is used
with the -l argument. Next generation LOMAC will use the MAC Framework
so should "just" work with this and other policies. Not the prettiest
code in the world, but then, neither is ls(1).
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
|
| | |
|
| |
|
|
| |
Tested on i386 and alpha.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Fixed setting of WARNS in rev.1.16. Options should normally be set using
using "?=", not using "=", so that the setting is easy to override on the
command line, and setting WARNS to 0 should not be an exception.
|
| |
|
|
|
|
|
|
| |
file sizes to be displayed with unit suffixes; Byte, Kilobyte,
Megabyte, Gigabyte, Terabyte and Petabyte in order to reduce the
number of digits to three or less.
Submitted by: nik
|
| |
|
|
|
|
| |
set WARNS=0.
Reviewed by: mike
|
| |
|
|
|
|
| |
in ls(1) and ps(1).
Sponsored by: DARPA, NAI Labs
|
| |
|
|
| |
${CFLAGS}. The only supported method thus is -DRELEASE_CRUNCH.
|
| | |
|
| |
|
|
| |
Add DPADD
|
| |
|
|
| |
a note of it in the release Makefile.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 ;)
|
| |
|
|
| |
Obtained from: bde
|
| |
|
|
| |
many places nowadays.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
