Overview of history of starship init #3491
chipbuster
started this conversation in
General
Replies: 1 comment
-
Excellent roundup, @chipbuster! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Starship's initialization procedure is built out of quite a few pieces: the idea of shipping the initialization in the binary itself, the two-phase initialization which makes it so that the entire initscript can be evaluated in a single line, and multiple other subsystems.
Many of these mechanisms were tuned via trial-and-error, and we historically haven't kept a log of all the issues we've hit. I went back through the repo history and looked at all PRs that I thought satisfied the following criteria:
These are the PRs I ended up looking at:
PROMPT_COMMAND
can cause infinite recursion withstarship_precmd
starship_precmd
cannot go at the front ofPROMPT_COMMAND
PROMPT_COMMAND
cannot be overwritten (else other frameworks break)/dev/stdin
does not exist on all systems--need to use caution/dev/stdin
In addition, we have support issues with older versions of
bash
: because MacOSis frozen on bash 3.2 (released 2006-10-11), there are many modern features that
we cannot always rely on. Since MacOS has moved to
zsh
being the default shell,we can likely relax this condition in the future, but at the moment, we try to
support all versions of bash from 3.2 to current.
Here are the conclusions from each individual PR (in reverse chronological order).
I will summarize everything at the end.
PR #106, #224
Starship used to call itself just by
starship
in the init files.This is incorrect because the user may specify non-PATH paths to
starship, or just have multiple copies of starship in the PATH but
not want to use the first.
These PRs added support for absolute and relative path invocations
of starship. As long as
starship
can be found whenstarship init
is called and the binary does not move, starship should continue to work.
PR #180
A dumb mistake on my part. Even when some variables are used to control shell
behavior, we cannot always rely on them being defined.
PR #213
This fixed an issue where double-bracket conditionals (e.g.
if [[ $VAR ]]
)completely broke ZSH. This seems to be because early versions of ZSH did not
support this syntax.
Features in shells cannot always be relied upon to be present if the shell has
a long lineage. This is likely most relevant for long-lived popular shells
like bash, zsh, and tcsh.
PR #241, #278
The bash-3.2 fallback init code uses /dev/stdin to get around rules about
sourcing with process substitution. Unfortunately, many of our platforms (incl.
Termux and Windows) do not have
/dev/stdin
, meaning we have to carefullycontrol when this fallback is called.
PR #336
This fixed an issue caused by setting
PROMPT_COMMAND
directly--we cannot dothis (same with
DEBUG
traps) since other frameworks hook this to do their ownsetup.
PR #696, #799
Starship shares the
PROMPT_COMMAND
hook with other programs, which may attemptto do things such as append to it without including semicolons. There may also
just be no other programs.
In all cases, starship needs to function correctly or be a good citizen and
attempt to avoid breaking other scripts as much as possible.
PR #1185
A very clever change by MunifTanjim which sidesteps many of the issues we've seen
above (though the lessons learned from those issues should be kept in mind).
Replaces the current
PROMPT_COMMAND
, but preserves the old one in a variable.Then, once starship has finished running its
precmd
, it executes the variablestoring the old
PROMPT_COMMAND
.PR #1541
Fixes an infinite recursion that can occur if
starship_precmd
gets intoPROMPT_COMMAND
more than once.PR #2848
Changes shell quoting of the path to the starship binary.
Takeaways
Modern shell support seems to mostly work as expected. Support for shells with
long histories (primarily bash, zsh, and possibly tcsh), is made trickier by
the fact that older versions do not support features that new ones do, or have
backwards-incompatible changes. NOTE: Fish will also exhibit this behavior
as time goes on.
We cannot rely on platform-specific files existing in the general case.
Bash init is a pain.
Use cases we support
(i.e. Use cases we have made changes to to get working in the past, and should not break without making an explicit decision to do so)
/dev/stdin
Beta Was this translation helpful? Give feedback.
All reactions