| Age | Commit message (Collapse) | Author |
|---|
|
Presently, revisions 5.1_p16-r10, 5.2_p26-r3 and bash-5.3_alpha-r2
refrain from declaring the genfun_set_win_title function at all in the
case that the tty belongs to sshd(8). This is to avoid cluttering the
shell's operating environment in situations where the decision is made
not to append 'genfun_set_win_title' to the PROMPT_COMMANDS array.
One might ask why it should not always be appended to the array. The
explanation for this is that Gentoo Linux does not exist in a vacuum;
not all operating systems default to initialising bash in such a way
that it can be assumed that the title will be set at each prompt (or at
all). Where SSH is involved, the server has no knowledge whatsoever of
the particulars of the client OS or its operating environment. This
would previously give rise to the following scenario.
1. User runs ssh(1) from non-Gentoo to connect to sshd(8) on Gentoo
2. The remote shell alters the window title
3. The user eventually exits the remote shell.
4. The window title is never restored to its prior value
Put simply, there is no way for the remote side to know what the
existing window title is, much less guarantee that it be restored on the
client side.
All that being said - and rather unsurprisingly - some Gentoo users will
care nothing for these considerations or are simply operating in a
homogenous environment where they are not an immediate concern. Try to
accommodate the wishes of such users more effectively by declaring the
function unconditionally. Consequently, they will have the option of
restoring Gentoo's historical behaviour in a somewhat straightforward
manner. That is, by setting PROMPT_COMMAND in ~/.bashrc or in an
/etc/bash/bashrc.d/ drop-in to the effect of the following.
PROMPT_COMMAND=(genfun_set_win_title)
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Bug: https://bugs.gentoo.org/934309
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Stands out more and gets repeated by Portage.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
makedev isn't supposed to exist where it is being checked here, but the
check itself vanishes in modern autoconf, and is thus unneeded for bash
5.2+.
Whitelist it just for the current version, which predates that.
Closes: https://bugs.gentoo.org/916480
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
* Drop shellcheck annotations. We don't use them in ::gentoo right now.
We might revisit that once shellcheck gains proper ebuild support, but right
now, they serve as noise.
* Fix readline version for <5.3_alpha.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Address a regression whereby the new initialisation files were composing
a PS1 prompt containing '\[' and '\]' for builds without readline
support. These sequences are normally used to denote sequences of
non-printing characters but are not treated specially unless readline
support is present. This came up 12 years ago as bug #432338. SpanKY's
solution at the time was to have the ebuild monkey-patch
/etc/bash/bashrc with sed, disabling colour support outright for the
USE="-readline" case. Unsurprisingly, moving the colour-related code to
a distinct bashrc.d snippet had prevented this method from being
effective.
After deliberating over the matter, I reached the conclusion that there
are already too many ebuilds containing overly brittle code of this
sort. Therefore, I decided to implement a runtime check instead.
Specifically, it is implemented as a trivial function, which works by
checking whether the direxpand shell option exists. This function is now
used in a twofold manner. Firstly, it is used to determine whether the
no_empty_cmd_completion and histappend shell options should be set in
etc/bash/bashrc (both of those require readline). Secondly, it it used
to determine whether the prompt should _not_ be colourised in
/etc/bash/bashrc.d/10-gentoo-color.bash, even in the case that the
terminal is understood to support colour.
Doing it this way has a few immediate benefits. No longer will colour
support be needlessly disabled outright; there was never any sense in
doing that. Instead, users that elect to compile bash without readline -
for whatever reason - may continue to enjoy full colour support with
only the prompt being rendered in monochrome. Moreover, the ebuild has
been simplified as a consequence of being able to completely drop the
section that defined sed_args before proceeding to clumsily modify
/etc/skel/.bashrc (with no effect, mind) and /etc/bash/bashrc.
Render /etc/bash/bashrc.d processing safer by unsetting the GLOBSORT
variable beforehand. This variable, which is introduced by
bash-5.3-alpha, allows for the user to affect the order in which words
occur as a result of pathname expansion. While there is no question that
the feature is useful, it must not be allowed to influence the order in
which files residing under /etc/bash/bashrc.d are processed. That is,
users must be able to expect that the files are processed in an order
that is based solely on the effective collation.
Remove st-256color from the list of terminals whitelisted for colour
support. There was no need for it to be there because it can already be
matched by the *color* globbing pattern.
The latest round of ebuilds have been cleaned up and should be slightly
easier to maintain from hereon. Further, they are now shellcheck-clean,
albeit with two warning categories having been disabled in the global
scope (so chosen because they aren't particularly helpful in the course
of evaluating ebuilds). Finally, version 9999 has been updated so as to
be abreast of these developments.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
