| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Petr Vaněk <arkamar@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
This goes back a while to e515c9f26e5967d35c3f83b21f984bee53ab22e6 and
then 5a798cae614346d6aa0ad8b85cfd5c65f2150587 (gentoo commits).
Fixed upstream in fe393c0f9ab72de5a7d32aab53e5e8275cad8735.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
| |
dash releases are infrequent. Further, there's various POSIX.1-2024 changes
in git which may be useful to test.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Akinori Hattori <hattya@gentoo.org>
|
|
|
|
|
|
| |
Signed-off-by: Randy Barlow <randy@electronsweatshop.com>
Closes: https://github.com/gentoo/gentoo/pull/37986
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
|
| |
Signed-off-by: Randy Barlow <randy@electronsweatshop.com>
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/937410
Signed-off-by: Randy Barlow <randy@electronsweatshop.com>
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
|
|
| |
Signed-off-by: Jonas Frei <freijon@pm.me>
Closes: https://github.com/gentoo/gentoo/pull/37989
Signed-off-by: Zac Medico <zmedico@gentoo.org>
|
|
|
|
|
|
| |
Signed-off-by: Jonas Frei <freijon@pm.me>
From: https://github.com/gentoo/gentoo/pull/37989
Signed-off-by: Zac Medico <zmedico@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: Jakov Smolić <jsmolic@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>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Florian Schmaus <flow@gentoo.org>
|
|
|
|
| |
Signed-off-by: Maciej Barć <xgqt@gentoo.org>
|
|
|
|
| |
Signed-off-by: Maciej Barć <xgqt@gentoo.org>
|
|
|
|
| |
Signed-off-by: Jakov Smolić <jsmolic@gentoo.org>
|
|
|
|
| |
Signed-off-by: Joonas Niilola <juippis@gentoo.org>
|
|
|
|
| |
Signed-off-by: Joonas Niilola <juippis@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
|
|
|
| |
Signed-off-by: Jonas Frei <freijon@pm.me>
Closes: https://github.com/gentoo/gentoo/pull/37379
Closes: https://bugs.gentoo.org/936307
Signed-off-by: Zac Medico <zmedico@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
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>
|
|
|
|
|
| |
Bug: https://bugs.gentoo.org/935658
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
|
|
| |
Signed-off-by: Mattéo Rossillol‑‑Laruelle <beatussum@protonmail.com>
Closes: https://github.com/gentoo/gentoo/pull/37384
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matthias Maier <tamiko@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|