Commit Graph
5 Commits
Author SHA1 Message Date
Chris Lindee 2d738a0aee profile/systemd-osc-context: Enforce length limits
UAPI.15 limits the length of fields; adhere to them.

References:
 [0] https://uapi-group.org/specifications/specs/osc_context/#syntax-in-abnf
2026-02-16 03:15:53 -06:00
Chris Lindee 72e71897f9 profile/systemd-osc-context: Remove invalid octets
UAPI.15 requires:
* No C0 Control Characters (`\x00-\x1f`)
* No DEL character (`\x7f`)

The following would be nice, but requires a `sed` implementation that is
aware of UTF-8: `-e $'y/\x00-\x1f\x7f/␀-␟␡/'`.

References:
 [0] https://uapi-group.org/specifications/specs/osc_context/#general-syntax
2026-02-16 03:15:53 -06:00
Chris Lindee 6a46846871 profile/systemd-osc-context: Bring escape up to spec
UAPI.15 requires:
* `\` to be replaced with `\x5c`
* `;` to be replaced with `\x3b`

References:
 [0] https://uapi-group.org/specifications/specs/osc_context/#general-syntax
2026-02-16 03:15:53 -06:00
Chris Lindee b88ab1c2dd profile/systemd-osc-context: Acknowledge uncertainty
Bash does not provide an easy way to discern if an exit status came from
a signal, or was a legitimate non-zero exit (i.e. a failure).  It can be
done, by using job control or by invoking another program; however, such
approaches require modifying the command entered by a user and are, thus,
invasive and risky.

Since an exit status of 129 on a command could either indicate it exited
cleanly with `exit(129)` or was interrupted by `SIGHUP`, the osc context
should report both possibilities, to acknowledge our uncertainty.  Given
we have no idea what happened, besides an unsuccessful exit, the exit is
described as `exit=failure`.

Moreover, discerning between an `interrupt` and a `crash` with a command
likely involves categorizing every signal.  It is fairly obvious `SIGINT`
is an interrupt and also obvious, IMO, that `SIGSEGV` is a crash.  Avoid
the complication (and potential disagreements) by using the encompassing,
generic value — one that remains true if no signal occurred.

References:
 [0] https://stackoverflow.com/a/66431355
2026-02-16 03:15:51 -06:00
Chris Lindee 3de092fad7 profile/systemd-osc-context: Bring exit up to spec
The exit status should be compared against 128 — not 127 — as the Bash
manual, under the EXIT STATUS section, states [0]:

    When a command terminates on a fatal signal N, bash uses the value
    of 128+N as the exit status.

    If a command is not found, the child process created to execute it
    returns a status of 127.  If a command is found but is not
    executable, the return status is 126.

Furthermore, UAPI.15 specifies the `signal` value must be the symbolic
signal name, not a numerical value [1].  Luckily, POSIX.1-2008 ensures
the shell must supply `kill -l`, which must be able to convert `$?` to
the signal that could cause such an exit in that shell [2].  It should
be noted that only a select handful of signals have a standard numeric
value; all others are implementation-defined [3].  This is why UAPI.15
requires the symbolic name, as the value may differ across systems.

Notably, not every value above 128 needs to correspond to a signal; on
my Linux system, only exit codes 129–192 indicate a signal.  Again, we
can use `kill -l`, which will exit non-zero when an exit code does not
come from a signal (plus 128) [4].

Signal 0 (which would correspond to exit code 128) is reserved for the
null signal, per POSIX.1-2008 [5], and therefore will never be an exit
signal.

This change brings the implementation into compliance.

References:
 [0] https://www.man7.org/linux/man-pages//man1/bash.1.html#EXIT_STATUS
 [1] https://uapi-group.org/specifications/specs/osc_context/
 [2] https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/utilities/kill.html#:~:text=The%20letter%20ell
 [3] https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/utilities/kill.html#:~:text=The%20effects%20of%20specifying%20any%20signal_number
 [4] https://www.man7.org/linux/man-pages//man1/bash.1.html#:~:text=false%20if%20an%20error%20occurs%20or%20an%20invalid%20option%20is%20encountered
 [5] https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/basedefs/signal.h.html#:~:text=The%20value%200%20is%20reserved%20for%20use%20as%20the%20null%20signal
2026-02-16 03:14:43 -06:00