| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Nothing references "bash-5.3-empty-PROMPT_COMMAND.patch" anymore.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
This commit introduces the following versions.
- 5.2_p37-r5
- 5.3_p3-r3
- bash-5.4_alpha_pre20250918-r2 (replacing -r1)
They improve the window title setting behaviour by using the ${param@P}
form of expansion to expand "\u@\h \W" as a prompt string. A notable
consequence of this is that, upon switching to the home directory, the
current working directory will be shown as the <tilde> character again.
The value of PROMPT_DIRTRIM is now respected. If this variable is unset,
the use of the \W prompt string escape will prevail, with the current
working directory typically being shown as its basename. If set to 0 or
greater, \w will be used instead, which may be trimmed. This means that
the title can be made to show the full path by setting PROMPT_DIRTRIM=0.
Also, whitelist xterm-ghostty for XTWINOPS support.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Drop the "15-gentoo-bashrc-check.bash" drop-in, whose retirement was
overdue. Do so by:
- dropping 5.2_p37-r3
- dropping the 5.4 snapshots, except for the latest
- revision-bumping the latest 5.4 snapshot
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Nothing references this file anymore.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Nothing references this file anymore.
$ grep -F /10-gentoo-title.bash *.ebuild | wc -l
0
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Drop 5.2_p37, along with the files that it was uniquely referencing.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
This commit introduces 5.2_p37-r4 and bash-5.3_p3-r1, as well as
revising bash-9999. The effective changes are described herewith.
Install a new /etc/profile.d drop-in, named "00-prompt-command.sh". It
serves to initialise the PROMPT_COMMAND variable as early as is
conveniently possible, provided that bash is acting as a login shell.
Install a revision of the /etc/bash/bashrc file that refrains from
initialising the PROMPT_COMMAND variable, provided that bash is acting
as a login shell. Along with the aforementioned change, this amounts to
a simplified interpretation of GitHub PR #42626. Though not a common
practice, some /etc/profile.d drop-ins (such as vte-2.91.sh) need to be
able to manipulate PROMPT_COMMAND and had hitherto been stymied by
bashrc proceeding to unconditionally clobber it.
Finally, refrain from installing 15-gentoo-bashrc-check.bash to
/etc/bash/bashrc.d. At the time of its introduction, I recommended that
it should exist for no longer than a year. Its removal is overdue.
Reported-by: Krzesimir Nowak <knowak@microsoft.com>
Part-of: https://github.com/gentoo/gentoo/pull/42626
Closes: https://github.com/gentoo/gentoo/pull/42626
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
The top of FILESDIR has become a little unwieldy. In advance of
submitting a patch that will introduce yet more files to be tracked, I
thought that it would be a good opportunity to conduct a minor
re-organisation. To that end, this commit relocates the skeleton files
to a sub-directory.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
* Fix sourcing files from /sys (which affects sys-kernel/ugrd)
I pulled this one out of a 'devel' push.
Note https://lists.gnu.org/archive/html/bug-readline/2025-07/msg00001.html wrt Chet not discouraging
such cherry-picking.
Thanks to zen_desu for confirming it fixes the ugrd issue too.
* Fix crash w/ empty PROMPT_COMMAND
Signed-off-by: Sam James <sam@gentoo.org>
|
|
backported fix
While backporting commit e327891b52513bef0b34aac625c44f8fa6811f53 from
the devel branch, I accidentally left in a line that should have been
removed, resulting in bash occasionally segfaulting while using the -e
option of the read builtin. Address that mistake.
Additionally, correct a typo in the commit message of one of the other
patches ("incoprorate" > "incorporate").
Fixes: 0193ee11e3aa99775c546ac63346ec05c01a51f7
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
The only difference between -r1 and -r2 is that the latter incorporates
a slightly revised 10-gentoo-color.bash drop-in. Hence, there's no
particular reason to retain the former.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
This revision brings two changes to the 10-gentoo-color.bash drop-in.
Firstly, try to match the value of TERM against the whitelist of
terminals known to support colour, only employing tput(1) as a last
resort. Given that the list is now a well-curated one, it makes sense to
try to forgo the expense of executing an external utility.
Secondly, micro-optimise the method by which readline support is
detected. It is ever so slightly faster to run ( ! shopt -u direxpand )
as opposed to [[ ! $(shopt -p direxpand) ]].
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Currently, the gentoo repo is carrying two identical patches:
- bash-5.2_p32-read-delimiter-in-invalid-mbchar.patch
- bash-5.2_p32-invalid-continuation-byte-ignored-as-delimiter-1.patch
However, the second one has a more informative commit message. Drop the
first and have the 5.2_p37 ebuild apply the second.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Backport two supplemental patches from the devel branch so as to address
some remaining defects affecting the revised read_mbchar() function.
For further information, please refer to pitfall #65 at
https://mywiki.wooledge.org/BashPitfalls, along with the commit messages
of the patches themselves. The read builtin should now behave as well as
it did in 4.4, and as well as it will in the upcoming 5.3-rc2 release.
Whitelist the Contour and Ghostty terminal emulators for colour support.
In the case that colour support is detected, refrain from defining any
aliases for which either an alias or function is found already to exist
by the same name. The motivation for making this change stems from a
discussion at https://forums.gentoo.org/viewtopic-t-1170323.html.
Define COLORTERM=1 in the environment of dircolors(1). The methods by
which dircolors determines whether colour is supported are inferior to
those of Gentoo. Indeed, at the point that dircolors is executed, it
will already have been determined that colour is supported with some
confidence. Defining COLORTERM=1 coerces dircolors into presuming so in
turn, increasing the range of terminal emulators for which Gentoo is
able to define LS_COLORS.
Define _cwd as a local variable in genfun_set_win_title(). Consequently,
_cwd is no longer a reserved variable name from the perspective of the
user.
Whitelist the Contour terminal emulator for XTWINOPS support.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Michael Mair-Keimberger <mmk@levelnine.at>
Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
This reverts commit 92328f4b82f4d1c6c48a6507ee5a81e13cbb660f.
A user reported in #gentoo:
```
[ ok ]
* Applying bash-5.2_p21-wpointer-to-int.patch ...
/var/tmp/portage/app-shells/bash-5.2_p37/temp/environment: line 702: /var/tmp/portage/app-shells/bash-5.2_p37/files/bash-5.2_p21-wpointer-to-int.patch: No such file or directory
/var/tmp/portage/app-shells/bash-5.2_p37/temp/environment: line 705: /var/tmp/portage/app-shells/bash-5.2_p37/files/bash-5.2_p21-wpointer-to-int.patch: No such file or directory
[ !! ]
* ERROR: app-shells/bash-5.2_p37::gentoo failed (prepare phase):
* patch -p1 -p0 failed with /var/tmp/portage/app-shells/bash-5.2_p37/files/bash-5.2_p21-wpointer-to-int.patch
*
```
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Michael Mair-Keimberger <mmk@levelnine.at>
Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
|
|
This backports a fix for an issue whereby the delimiter employed by the
read builtin is ignored in the case that it is part of an invalid
multibyte sequence. Further details can be found within the patch.
[sam: Keep -r0.]
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Compared to bash-5.2_p26-memory-leaks.patch, this drops a hunk for
builtins/evalstring.c as the open_redir_file issue is fixed in patch 31
upstream for bash-5.2.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
The 5.2_p26-r7 revision contained (harmless) changes that were not yet
intended to be applied to the gentoo repo, owing to a miscommunication
between Sam and I. This commit applies the changes as were eventually
intended and, for this reason, the remainder of this commit message
shall be written accordingly. That is, as if no preceding commit had
been involved to get to this point.
...
Xterm is able to push and pop window titles to a stack and there are
several other terminal emulators that can do so, such as alacritty, foot
and tmux. Take advantage of this feature so as to reinstate automatic
window title setting in the case that the PTY is owned by sshd(8).
Unfortunately, there are a lot of terminal emulators that falsely
advertise themselves as being xterm-compatible, making it impossible to
reliably identify xterm itself. However, we can reliably identify
alacritty, foot and tmux so let's support those three to begin with.
The benefits conferred upon tmux are of a distinct nature, since it was
already the case that it was being whitelisted for title support.
Specifcally, the benefits are as follows:
- title restoration is supported even where tmux(1) is launched prior to ssh(1)
- title restoration is supported for nested instances of tmux
It should be noted that tmux does not forward titles to the outer
terminal emulator by default. Such can be arranged for with the
following configuration.
set -g set-titles on
set -g set-titles-string "#T"
Don't enable title setting for GNU screen in the case that the PTY is
owned by sshd(8) and screen(1) was launched prior to connecting with
ssh(1). This is a distinction that can be made by checking whether the
WINDOW variable is set in the environment.
Have the genfun_set_win_title function export a variable named
SHELL_SETS_TITLE upon the first occasion that it is called. Presently,
nothing responds to this variable but the intention is to eventually
have portage respond to it. Portage implements heuristics and behaviours
that are horrifyingly broken. For instance, it considers the mere
presence of PROMPT_COMMAND as somehow proving that the interactive shell
uses it for nothing other than to set the title, despite the fact that:
- the contents of PROMPT_COMMAND may be arbitrarily defined by the user
- the purpose of PROMPT_COMMAND is whatever the user may wish it to be
- nobody in their right mind would export PROMPT_COMMAND
- PROMPT_COMMAND can be an array since 5.1 (making it unexportable)
Worse still, in the event that portage is somehow able to ascertain the
value of PROMPT_COMMAND, it takes its first element and proceeds to
inject its value into an invocation of either sh, $SHELL or bash -c,
irrespective of the consequences. No, I'm not making this up.
As such, the purpose of the SHELL_SETS_TITLE variable is to act as a
straightforward indicator that an interactive shell exists as an
ancestor process and that it will take it upon itself to set a fresh
window title upon its primary prompt being displayed.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Xterm is able to push and pop window titles to a stack and there are a
few other terminal emulators that can do so (alacritty and foot being
the only ones that I am aware of at the present time). Take advantage of
this feature so as to reinstate automatic window title setting in the
case that the PTY is owned by sshd(8). Unfortunately, there are a lot of
terminal emulators that falsely advertise themselves as being
xterm-compatible, making it impossible to reliably identify xterm
itself. However, we can reliably identify alacritty and foot so let's
support those two to begin with.
Have the genfun_set_win_title function export a variable named
SHELL_SETS_TITLE upon the first occasion that it is called. Presently,
nothing responds to this variable but the intention is to eventually
have portage respond to it. Portage implements heuristics and behaviours
that are horrifyingly broken. For instance, it considers the mere
presence of PROMPT_COMMAND as somehow proving that the interactive shell
uses it for nothing other than to set the title, despite the fact that:
- the contents of PROMPT_COMMAND may be arbitrarily defined by the user
- the purpose of PROMPT_COMMAND is whatever the user may wish it to be
- nobody in their right mind would export PROMPT_COMMAND
- PROMPT_COMMAND can be an array since 5.1 (making it unexportable)
Worse still, in the event that portage is somehow able to ascertain the
value of PROMPT_COMMAND, it takes its first element and proceeds to
inject its value into an invocation of either sh, $SHELL or bash -c,
irrespective of the consequences. No, I'm not making this up.
As such, the purpose of the SHELL_SETS_TITLE variable is to act as a
straightforward indicator that an interactive shell exists as an
ancestor process and that it will take it upon itself to set a fresh
window title upon its primary prompt being displayed.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
In bug #934732, Sven Wegener requested for bash to refrain from setting
the "internal" window title. That is, the window title (%t) of GNU
screen and the window_name (#W) of tmux. A patch was attached to the
bug, which I acknowledged and which was subsequently applied by Sven.
Unfortunately - and perhaps owing to my eagerness to have the matter be
resolved - I did not notice that the patch introduces a regression. The
regression is that both screen and tmux are no longer exempted from the
sshd(8) check, resulting in neither the hardstatus (%h) being set for
the former, nor the pane_title (#T) for the latter. This commit restores
the intended behaviour.
In comment #10 of bug #550104, Heui-mun Park makes a compelling case
that the "\033]0;" variant of the Set Text Parameters sequence should be
preferred over other variants. The difference is that it sets the "icon
name" in addition to the "window title". Indeed, I have found that most
applications that employ the sequence make use of this more
comprehensive variant. For many users, such a distinction would amount
to being little more than an artifact of history. Nevertheless, it makes
perfect sense for 10-gentoo-title.bash to be aligned with the practices
of others in this regard. Make it so.
Improve the commentary in 10-gentoo-title.bash, along with the accuracy
and utility of the information conveyed by the ewarn comands in the
ebuilds.
Have the live ebuild (version 9999) install 15-gentoo-bashrc-check.bash,
just as the other recent ebuilds do. It's simpler from a maintenance
standpoint for there to be as few differences between them as is
possible.
Fixes: 9ff9f8199ccf9d55fb1cf066cbbc791101894ab0
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
The k escape sequence changes the internal window title of screen and
tmux, which is an alias given to the window by the user. The alias can
be used to reference the window in internal commands, e.g. by using
"select <alias>" in screen or "select-window -t <alias>" in tmux to
switch to a window by name, and should not be updated by commands
running inside of screen and tmux.
Closes: https://bugs.gentoo.org/934732
Signed-off-by: Sven Wegener <swegener@gentoo.org>
|
|
Some users choose to manage /etc/bash/bashrc directly and disregard any
of its updates outright. Additionally, some users have ~/.bashrc as a
copy of ${FILESDIR}/bashrc which is either exact or which contains only
trivial modifications, meaning that the bashrc.d drop-ins end up being
sourced twice. For both of these scenarios, users will presently
encounter a diagnostic message indicating that the genfun_has_readline
function does not exist. In turn, that is because the function is
declared by /etc/bash/bashrc, while also being used by
/etc/bash/bashrc.d/10-gentoo-color.bash.
Since there is no particular need for 10-gentoo-color.bash to be coupled
in this manner, jettison the function. Instead, have bashrc consider the
exit status of the "shopt -s no_empty_cmd_completion" command and have
10-gentoo-color.bash perform its own test.
Additionally, implement a new bashrc.d drop-in named
"15-gentoo-bashrc-check.bash". Its purpose is to check whether ~/.bashrc
exists as a copy of ${FILESDIR}/bashrc and instruct the user as to how
to remedy the situation. After performing the check, it touches a file
under ${TMPDIR} so that it can subsequently avoid driving the user mad.
I recommend that this drop-in be removed one year hence. I disliked
having to do this but consider it to be in the public interest.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Bug: https://bugs.gentoo.org/934523
Signed-off-by: Sam James <sam@gentoo.org>
|
|
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>
|
|
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>
|
|
[ef]grep aliases
The ebuilds that install "${FILESDIR}/bashrc.d/10-gentoo-color.bash"
were neglecting to prefixify it. That is, to replace instances of "/etc"
with "${EPREFIX}/etc". After reviewing the prefix eclass, I found it to
be wanting in all of its chief respects: interface, correctness, safety
and robustness. Consequently, I rejected the notion of using it on
principle. Instead, I elected to create a custom function, which is now
used to prefixify both "bashrc" and "10-gentoo-color.bash". Among its
virtues are that it writes an amended stream to the standard output,
which may be directly processed by newins.
Whitelist st-256color for Set Text Parameters support. Also, add it to
the list of terminals known to support colour.
Drop the egrep and fgrep aliases again. Previously, they had been
dropped by Mike Gilbert but were inadvertently re-introduced through my
being thorough rather than prudent. Given that both are non-standard, I
certainly have no wish to provide users with any additional excuses for
their continued use.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Fixes: 268b2e7c07d97bd9e833d239d786a0314c3b09ec
Signed-off-by: Sam James <sam@gentoo.org>
|
|
This commit simplifies /etc/bash/bashrc by separating out the
functionality that is relatively complicated - perhaps even opinionated
on the part of Gentoo - into files that are installed to the
/etc/bash/bashrc.d directory. The intention is to preserve the overall
Gentoo flavour, while making it easier for users to customise their
operating environment than was the case before, and to be able to easily
suppress functionality that they may not wish for. The exact changes are
described herewith.
No longer will a superfluous error message be printed in the case that
bash was not compiled with readline support.
Files within /etc/bash/bashrc.d must now have a suffix of either ".sh"
or ".bash" in order to be sourced. This better reflects the way in which
/etc/profile works and should be a little safer.
Two new files are introduced:
- /etc/bash/bashrc.d/10-gentoo-color.bash
- /etc/bash/bashrc.d/10-gentoo-title.bash
Users may suppress these with INSTALL_MASK, should they wish to do so.
The NO_COLOR variable is now respected, provided that is is defined
prior to the sourcing of 10-gentoo-color.bash. It should be noted that
ssh users have the option of transmitting this variable by configuring
both ssh(1) and sshd(8) accordingly.
The way in which terminals are evaluated for colour support has been
greatly improved. There are now three heuristics involved. The first
method is to determine whether COLORTERM is already set as an
environment variable. This is an effective method because modern
terminal emulators commonly set the variable so as to advertise 24-bit
colour support. Further, Gentoo already whitelists the COLORTERM
variable in both ssh(1) and sshd(8). The second method is to use the
ncurses implementation of tput(1) to determine whether colour is
supported. The third method is to fall back to a traditional whitelist
of TERM patterns. However, I have overhauled this list based on an
arduous survey of terminal emulators during which I collected empirical
evidence as to which of them actually belong on the list. As such, the
coverage of this method of last resort is broader.
The COLORTERM variable will now be set for terminal emulators that are
found to support 24-bit colour but which do not set the variable by
themselves.
Colour-supporting aliases will now be defined for all of the following
utilities: diff, dir, egrep, fgrep, grep, ls and vdir.
Out of an abundance of caution, the -- operand is now used to signify
end-of-options in the case that dircolors(1) is being passed a pathname
incorporating the user's home directory.
PROMPT_COMMAND will now be defined as an array, as is supported for bash
5.1 or greater. It is more convenient because additional commands can
simply be appended to the array.
No longer will the "Title Definition String" and/or "Set Text Parameter"
sequences be injected into the value of PS1. This keeps the value of PS1
clean and results in fewer side effects in the event that the user
wishes to customise the prompt.
PROMPT_COMMAND will now be used to contain commands that print the
"Title Definition String" and/or "Text Parameter Sequences", depending
on the characteristics of the operating environment. The precise
behaviour is conveyed from hereon.
If the value of TERM is found to be that of the screen or tmux terminal
multiplexers, PROMPT_COMMAND will be set so as to invoke a function that
prints the Title Definition String sequence. The effect of the sequence
is to define the window title for screen, and the pane title for tmux.
The title will incoporate the hostname in short form.
If, on the other hand, the value of TERM is not found to be that of a
terminal multiplexer, a test is performed to see whether the tty is that
of sshd(8). If it is, then no further processing will occur. The reason
for this is it that there is no way for Gentoo to know the
characteristics of the operating environment where ssh(1) happens to be
running at the time. Sadly, there are many cases in which the window
title would simply not be restored after ssh(1) exists, which amounts to
a poor user experience.
Assuming that processing has not ceased at this point, the value of TERM
will be matched against a whitelist of modern terminals that are known
to support the Set Text Parameters Sequence, and to support UTF-8
correctly. If a match is made then PROMPT_COMMAND will be amended so as
to invoke a function that prints the aforementioned sequence. The effect
of the sequence is to define the hardstatus for screen, the window name
for tmux and the window title for graphical terminal emulators. The
title will incorporate the username, the hostname in short form and the
basename of the current working directory. Said basename will be
sanitised where appropriate, by employing the ${param@Q} form of
parameter expansion. Doing so improves the user experience by ensuring
that, where the basename contains anything other than (visible)
graphemes, the title will always show a valid, legible shell word.
It should be noted that users may now easily opt out of the title
setting behaviour by either unsetting PROMPT_COMMAND or by re-defining
it, which was not possible before. At the same time, users that like to
customise the value of PROMPT_COMMAND now have the option of appending
their custom commands to the array, duly preserving the default Gentoo
behaviour.
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Bug: https://bugs.gentoo.org/show_bug.cgi?id=554086
Bug: https://bugs.gentoo.org/show_bug.cgi?id=926742
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Michael Mair-Keimberger <mmk@levelnine.at>
Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Michael Mair-Keimberger <mmk@levelnine.at>
Closes: https://github.com/gentoo/gentoo/pull/34539
Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Note that Ramey's claim that only interactive shells are affected is
false, as is demonstrated below.
$ bash -c '[[ ]]; echo fin'; echo $?
0
Signed-off-by: Kerin Millar <kfm@plushkava.net>
Bug: https://savannah.gnu.org/support/?110745
Bug: https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00103.html
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Signed-off-by: Diego Viola <diego.viola@gmail.com>
Closes: https://github.com/gentoo/gentoo/pull/30765
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
|
|
Signed-off-by: Diego Viola <diego.viola@gmail.com>
Closes: https://github.com/gentoo/gentoo/pull/30756
Signed-off-by: Sam James <sam@gentoo.org>
|
|
The k escape sequence changes screen's internal window title, which is
the alias given by the user to the window and which should not be
changed by an application running inside screen. screen supports the so
called hardstatus line with the _ escape sequence, which should be used
instead and which gets forwarded to the terminal as the title.
Signed-off-by: Sven Wegener <swegener@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: Michael Mair-Keimberger <mmk@levelnine.at>
Closes: https://github.com/gentoo/gentoo/pull/28299
Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
|
|
It's still not sufficient but with this in on top of _p9, it's very
clear what the remaining issues are then, rather than me at least
trying to remember exactly what's broken still as the saga continues.
It is still not enough to unmask as there's still one extglob
issue remaining (and this came up pretty early as far as testing
goes). I don't see us being able to expose Bash 5.2 to users
for a while yet.
Bug: https://bugs.gentoo.org/873931
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Just splits the patches from 47950445cddff736a1e6c0c1346a20ab6b326cc1
into two.
Closes: https://bugs.gentoo.org/873931
See: 47950445cddff736a1e6c0c1346a20ab6b326cc1
Thanks-to: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Bug: https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00029.html
Closes: https://bugs.gentoo.org/873931
Thanks-to: Kerin Millar <kfm@plushkava.net>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Upstream has declared these forms to be deprecated. Aliasing them to
'grep -E' and 'grep -F' prevents the deprecation warning from being
displayed, which could lead to confusion.
Bug: https://bugs.gentoo.org/869788
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
|
|
Was taking up 129K in files/ before.
Signed-off-by: Sam James <sam@gentoo.org>
|
