On Wednesday 10 June 2009 13:33:19 Martin McCormick wrote:
> We use both bind and the ISC DHCP server and are very
> satisfied customers. When you use omshell to add a bootP entry,
> it inserts it as a clause in the dhcpd.leases file but you still
> must specify all the parameters yourself.
Mel Flynn writes:
> If this is the sole purpose of the program, I would retire it if you're
> using
> ISC provided software for these services. rndc and omshell can do all of
> this
> using atomic operations. Information is gathered first, then sent in one
> block
> to the server, so even if two
On Wednesday 10 June 2009 08:28:14 Martin McCormick wrote:
> Mel Flynn writes:
> > Agreed. You're solving the wrong problem by mapping CTRL-Z to CTRL-C. The
> > questions you should be asking are:
> > 1) Why are stale locks bad for the app?
>
> Because if there is one, nobody else in our group can
Mel Flynn writes:
> Agreed. You're solving the wrong problem by mapping CTRL-Z to CTRL-C. The
> questions you should be asking are:
> 1) Why are stale locks bad for the app?
Because if there is one, nobody else in our group can use the
app to assign IP addresses. I made it back in 1993 so that onl
On Wednesday 10 June 2009 00:49:16 per...@pluto.rain.com wrote:
> Martin McCormick wrote:
> > Thanks to all. In this case, I made SIGTSTP have the
> > same effect in the program that CTRL-C does (SIGINT) so now
> > either signal makes the application remove the lock and quit
> > gracefully.
>
Martin McCormick wrote:
> Thanks to all. In this case, I made SIGTSTP have the
> same effect in the program that CTRL-C does (SIGINT) so now
> either signal makes the application remove the lock and quit
> gracefully.
To each his own, I guess. To anyone familiar with the usual
Unix/Linux c
In the last episode (Jun 10), Polytropon said:
> On Tue, 9 Jun 2009 17:07:30 -0500, Dan Nelson wrote:
> > ^Z sends a SIGTSTP, which can be caught (or ignored, in your case).
> >
> > 18SIGTSTP stop process stop signal generated from
> >
Dan Nelson writes:
> ^Z sends a SIGTSTP, which can be caught (or ignored, in your case).
>
> 18SIGTSTP stop process stop signal generated from
> keyboard
> > According to
> >
> > % stty -g
> > ... status=14:stop=13:susp=1
On Wed, 10 Jun 2009 00:15:27 +0200, Erik Trulsson
wrote:
> Not quite. It indicates (according to stty(1)) that ^Z generates the
> SUSP character.
> The termios(4) manpage (referenced by stty(1)) says that
>
> SUSPIf the ISIG flag is enabled, receipt of the SUSP character causes
>
On Tue, 9 Jun 2009 17:07:30 -0500, Dan Nelson wrote:
> ^Z sends a SIGTSTP, which can be caught (or ignored, in your case).
>
> 18SIGTSTP stop process stop signal generated from
> keyboard
What is the way to get this information?
On Tue, Jun 09, 2009 at 11:42:15PM +0200, Polytropon wrote:
> On Tue, 09 Jun 2009 16:30:30 -0500, Martin McCormick
> wrote:
> > Which signal is sent to a process when one types ^z or
> > Control-z? It appears to be SIGSTOP and according to signal's
> > man page, this is one signal you can't catch
In the last episode (Jun 09), Polytropon said:
> On Tue, 09 Jun 2009 16:30:30 -0500, Martin McCormick
> wrote:
> > Which signal is sent to a process when one types ^z or Control-z? It
> > appears to be SIGSTOP and according to signal's man page, this is one
> > signal you can't catch.
^Z sends
On Tue, 09 Jun 2009 16:30:30 -0500, Martin McCormick
wrote:
> Which signal is sent to a process when one types ^z or
> Control-z? It appears to be SIGSTOP and according to signal's
> man page, this is one signal you can't catch.
You can check the setting with this command:
% stty -a
Which signal is sent to a process when one types ^z or
Control-z? It appears to be SIGSTOP and according to signal's
man page, this is one signal you can't catch.
I have an application with a signal handler I wrote and
I am trying to discourage folks typing CTRL-Z if it hangs
because that
14 matches
Mail list logo
