| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
${CFLAGS}. The only supported method thus is -DRELEASE_CRUNCH.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
dependent upon the output being directed to a terminal however.
(Use the CLICOLOR_FORCE variable to force output).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
and symbolic links (by default)
PR: bin/19354
Reviewed by: silence on -current
|
|
|
|
|
|
| |
Remove newly added hard sentence breaks.
Mark ANSI up as a type name (Tn).
Avoid parenthesized sentences and paragraphs.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Rewrite corresponding comment to say what happens in reality with oxtabs
and current terminal column.
|
|
|
|
|
| |
as comment says. I know no terminal confused by this. If even such terminal
exists, it must be termcap flag for this, not hardcoded in ls.
|
| |
|
| |
|
|
|
|
|
| |
Add "extern" to variables declarations in extern.h to not make them
commons into each compiled file.
|
|
|
|
|
|
| |
Staticize some color functions
Add yet one tolower() call which is forgotten after check
Don't check for OOPS - not really needed
|
|
|
|
|
| |
yellow -> brown
white -> light grey
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Add ^C reaction set
|
|
|
|
| |
Add DPADD
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
of the typeset output, tend to make diffs harder to read and provide
bad examples for new-comers to mdoc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 ;)
|
|
|
|
|
| |
essentially large unsigned ones, and we already print minor
numbers > 255 in hex.
|
|
|
|
| |
Obtained from: bde
|
| |
|
|
|
|
| |
many places nowadays.
|
|
|
|
|
|
| |
a '\0' at the end of a string.
Submitted by: Martin Birgmeier <Martin.Birgmeier@aon.at>
|