These allow some very useful magic in the makefiles.
The comment in var.c describing their behaviour is mostly lifted
from ODE make, but the implementation of the modifiers themselves
is quite different (much simpler) due to divergence of our code base.
via initscr() by calling t_getstr() with curses' internal terminal info
initialized in setterm() (which is called by initscr()).
XXX THIS IS A HORRIBLE KLUDGE! ...and I'm almost embarassed to commit it.
XXX It really should be fixed by using normal curses facilities.
Firstly, we ignore getenv("PWD") if MAKEOBJDIRPREFIX is set so that we always
get the same value for .CURDIR regardless of how make was invoked.
Second, when executing a command we check if it is ${.MAKE} or ${.MAKE:T}
without a preceeding chdir, if so we insert a chdir(${.CURDIR}) so that
the Makefile will be found by the child make. Note that this behaviour is
dissabled if MAKEOBJDIRPREFIX is not set or if NOCHECKMAKECHDIR is set.
See the comments in main.c for more detail.
With these two changes, one can successfully build usr/src using MAKEOBJDIRPREFIX
allowing the src to be mounted from a CD-ROM.
Since these members are used to hold members defined now as u_quad_t
in struct if_data, u_long is quite not enough actually.
Without this, one night ttcp easily makes netstat to produce wrong output
like this:
enami@annex-2f-floor-244% netstat -ibw 1 -I tlp0
tlp0 in tlp0 out total in total out
bytes bytes bytes bytes
176333740607 176914940420 240082591 821282404
176093659136 176093659136 0 0
176093659136 176093659136 0 0
symlinks, and thus can operate on symlinks. remove a bogus comment in
chflags(1) that claims symlinks do not have file flags.
XXX: todo -- make chflags(1) use lchflags(2) when given the right options.
* sanity check a length (otherwise certain bogus responses can crash ftp)
* allow a transfer encoding type of `binary'; certain firewall vendors
return this bogus type...
The child process of do_ktrace() does return and the stack is
changed by another function call (execvp()).
By using vfork() (my previous change), the execution of the parent
process resumes on the modified stack. Oops.
We could use vfork() carefully, but for now use fork().
Problem reported and investigated by Ethan Solomita <ethan@geocast.com>.
Thanks.
mycroft