#[non_exhaustive]pub enum Signal {
Hangup,
ForceStop,
Interrupt,
Quit,
Terminate,
User1,
User2,
Custom(i32),
}Expand description
A notification (signals or Windows control events) sent to a process.
This signal type in Watchexec is used for any of:
- signals sent to the main process by some external actor,
- signals received from a sub process by the main process,
- signals sent to a sub process by Watchexec.
On Windows, only some signals are supported, as described. Others will be ignored.
On Unix, there are several “first-class” signals which have their own variants, and a generic
Custom variant which can be used to send arbitrary signals.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
Hangup
Indicate that the terminal is disconnected.
On Unix, this is SIGHUP. On Windows, this is ignored for now but may be supported in the
future (see #219).
Despite its nominal purpose, on Unix this signal is often used to reload configuration files.
ForceStop
Indicate to the kernel that the process should stop.
On Unix, this is SIGKILL. On Windows, this is TerminateProcess.
This signal is not handled by the process, but directly by the kernel, and thus cannot be intercepted. Subprocesses may exit in inconsistent states.
Interrupt
Indicate that the process should stop.
On Unix, this is SIGINT. On Windows, this is ignored for now but may be supported in the
future (see #219).
This signal generally indicates an action taken by the user, so it may be handled differently than a termination.
Quit
Indicate that the process is to stop, the kernel will then dump its core.
On Unix, this is SIGQUIT. On Windows, it is ignored.
This is rarely used.
Terminate
Indicate that the process should stop.
On Unix, this is SIGTERM. On Windows, this is ignored for now but may be supported in the
future (see #219).
On Unix, this signal generally indicates an action taken by the system, so it may be handled differently than an interruption.
User1
Indicate an application-defined behaviour should happen.
On Unix, this is SIGUSR1. On Windows, it is ignored.
This signal is generally used to start debugging.
User2
Indicate an application-defined behaviour should happen.
On Unix, this is SIGUSR2. On Windows, it is ignored.
This signal is generally used to reload configuration.
Custom(i32)
Indicate using a custom signal.
Internally, this is converted to a nix::Signal
but for portability this variant is a raw i32.
Invalid signals on the current platform will be ignored. Does nothing on Windows.
The special value 0 is used to indicate an unknown signal. That is, a signal was received
or parsed, but it is not known which. This is not a usual case, and should in general be
ignored rather than hard-erroring.
§Examples
use watchexec_signals::Signal;
use nix::sys::signal::Signal as NixSignal;
assert_eq!(Signal::Custom(6), Signal::from(NixSignal::SIGABRT as i32));On Unix the from_nix method should be preferred if converting from
Nix’s Signal type:
use watchexec_signals::Signal;
use nix::sys::signal::Signal as NixSignal;
assert_eq!(Signal::Custom(6), Signal::from_nix(NixSignal::SIGABRT));Implementations§
Source§impl Signal
impl Signal
Sourcepub fn to_nix(self) -> Option<NixSignal>
pub fn to_nix(self) -> Option<NixSignal>
Converts to a nix::Signal if possible.
This will return None if the signal is not supported on the current platform (only for
Custom, as the first-class ones are always supported).
Sourcepub fn from_nix(sig: NixSignal) -> Self
pub fn from_nix(sig: NixSignal) -> Self
Converts from a nix::Signal.
Source§impl Signal
impl Signal
Sourcepub fn from_unix_str(s: &str) -> Result<Self, SignalParseError>
pub fn from_unix_str(s: &str) -> Result<Self, SignalParseError>
Parse the input as a unix signal.
This parses the input as a signal name, or a signal number, in a case-insensitive manner.
It supports integers, the short name of the signal (like INT, HUP, USR1, etc), and
the long name of the signal (like SIGINT, SIGHUP, SIGUSR1, etc).
Note that this is entirely accurate only when used on unix targets; on other targets it
falls back to a hardcoded approximation instead of looking up signal tables (via nix).
assert_eq!(Signal::Hangup, Signal::from_unix_str("hup").unwrap());
assert_eq!(Signal::Interrupt, Signal::from_unix_str("SIGINT").unwrap());
assert_eq!(Signal::ForceStop, Signal::from_unix_str("Kill").unwrap());Using FromStr is recommended for practical use, as it will also parse Windows control
events, see Signal::from_windows_str.
Sourcepub fn from_windows_str(s: &str) -> Result<Self, SignalParseError>
pub fn from_windows_str(s: &str) -> Result<Self, SignalParseError>
Parse the input as a windows control event.
This parses the input as a control event name, in a case-insensitive manner.
The names matched are mostly made up as there’s no standard for them, but should be familiar to Windows users. They are mapped to the corresponding unix concepts as follows:
CTRL-CLOSE,CTRL+CLOSE, orCLOSEfor a hangupCTRL-BREAK,CTRL+BREAK, orBREAKfor a terminateCTRL-C,CTRL+C, orCfor an interruptSTOP,FORCE-STOPfor a forced stop. This is also mapped toKILLandSIGKILL.
assert_eq!(Signal::Hangup, Signal::from_windows_str("ctrl+close").unwrap());
assert_eq!(Signal::Interrupt, Signal::from_windows_str("C").unwrap());
assert_eq!(Signal::ForceStop, Signal::from_windows_str("Stop").unwrap());Using FromStr is recommended for practical use, as it will fall back to parsing as a
unix signal, which can be helpful for portability.