goes to a fair degree of trouble to enable something like this to
be safe: cd /tmp && find . -mtime +7 -delete
It removes both files and directories. It does not attempt to remove
immutable files (an earlier version I showed to a few people did a chflags
and tried to blow away even immutable files. Too risky..)
It is thought to be safe because it forces the fts(3) driven descent to
only do "minimal risk" stuff. specifically, -follow is disabled, it does
checking to see that it chdir'ed to the directory it thought it was
going to, it will *not* pass a pathname with a '/' character in it to
unlink(), so it should be totally immune to symlink tree races. If it runs
into something "fishy", it bails out rather than blunder ahead.. It's better
to do that if somebody is trying to compromise security rather than risk
giving them an opportunity. Since the unlink()/rmdir() is being called
from within the current working directory during the tree descent, there
are no fork/exec overheads or races.
As a side effect of this paranoia, you cannot do a
"find /somewhere/dir -delete", as the last argument to rmdir() is
"/somewhere/dir", and the checking won't allow it. Besides, one would use
rm -rf for that case anyway. :-)
Reviewed by: pst (some time ago, but I've removed the immutable file
deletion code that he complained about since he last saw it)
known to printf(3) and then used printf() to format it... The only
problem what the #define printf out1fmt. The code was behaving differently
when run as a shell builtin since out1fmt() isn't printf(3).
Simple hack. Print to a buffer and fputs (also #defined for sh) the
result. This should fix the printf builtin problem in PR#1673, rather
than leaving the call commented out. (printf.o was being statically linked
in anyway, we might as well use it)
creating a symbolic link from foo.html (from <label name="foo">) to
the numbered file, a shell script is built that can be used to make
the links at a later time (read: after installation in the target
directory).
having the same effect, and install a link for this. There is
historic precedence for the command hd(1) (with roughly that output
format) in Xenix, SCO, and a few SysV's that tooks the idea.
Also, added a couple of spaces to the -C format to make the output
better readable.
Ok'ed by: phk
. prototyped and staticized the internal functions while i was here,
. made the thing -Wall clean,
. fixed an error that causes the recipient name to be matched only
for the first characters, as opposed to a full name (wonder why i'm
concerned? Well, one of my login IDs is `j', and i've noticed that
vacation has been sending out replies to all mailing list messages
that had a jkh@ or jmb@ in it :),
. introduced an option -l to list the contents of the database; mucho
useful if you've got (too) many mailing list messages in your inbox
and wanna make sure you don't miss the `important' mails.
not halt on error. Thanks to Wolfram for reminding me. ;)
Also remove a unnecessary test for c == '\n', since the
loop (in ParseSkipLine) will not terminate unless
c == '\n' || c == EOF, and the EOF case is already
explicted handled by a return statement.
- Change the debug flag from -d to -D to avoid conflict with other
install programs.
- Update man page to reflect this
- Update usage string
-d meaning creat directory is specifically not implemented by these changes.
$(.CURDIR}/obj search while retaining compatability of new
prefix with cwd for the current source tree builds.
.TARGETOBJDIR has been removed from make and CANONICALOBJDIR set in
bsd.obj.mk
The builtin object directory searching is defined specifically as:
If MAKEOBJDIRPREFIX is defined, the search order is
${MAKEOBJDIRPREFIX}${.CURDIR}
${.CURDIR}
Else if MAKEOBJDIR is defined, the search order is
${MAKEOBJDIR}
${.CURDIR}
Otherwise, default to the search order
${.CURDIR}/obj.`uname -m`
$(.CURDIR}/obj
/usr/obj${.CURDIR}
${.CURDIR}
Reviewed by: bde
/usr/bin/lock can be used to lock a terminal much like xlock does
for your X-windows session. Problem is, /usr/bin/lock cannot lock
your terminal indefinately. Rather you must specify a timeout
value, after which, your terminal is unlocked and become unsecured.
I have added a ``-n'' no timeout option to /usr/bin/lock
Currently the only way to get this functionality is to use a huge
timeout value and hope it is long enought (in time). This method
also requires you to know the maxium number of minutes you are
allowed to specify.
Submitted by: David E. O'Brien <obrien@Nuxi.cs.ucdavis.edu>
