Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Zsh Guide chapter 5 (substitutions)
- X-seq: zsh-users 4159
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Richard Curnow <Richard.Curnow@xxxxxx>, zsh-users@xxxxxxxxxx
- Subject: Re: Zsh Guide chapter 5 (substitutions)
- Date: Tue, 21 Aug 2001 15:34:21 +0000
- In-reply-to: <20010821152154.A8668@xxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20010815230024.3E7F614284@xxxxxxxxxxxxxxxxxxxxxxxx> <20010821152154.A8668@xxxxxxxxxxxxxxxx>
On Aug 21, 3:21pm, Richard Curnow wrote:
}
} On page 74, 2nd para from the end,
}
} It seems a bit odd to signal a process to restart; why can't the
} operating system just restart it when you ask? The real answer is
} probably that signals provide an easy way for you to talk to the
} operating system without grovelling around in the dirt too much.
}
} I think it's to provide a way for a process to save and restore state
} across the suspension, by installing handlers for SIGTSTP and SIGCONT.
Saving and restoring state is one reason that there are four signals to
stop a process (STOP, TSTP, TTIN, TTOU). However, it's not the reason
that a signal is used for SIGCONT; Peter's more on target with that one.
There's no such thing as a SIGCONT handler, by the way. The process
just picks up where it left off (possibly with system calls interrupted
depending on the operating system). A typical TSTP handler looks like
save_state();
kill(getpid(), SIGSTOP); /* STOP is not catchable */
restore_state();
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
Messages sorted by:
Reverse Date,
Date,
Thread,
Author