While it fixed the problem of trailing spaces, but if the probe specifier
contained leading spaces, it would brake dtrace. The proper fix would be
to skip the leading spaces in the string as well.
However, it would result in a bigger diff for a very small benefit. While
a new import of dtrace is impending, it's better not to have this change.
Discussed with christos.
When using dtrace using one of the tracing options, such as -n, -P, -i, -f etc.,
the first line of output from dtrace one is something like this:
sudo dtrace -n 'syscall:::entry /pid == 100/ {@num[probefunc] = count();}'
dtrace: description 'syscall:::entry ' matched 482 probes
There is a trailing space at the end of the probe specifier name ('syscall:::entry ').
This happens beucase dtrace tries to separate the probe name from the predicate and actions
using `{' and `/' as the separators but doesn't consider space also as a possible separator.
Output after this change:
sudo dtrace -n 'syscall:::entry /pid == 100/ {@num[probefunc] = count();}'
dtrace: description 'syscall:::entry' matched 482 probes
ok christos@
- Relocate definitions in the following order to be easy to understand.
0) IFM_*MASK
1) macros to extract various bits of information from the media word.
2) Media type.
3) Shared media sub-type.
4) Status bits.
5) Shared (global) options
6) Media dependent definitions.
7) kernel function declarations.
7) userland function declarations.
- Add comments.
This change makes me realize that:
0) RFU bit have never used.
1) bit 1..0 are shared between Shared media sub-type and Status bits.
It's little dangerous.
2) No. 5 of Media type is not used (hole).
3) Only IEEE80211 uses IFM_MMASK(IFM_MODE()) bits.
4) IFM_TOKEN's OMASK bits doesn't start from 0x00000100 but starts from
0x00000200. Is this for BSD/OS compatibility?
This version of dhcrelay(8) needed to stay inforeground with -d flag in
order to service requests. Running inbackground turned it deaf to DHCP
requests.
This was caused by wrong kqueue(2) usage, where kevent(2) was used with
a file descriptor obtained by a kqueue(2) call done before fork(2).
kqueue(2) man page says "The queue is not inherited by a child created
with fork(2)". As a result, kevent(2) calls always got EBADF.
The fix is to reorder function calls in dhcrelay(8) main() function.
dhcp_context_create(), which causes kqueue(2) to be invoked, is
moved with its dependencies after fork(2). This matches the code layout
of dhclient(8) and dhcpd(8), which do not have the bug.
The fix was not submitted upstream since latest ISC DHCP code was
refactored and does not have the bug anymore.
while doing a half-hearted, broken, partial, version of cd -L instead.
The latter (as the manual says) is not supported, what's more, it is an
abomination, and should never be supported (anywhere.)
Fix the doc so that the pretense that we notice when a path given crosses
a symlink (and turns on printing of the destination directory) is claimed
no more (that used to be true until late Dec 2016, but was changed). Now
the print happens if -o cdprint is set, or if an entry from CDPATH that is
not "" or "." is used (or if the "cd dest repl" cd cmd variant is used.)
Fix CDPATH processing: avoid the magic '%' processing that is used for
PATH and MAILPATH from corrupting CDPATH. The % magic (both variants)
remains undocumented.
Also, don't double the '/' if an entry in PATH or CDPATH ends in '/'
(as in CDPATH=":/usr/src/"). A "cd usr.bin" used to do
chdir("/usr/src//usr.bin"). No more. This is almost invisible,
and relatively harmless, either way....
Also fix a bug where if a plausible destination directory in CDPATH
was located, but the chdir() failed (eg: permission denied) and then
a later "." or "" CDPATH entry succeeded, "print" mode was turned on.
That is:
cd /tmp; mkdir bin
mkdir -p P/bin; chmod 0 P/bin
CDPATH=/tmp/P:
cd bin
would cd to /tmp/bin (correctly) but print it (incorrectly).
Also when in "cd dest replace" mode, if the result of the replacement
generates '-' as the path named, as in:
cd $PWD -
then simply change to '-' (or attempt to, with CDPATH search), rather
than having this being equivalent to "cd -")
Because of these changes, the pwd command (and $PWD) essentially
always acts as pwd -P, even when called as pwd -L (which is still
the default.) That is, even more than it did before.
Also fixed a (kind of minor) mem management error (CDPATH related)
"whosoever shall padvance must stunalloc before repeating" (and the
same for MAILPATH).
