This lets you resolve pathnames to their underlying physical path:
critter# realpath /sys/kern/subr_disk.c
/freebsd/src/sys/kern/subr_disk.c
Update the pwd man-page slightly.
- The ability to specify elements by volume tag instead of their actual
physical location. e.g., instead of:
chio move slot 3 slot 4
you would now use:
chio move voltag FOO slot 4
- The ability to return an element to its previous location, as specified
by the source element. e.g., instead of:
chio move drive 0 slot 4
you would now use:
chio return drive 0
or
chio return voltag FOO
These features will obviously only work with changers that support volume
tags and/or source element IDs. chio(1) should fail gracefully if the user
attempts to use these new features and the source element ID or volume tag
are not found.
PR: bin/21178
Submitted by: "C. Stephen Gunn" <csg@waterspout.com>
Reviewed by: ken
include:
* Mutual exclusion is used instead of spl*(). See mutex(9). (Note: The
alpha port is still in transition and currently uses both.)
* Per-CPU idle processes.
* Interrupts are run in their own separate kernel threads and can be
preempted (i386 only).
Partially contributed by: BSDi (BSD/OS)
Submissions by (at least): cp, dfr, dillon, grog, jake, jhb, sheldonh
Serious fix still needed, see discussion on -current
(Subject: /bin/sh dumps core with here-document of 8bit text)
Problem in this code originally spotted by
Jun Kuriyama <kuriyama@FreeBSD.org>
growstackblock() sometimes relocates a stack_block considered empty
without properly relocating stack marks referencing that block.
The first call to popstackmark() with the unrelocated stack mark
as argument then causes sh to abort.
Relocating the relevant stack marks seems to solve this problem.
The patch changes the semantics of popstackmark() somewhat. It can
only be called once after a call to setstackmark(), thus cmdloop() in
main.c needs an extra call to setstackmark().
PR: bin/19983
Submitted by: Tor.Egge@fast.no
Reviewed by: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
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
