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
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
Let's do the check early and skip most of the file if appropriate. Also, treat
missing $TERM same as "dumb". We're almost certainly at a dump terminal in that
case.
In https://github.com/systemd/systemd/issues/39114 users are reporting
that our script overrides PROMPT_COMMAND that they had. After looking
at /etc/bashrc in Fedora, I see that it only sets PROMPT_COMMAND if
[ -z "$PROMPT_COMMAND" ]. Let's adjust the script so this continues to
work.
Fixes https://github.com/systemd/systemd/issues/39114.
(This is a bit of a stretch. 39114 was originally about SecureCRT,
but that was resolved in SecureCRT. But there was a lot of dicussion
about the prompt being overriden, which this commit should fix.)
While we can safely assume that `/proc/sys/kernel/random/boot_id`
exists, the same can't be said for `/etc/machine-id` in environments
where systemd is installed, but not running. An example would be OCI
containers like with the official Arch Linux image, see [0].
Without this check the prompt would constantly output `/etc/machine-id:
no such file or directory` with the OSC events introduced in dadbb34
(v258).
[0] https://gitlab.archlinux.org/archlinux/archlinux-docker/-/issues/107
Frantisek Sumsal
Chris Lindee
Lennart Poettering
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Justin Kromlinger