ed block, even if the code inside won't be
compiled, where in the former case it does not (the preprocessor
strips all comments before parsing tokens). It doesn't have anything
to do with what you were trying to explain. It was just an interesting
comment on comments.
-brian
--
Brian O'Shea
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
tf_eax = 55, tf_trapno = 7, tf_err = 2, tf_eip = 134536452, tf_cs = 31,
tf_eflags = 643, tf_esp = -1077937056, tf_ss = 47})
at ../../i386/i386/trap.c:1126
#13 0xc0244f65 in Xint0x80_syscall ()
#14 0x80486ee in ?? ()
#15 0x8048478 in ?? ()
#16 0x8048139 in ?? ()
--
Brian O'Sh
behaves like tcsh. This is a common
technique (check out ex, nex, nvi, nview, vi, and view, for examples;
all are hard links to the same file). The program checks its argv[0]
and behaves differently depending on what it is set to.
-brian
--
Brian O'Shea
[EMAIL PROTECTED]
To Unsubscr
r, but I havn't heard anything about it since. How do you
use it?
Thanks,
-brian
p.s. Forgive me if this is well documented in -CURRENT. At the moment,
the latest version of FreeBSD that I have available to me is 4.1-RC
(cvsup from July 21) and I can't find any mention of it.
--
al port?
Also, please include :
- A description of the hardware you are using
- When you last updated -current sources
Thanks,
-brian
--
Brian O'Shea
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
10
[panic:/root]# hd /proc/16/cmdline
69 72 71 31 3a 20 61 74 6b 62 64 30 00 00 00 00 |irq1: atkbd0|
0010
There seem to be lots of nulls at the end of the names of kernel
threads (padding their names to 16 bytes). Not that it matters,
but it's strange.
-brian
--
B
> Revision ChangesPath
> 1.16 +14 -15src/sys/dev/random/randomdev.c
Maybe this is a related problem (except now random read blocking is
interruptable?)
--
7; names.
Of course, they have added a symlink maze (worse, hard links on HP-UX)
on top of that, making it tedious to maintain rc scripts by hand
(maybe that was by design).
[snip]
--
Brian O'Shea
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
n mktemp ()
#5 0x804c692 in mkstemp ()
#6 0x804886a in write_elf_hints ()
#7 0x8048818 in update_elf_hints ()
#8 0x8048c61 in main ()
#9 0x8048139 in _start ()
-brian
--
Brian O'Shea
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, Oct 23, 2000 at 05:07:42PM -0400, Brandon D. Valentine wrote:
> On Mon, 23 Oct 2000, Brian O'Shea wrote:
>
> >Sounds interesting. To add a new rc script to the system, do you have
> >to add an entry to an "rc order list" somewhere (in addition to adding
ooks, including some pretty
> old ones, refer to sending HUP signal as standard way of
> restarting/resetting daemons.
Using the `kill -HUP` method, how do you deal with the dependency
issues that people have been mentioning in this thread?
-brian
--
Brian O'Shea
[EMAIL PROTECTED]
To
cess forking, so eventually
resources get exhausted. Take a look at the attachment for more
details.
-brian
--
Brian O'Shea
<[EMAIL PROTECTED]>
It looks like the program basically does this, in pseudo-code:
main()
{
int pid;
while (1) {
pid = fork();
if (
12 matches
Mail list logo
