| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[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>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/928373
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
| |
Includes newly-added filter-lto, reported that upstream to Chet. Only in
5.3_alpha as the issue is newly-introduced.
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to implicit function declarations, LTO fails to detect the
availability of a function and errors out due to an undefined reference
at link time.
It's fixed in bash 4.0 and on, but the value of backporting the fix to
versions of bash that have niche use (people interested in exploring old
versions, not people who are looking for the shebang interpreter for
their system scripts) is a matter of some question...
Closes: https://bugs.gentoo.org/893958
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
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/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>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
if available
-fprofile-partial-training helps not to pessimise other paths if no data
is available.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upstream only test with Bison and require GNUisms like YYEOF and
YYERRCODE. The former at least may be in POSIX soon:
https://www.austingroupbugs.net/view.php?id=1269.
configure warns on use of non-Bison but doesn't abort. The result
may misbehave at runtime.
Noticed with recently added bash-5.2_p15-shell-parser-reset-issue.patch
(which is blameless in itself).
A simple test with a broken Bash is:
```
$ /var/tmp/portage/app-shells/bash-5.2_p15-r4/image/bin/bash -n /lib/gentoo/functions.sh
/lib/gentoo/functions.sh: line 104: syntax error near unexpected token `}'
/lib/gentoo/functions.sh: line 104: `}'
```
Reference: 3ee2d707a299f352b6970af459b0c25c356cbb25
Reference: dde3a81f420e745fe884b6535796129192f02561
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to radhermit's new pkgcraft tooling. Also, thanks to ztrawhcse for suggestions.
Before:
```
app-shells/bash-5.2_p15-r3::.: 61.224122ms
app-shells/bash-5.1_p16-r4::.: 65.001125ms
app-shells/bash-5.1_p16-r5::.: 65.480029ms
```
After:
```
app-shells/bash-5.2_p15-r3::/home/sam/g/: 10.449073ms
app-shells/bash-5.1_p16-r4::/home/sam/g/: 10.505063ms
app-shells/bash-5.1_p16-r5::/home/sam/g/: 10.523583ms
```
This also gets us to approximately the same speed (almost within rounding
error) of pre-d3c19b7974aeb4ac2a1351a019e80625b4111c4b (where we removed eval
usage).
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/907403
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
|
|
|
|
| |
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
|
|
|
|
| |
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
|
|
|
|
| |
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
|
|
|
|
| |
Signed-off-by: David Seifert <soap@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>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/896330
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/889848
Signed-off-by: Leonardo Hernández Hernández <leohdz172@protonmail.com>
Closes: https://github.com/gentoo/gentoo/pull/28985
Signed-off-by: Sam James <sam@gentoo.org>
|