Since Sericea is an official variant of Fedora, it should have an
official welcome message like the other ones.
https://github.com/containers/toolbox/pull/1293
Signed-off-by: Jakub Sierżęga <jakub.sierzega@comarch.com>
Otherwise https://www.shellcheck.net/ would complain:
Line 86:
term_just_first_character="${TERM%$term_without_first_character}"
^-- SC2295 (info): Expansions inside
${..} need to be quoted
separately, otherwise they match
as patterns.
See: https://www.shellcheck.net/wiki/SC2295
CentOS Stream 9 has ShellCheck-0.8.0, while so far the 'unit tests' were
being run on Fedora 36, which only has ShellCheck-0.7.2.
This is a step towards testing on CentOS Stream 9.
https://github.com/containers/toolbox/pull/1200
Otherwise, every zsh instance on Fedora Kinoite and Silverblue was
running into:
/etc/profile.d/toolbox.sh:30: bad substitution
... because case modification with "${VARIANT_ID^}" is undefined in
POSIX shell [1], and doesn't work with Z shell.
Fedora Silverblue got its own PRETTY_NAME (and VARIANT and VARIANT_ID)
starting from Fedora 32 [2]. Therefore, it's better to use PRETTY_NAME
and let the downstream distributor of the host operating system decide
how it should be presented to the user, instead of coming up with a
custom string. eg., PRETTY_NAME isn't the same as "Fedora $VARIANT" on
Fedora Silverblue.
One nice side-effect of this is that while VARIANT and VARIANT_ID are
optional fields, PRETTY_NAME has a well-defined fallback value of
'Linux' [3]. This makes this a little less specific to Fedora Kinoite
and Silverblue.
The rest of the welcome text was reformatted to prevent it from getting
too wide depending on the contents of PRETTY_NAME.
Fallout from 3641a0032f
[1] https://www.shellcheck.net/wiki/SC3059
[2] https://pagure.io/workstation-ostree-config/c/c18ef957d11862d32f362722931dbfdf1f5beb0d
[3] https://www.freedesktop.org/software/systemd/man/os-release.htmlhttps://github.com/containers/toolbox/issues/1017
Some OSTree based systems, such as Endless OS, don't ship with
/usr/lib/os-release, and the os-release(5) manual says [1]:
The file /etc/os-release takes precedence over /usr/lib/os-release.
Applications should check for the former, and exclusively use its data
if it exists, and only fall back to /usr/lib/os-release if it is
missing.
[1] https://www.freedesktop.org/software/systemd/man/os-release.htmlhttps://github.com/containers/toolbox/pull/692
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
