Currently, on Fedora, a nested instance of Z shell inside a Toolbox
container renders the PS1 like this:
\[\]⬢\[\][\u@\h \W]\$
Notice that Z shell doesn't like that the terminal escape sequences
for the foreground colour are wrapped in '\[' and '\]' [1], and doesn't
understand the special characters like '\u' and '\h'.
This is fixed by making the PS1 specific to the shell. The prompt for
Z shell is based on the default prompt used on Fedora, just like the
one for Bash.
Note that this only affects nested instances of Z shell because of the
way the start-up scripts for Z shell are written on Fedora. Toolbox
invokes top-level shell as a login shell, and for those the PS1 set by
profile.d/toolbox.sh is overwritten by the operating system's default
in /etc/zshrc. See:
https://bugzilla.redhat.com/show_bug.cgi?id=2026749
[1] Commit bc1a816ea3https://github.com/debarshiray/toolbox/issues/190https://github.com/containers/toolbox/pull/936
The fedora-toolbox:32 image is the first of images in the renamed
toolbox image repository[0]. With the change we can drop the
pull_image_old() function because it was kept only for the old image.
Seems like newer version of ShellCheck checks the validity of variable
names (SC2153). This caused a false positive, so I silenced it.
[0] https://github.com/containers/toolbox/pull/615https://github.com/containers/toolbox/pull/780
While Toolbox's test suite explicitly uses --shell=sh when running
shellcheck(1) on profile.d/toolbox.sh, external tools like Coverity
can't be expected to do the same. So they complain:
Line 1:
[ "$BASH_VERSION" != "" ] || [ "$ZSH_VERSION" != "" ] || return 0
^-- SC2148: Tips depend on target shell and yours is unknown. Add a
shebang or a 'shell' directive.
See: https://github.com/koalaman/shellcheck/wiki/SC2148https://github.com/containers/toolbox/pull/673
Fedora's /etc/bashrc sets the PROMPT_COMMAND environment variable to
__vte_prompt_command when running inside a VteTerminal. This becomes a
problem if the __vte_prompt_command shell function is missing because
/etc/profile.d/vte.sh itself is absent [1], which is the case with the
Red Hat Universal Base Image.
This tricks the code in /etc/bashrc into not doing that.
[1] https://pagure.io/setup/pull-request/23https://github.com/containers/toolbox/pull/667
All the fields defined in /usr/lib/os-release were being injected into
the shell as environment variables. This is unintentional. Some of the
variables have relatively generic names, and having them in the
environment can lead to unexpected surprises.
Fallout from c6e37cdef3https://github.com/containers/toolbox/pull/623
On Ubuntu, both /usr/share/terminfo and /lib/terminfo can have contents, and xterm-256color is at /lib/terminfo (provided by ncurses-base package) while xterm+256color is at /usr/share/terminfo (provided by ncurses-term package). This PR checks both directory to suppress the warning.
It tries to loosely mimic ncurses to look up a terminfo entry for the
current terminal, as mentioned in the terminfo(5) manual. Unlike
ncurses, it doesn't handle TERMINFO_DIRS, though, to avoid parsing an
array of directories for the sake of simplicity.
Every line of code in this file is part of the interactive shell's
start-up sequence, which makes it a trade-off between correctness and
speed. Therefore, the purpose of this warning is not to exhaustively
catch all possible corner cases, but to serve as a convenience in the
majority of cases. Ultimately, if someone is using an exotic terminal
set-up, then a missing warning is a minor price to pay in order to not
slow things down for the vast majority of users who don't.
Based on code written by Mert Alp Taytak:
https://github.com/containers/toolbox/pull/515https://github.com/containers/toolbox/issues/505
The Silverblue welcome message was being displayed incorrectly on
other OSTree based OS's (Fedora Atomic Host, Fedora CoreOS, etc).
Note that none of the stable Silverblue releases that have shipped so
far (ie., until Silverblue 30) have had 'silverblue' as the VARIANT_ID.
This makes the check a bit more convoluted that it should have been.
https://github.com/debarshiray/toolbox/pull/236
... because of its likeness to the Toolbox logo. Note that the magenta
foreground colour is requested through a terminal escape sequence with
SGR parameters [1]. The specific colour code for magenta is 35.
The main body of the PS1 needs to be split out to prevent Bash from
complaining:
bash: printf: missing unicode digit for \u
[1] https://en.wikipedia.org/wiki/ANSI_escape_codehttps://github.com/debarshiray/toolbox/pull/150
The shell start-up scripts are where the PS1 is meant to be set. So
far, the absence of a toolbox-specific start-up script was being worked
around by setting the PS1 as part of the 'podman exec' invocation. This
came with certain limitations. eg., using su(1) or sudo(8) to get a
root shell can overwrite the PS1 set during 'podman exec' with a value
set by the operating system's existing start-up scripts depending on
which environment variables were being retained.
Now that the toolbox has it's own /etc/profile.d/toolbox.sh start-up
script, it's time to move the PS1 to its rightful home.
Since the start-up script and /run/.toolboxenv are present in older
toolbox containers, this change should be fully backwards compatible
and lead to a more robust PS1 without breaking older containers.
https://github.com/debarshiray/toolbox/pull/148
This is better than setting an environment variable like
TOOLBOX_CONTAINER with 'podman create' because, unlike environment
variables, it can't be unset later by commands like su(1) or sudo(8).
One nice side-effect of doing it inside 'toolbox enter' is that it
will automatically work with older toolbox containers.
A subsequent commit will switch to using the /etc/profile.d/toolbox.sh
start-up script to set the PS1 instead of doing it as part of the
'podman exec' invocation. Having the identification mechanism work with
older toolbox containers is important to avoid breaking the PS1 for
backwards compatibility.
This reverts commit c7b7fa1867https://github.com/debarshiray/toolbox/pull/148
This is a lot more clear and explicit than TOOLBOX_PATH, which is more
of an implementation detail to bind mount the toolbox script inside the
toolbox container.
https://github.com/debarshiray/toolbox/pull/142
