LC_CTYPE setting) when determining which characters are printable.
This is an often-requested feature.
Use wcwidth() to determine the number of column positions a character
takes up, although there are still a few places left where we assume
1 byte = 1 column position, e.g. line-wrapping when handling the -m option.
The error handling here is somewhat more complicated than usual: we do
our best to show what we can of a filename in the presence of conversion
errors, instead of simply aborting.
will print them (i.e., number of successful calls to acl_get_entry()
exceeds 3). This makes O(1) what was O(num_TYPE_ACCESS_ACLs).
This is a slightly modified version of submitter's patch.
PR: bin/65042
Submitted by: Christian S.J. Peron <maneo@bsdpro.com>
1. Sizes in the range 1000 -- 1023 units require four characters width
for the integer; increase the field width to accomodate this.
2. Sizes in the range 9.95 -- 10 units were being displayed as "10.0"
units; adjust the logic to fix this, and now that we've got an extra
character of field width, print fractional units if the size is less
than 99.95 units.
3. Don't display sub-byte precision.
This should mean that the following sizes are displayed:
0B .. 1023B
1.0U .. 9.9U
10.0U .. 99.9U
100U .. 1023U
for values of U in "KMGTPE".
PR: bin/63547
Pointy hat to: cperciva
Approved by: rwatson (mentor)
from log[10](largest file size), but when outputting in human-friendly
format the width is always at most 4. (eg. "123K", " 12K", "1.2K".)
PR: bin/59320
Approved by: rwatson (mentor)
determine whether a symlink has an ACL. Instead, assume that symbolic
links don't have ACLs and don't bother checking. Avoids spurious
ENOENT warnings when listing directories containing broken symlinks
on filesystems with ACLs enabled.
Pointed out by: rwatson, bde
do the wrong thing when the symlink doesn't have a target, by
considering !f_label in the construction of ch_options.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
listings if the file has an extended ACL (more than the required 3 entries).
This is what Solaris and IRIX do, and what the withdrawn POSIX.2c standard
required.
Reviewed by: rwatson (an earlier version of the patch)
object to retrieve label information on, rather than directly
consuming the fts-provided paths (none of which are quite right).
This is based on the similar readlink() code, and may contain
the same bugs.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, Network Associates Laboratories
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
appropriate. Before this, a 2.9 GB file was misleadingly reported as
"2G". This mostly brings unit_adjust() in line with what is in du(1).
Reviewed by: jmallett
Approved by: nik
hack, thereby allowing future extensions to the structure (e.g., for extended
attributes) without rebreaking the ABI. FTSENT now contains a pointer to the
parent stream, which fts_compar() can then take advantage of, avoiding the
undefined behavior previously warned about. As a consequence of this change,
the prototype of the comparison function passed to fts_open() has changed
to reflect the required amount of constness for its use. All callers in the
tree are updated to use the correct prototype.
Comparison functions can now make use of the new parent pointer to access
the new stream-specific private data pointer, which is intended to assist
creation of reentrant library routines which use fts(3) internally.
Not objected to in spirit by: -arch
(I skipped those in contrib/, gnu/ and crypto/)
While I was at it, fixed a lot more found by ispell that I
could identify with certainty to be errors. All of these
were in comments or text, not in actual code.
Suggested by: bde
MFC after: 3 days
-m List files across the page, separated by commas.
-p Print a slash after directory names
-x Same as -C but sort across the columns rather than down
Submitted by: Kyle Martin <mkm@ieee.org>
Install sys/<arch>/include/pc/*.h to /usr/include/machine/pc/.
PR: docs/29534
Install sys/netatm/*/*.h to /usr/include/netatm/*/.
Don't install compatibility symlinks for <machine/soundcard.h>
and <machine/joystick.h>. Three years is enough to be aware of
the change, and these weren't visible in the SHARED=symlinks
case.
Back out include/Makefile,v 1.160 that was a null change anyway
due to the bug in the path, and we now don't want to install
these headers because they would otherwise be invisible in the
SHARED=symlinks case.
Don't install IPFILTER headers. Userland utilities fetch them
directly, and they were not visible in the SHARED=symlinks case.
Resurrect SHARED=symlinks in Makefile.inc1.
PR: bin/28002
Prodded by: bde
MFC after: 2 weeks
o Old-style K&R declarations have been converted to new C89 style
o register has been removed
o prototype for main() has been removed (gcc3 makes it an error)
o int main(int argc, char *argv[]) is the preferred main definition.
o Attempt to not break style(9) conformance for declarations more than
they already are.
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
are now defined using the characters a-h and A-H for the bold
variants. The old way using 0-7 for the colours still works, but
prints a message asking the user to switch.
PR: bin/27374
flag has been depricated, although it still works with a warning
message, and replaced with an environment variable CLICOLOR (command
line interface colour). This could be used by other tools that
want to be able to control colour output.
In addition if the environment variable CLICOLOR_FORCE is defined
colour sequences are output irrespective of whether the output is
directed to a terminal (as long as TERM references a colour capable
terminal of course ;)
PR: bin/20291 and bin/20483
terminal emulator.
As pointed out by jhb, a more scalable solution would be preferable
when multiple applications in the base system begin linking against
libh.
Submitted by: Doug Barton <DougB@gorean.org>
the long -l output format with the last commit. Fix it
by replacing the "%b %e" strftime format with "%Ef".
Make a note in the manual page that the LANG environment
variable affects the running of ls.
Reviewed by: ache
representation of time and date") won't change in time. Instead
of hard coding the locations of the time elements and hoping that
they don't move use strftime to generate the desired formats in
the first place.
PR: bin/7826
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
