Closed magicant closed 3 months ago
[!IMPORTANT]
Auto Review Skipped
Draft detected.
Please check the settings in the CodeRabbit UI or the
.coderabbit.yaml
file in this repository. To trigger a single review, invoke the@coderabbitai review
command.You can disable this status message by setting the
reviews.review_status
tofalse
in the CodeRabbit configuration file.
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
This PR is quite messed up. I'm thinking of starting over with a more organized plan. 🤔
I'm thinking of defining Name
, Number
, and Spec
in yash_env::signal
.
Unresolved questions:
ProcessResult
(ProcessState
) contain Name
or Number
?
Number
in ProcessResult
would make conversion to/from ExitStatus
independent of System
ExitStatus
es is needed in the fg
and wait
built-ins and subshell starters.Name
in ProcessResult
would be needed for impl Display for ProcessResult
impl Display for ProcessResult
is only used in the jobs
built-in.ProcessResult
and ProcessState
should contain a signal Number
. System
should basically operate on Number
s. Signal Name
s are only used for human interfaces.Number
allow representing any (possibly non-existing) signal numbers?
kill
built-in and its underlying counterpart System::kill
needs to allow trying to send signals with arbitrary numbers, either a Number
has to represent any number or System::kill
has to accept raw integers rather than Number
s.Number
only represents a valid signal, System::signal_name_from_number
would be infallible, which is convenient when converting a ProcessState
for human-readable display.Number
only represents a valid signal, conversion from ExitStatus
to Number
would be fallible and need a System
. This is used in the kill
built-in.Number
can represent any number, conversion from ExitStatus
to Number
would be infallible, but fallible conversion is needed from Number
to Name
.Number
representing an invalid signal does not seem to be more useful than a Number
that rejects invalid signals.Condition
represent the signal as Number
or Name
?
Condition
s should specify the signal by Number
(assuming that a Number
can only represent a valid signal).Closing in favor of #367
This is part of #353.
This PR also adds support for real-time signals on some platforms.
Signal
definitionSignal
from and to raw numbers inSystem
SigSet
fromSystem
Move conversion from signal number toCondition
out ofimpl std::str::FromStr for Condition
ProcessState
and nix'sWaitStatus
impl TryFrom<ProcessState> for ExitStatus
withSystemEx::exit_status_for_process_state
impl From<Signal> for ExitStatus
withSystemEx::exit_status_for_signal
impl TryFrom<ExitStatus> for Signal
Signal
Additional todo:
ProcessState
so we don't have to unwrap the result ofSystemEx::exit_status_for_process_state
ProcessResult::{Exited,Signaled,Stopped}
which is guaranteed to have a corresponding exit status.Subshell::start_and_wait
(and maybe some other functions) should return the new enum. → #366