* refactor(dotnet): ".NET" instead of "•NET"
"•NET" looks quite weird, especially since the official writing is ".NET".
* revert(docs): translated docs
Co-authored-by: Eyal Cherevatzki <eyal@hyperguest.com>
No need to forcefully set the `PROMPT` variable every time the prompt is
to be shown. Just set it once, leaving the command to be evaluated every
time the prompt is to be shown, by enabling the `promptsubst` option.
Setting it once is also friendlier to users that want to experiment with
another prompt theme by temporarily setting `PROMPT` to something else.
This would currently not be possible, because the variable is always
reset before every prompt draw (precmd) and keymap change
(zle-keymap-select).
Some other updates to take better advantage of the zsh script dialect:
* `$` is not required to read variables inside `(( ))` arithmetic
expressions.
* The zsh dialect to check if a variable is set is `${+var}`. Better
than `${var+1}`, which substitutes 1 if var is set, which is
intended for more general substitutions, not just to check if var is
set.
* The number of jobs can be read using the `%j` escape sequence, which
is expanded when the `promptpercent` option is set.
Also simplified a couple of code lines by avoiding a temporary
`STARSHIP_START_TIME` variable, since we already have
`STARSHIP_CAPTURED_TIME`.
* fix(python): Handle PyPy python version correctly
* refactor: rework Python version retrieval and formatting
Align Python version retrieval and formatting with established
Starship conventions.
* fix(java): use consistent separators for java path
This switches us from just appending `/bin/java` to `$JAVA_HOME` to
treating `$JAVA_HOME` as a path. This should fix any issues on Windows
where $JAVA_HOME might use `\` rather than `/`.
* test(java): add test for JAVA_HOME
* refactor: remove duplicate defaults
* perf: sligntly better java path perf
* Update src/modules/java.rs
Co-authored-by: Dario Vladović <d.vladimyr@gmail.com>
* Update src/modules/java.rs
Co-authored-by: Dario Vladović <d.vladimyr@gmail.com>
* Update src/modules/java.rs
Co-authored-by: Dario Vladović <d.vladimyr@gmail.com>
Co-authored-by: Dario Vladović <d.vladimyr@gmail.com>
* feat: add support for tcsh
* add tcsh to install.sh install message
* list tcsh in bug_report.rs and main.rs
* quote starship path
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* fix job count
* add tcsh support to shell module
* fix STARSHIP_START_TIME undefined error
* preserve existing user precmd and postcmd, remove jobs support
* remove unnecessary parentheses
* minor script improvement
* removes parens from install script message
* Update docs/config/README.md
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* fix(Tcsh): remove unecessary quotes
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
- update shebang to support posix-compliant shells (like dash)
- replace all usages of echo with printf (to normalise)
- command variable to fetch_cmd as it overloads a posix
- rename complete function to completed as it overloads
the bash builtin for completion
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* feat: add support for tcsh
* add tcsh to install.sh install message
* list tcsh in bug_report.rs and main.rs
* quote starship path
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* fix job count
* add tcsh support to shell module
* fix STARSHIP_START_TIME undefined error
* preserve existing user precmd and postcmd, remove jobs support
* remove unnecessary parentheses
* minor script improvement
* removes parens from install script message
* Update docs/config/README.md
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* docs: Update Nix installation documentation
This changes the documentation to show the provided Home Manager module
instead of manual Home Manager installation instructions. Also fixes a
typo in the NixOS instructions and removes the unfinished and now
unnecessary section on zsh integration via Home manager (since that is
included in the provided module).
* docs: Change example Home Manager configuration
The unicode hexagon symbol does not actually fit into a single column with a
fixed-width font. does. As starship requires a nerd font as a prerequisite,
it's safe to assume that this symbol is available.
Symbol link: https://www.nerdfonts.com/cheat-sheet?set=nf-mdi-nodejs
In the documentation, I've left the '⬢' symbols in '#### Text Group' as
they are, as they will continue displaying correctly in a browser
without a nerd font available. I feel like readability is more important
than consistency with the new nodejs symbol, especially as this
documentation section does not actually refer to nodejs, rather it's
just a symbol.
As `⬢` has been replaced, use `⌘` instead in documentation to avoid
any possible confusion
This makes it possible to configure when the purescript module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
This makes it possible to configure when the php module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
This makes it possible to configure when the perl module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
This makes it possible to configure when the ocaml module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
This makes it possible to configure when the nodejs module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
This makes it possible to configure when the nim module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
* feat(erlang): Configure when the module is shown
This makes it possible to configure when the erlang module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
* Update docs/config/README.md
Co-authored-by: Shu Kutsuzawa <cappyzawa@gmail.com>
Co-authored-by: Shu Kutsuzawa <cappyzawa@gmail.com>
This makes it possible to configure when the elm module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
This makes it possible to configure when the elixir module is shown
based on the contents of a directory. This should make it possible to be
a lot more granular when configuring the module.
* Add the shell module
This module allows to quickly identify which shell is currently used, in case someone frequently switches between them.
* Updated documentation with shell module.
Co-authored-by: mro <mro@fedorabox.localdomain>
This makes it possible to configure when the dotnet module is shown
based on the contents of a directory. This should make it possible to be
a lot more granular when configuring the module.
This makes it possible to configure when the lua module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
This makes it possible to configure when the golang module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
This makes it possible to configure when the terraform module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
* feat(docker_context): Configure when module is shown
This makes it possible to configure when the docker_context module is
shown based on the contents of a directory. This should make it possible
to be a lot more granular when configuring the module.
* Update docs/config/README.md
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* feat(vagrant): Configure when the module is shown
This makes it possible to configure when the vagrant module is shown based on the contents of a directory.
* fix documentation
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* feat(dart): Configure when the module is shown
This makes it possible to configure when the dart module is shown based
on the contents of a directory. This should make it possible to be a lot
more granular when configuring the module.
* docs(dart): add missing detected files
* removed invalid comment
* feat(crystal): Configure when the module is shown
This makes it possible to configure when the crystal module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
* Update docs/config/README.md
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
This makes it possible to configure when the cmake module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
* refactor(directory): Introduce `logical-path` argument which allows a shell to explicitly specify both a logical and physical filesystem path
Fix `directory::module` to consume both path and logical-path (if provided). The "logical" path is preferred when rendering the "display path", while the "physical" path is used to resolve the "read only" flag. Repo- and home-directory contraction behavior is maintained, based on the logical path if it is set, or the physical path if it is not.
The custom "get_current_dir" logic has been removed entirely, and the `directory` module now relies on `context.current_dir` / `context.logical_dir` entirely.
Changes have been made to `init/starship.ps1` to work with this new flag:
- Calculate and pass "physical" and "logical" paths explicitly (as other shells do not pass `--logical-path` that they fall back to rendering the physical path)
- Moved the "powershell provider prefix" cleanup code to the PowerShell script - this code _should_ now support any kind of powershell path prefix.
* fix(powershell): Fix an issue with trailing backslashes on file paths causing command line parsing issues.
This is a bit of a footgun!
The work-around chosen is to append a trailing space when a path string ends with a backslash, and then trim any extra whitespace away in the Context constructor.
Other alternatives considered and rejected:
1. Always trim trailing backslashes as the filesystem generally doesn't need them.
2. Escape trailing backslashes with another backslash. This proved complex as PS only quotes string args when the string includes some whitespace, and other backslashes within the string apparently don't need to be escaped.
* fix(powershell): Use Invoke-Native pattern for safely invoking native executables with strings which may contain characters which need to be escaped carefully.
* fix(context): Remove superfluous argument trims
These were in place to clean up extra whitespace sometimes injected by starship.ps1::prompt, and are no longer required with the new Invoke-Native helper in place.
* refactor(directory): Clean up the semantics of `logical_dir` defaulting it to `current_dir` but overridable by the `--logical-dir` flag.
- Restore `use_logical_path` config flag.
- Always attempt to contract repo paths from the `current_dir`.
* fix(directory) :Use logical_dir for contracting the home directory
This keeps the two calls to contract_path in sync.
* fix(directory): Remove test script
* refactor(directory): Convert current_dir to canonical filesystem path when use_logical_path = false
- This requires some clean-up to remove the extended-path prefix on Windows
- The configured logical_dir is ignored entirely in this mode - we calculate a new logical_dir by cleaning up the physical_dir path for display.
- Test coverage
* fix(directory): Use AsRef style for passing Path arguments
* fix(directory): Strip the windows extended-path prefix from the display string later in the render process
* fix(docs): Update docs/config/README.md for use_logical_path
* refactor(context): Populate `current_dir` from `--path` or `std::env::current_dir`, populate `logical_dir` from `--logical-path` or the `PWD` env var
- `current_dir` is always canonicalized
- On Windows, `current_dir` will have an extended-path prefix
- `logical_dir` is now always set
- `directory::module` now just selects between `current_dir` and `logical_dir` when picking which path to render
- Test coverage
* fix(directory): Fix path comparison operations in directory to ignore differences between path prefixes
- Added PathExt extension trait which adds `normalised_equals`, `normalised_starts_with` and `without_prefix`
* fix(path): Add test coverage for PathExt on *nix
* fix(directory): Test coverage for `contract_repo_path`, `contract_path` with variations of verbatim and non-verbatim paths
* fix(directory): Update path-slash to latest
This fixes the issue with the trailing character of some Windows paths being truncated, e.g. `\\server\share` and `C:`
* fix(powershell): Improve UTF8 output handling, argument encoding
- Use `ProcessStartInfo` to launch native executable, replacing manual UTF8 output encoding handling
- If we detect we're on PWSH6+ use the new `System.Diagnostics.ProcessStartInfo.ArgumentList` parameter, otherwise manually escape the argument string
- Move `Get-Cwd` and `Invoke-Native` into the prompt function scope so that they don't leak into the user's shell scope
* fix(path): Make PathExt methods no-ops on *nix
* fix(path): Cargo fmt
* fix(powershell): Remove typo ';'. Fix variable assignment lint.
This makes it possible to configure when the python module is shown
based on the contents of a directory. This should make it possible to
be a lot more granular when configuring the module.
This includes a breaking change since we are removing the
`scan_for_pyfiles` configuration option in favour of setting the
`detect_extensions` to an empty array.
* Remove status_ prefix from status module variables
* Revert "Remove status_ prefix from status module variables"
This reverts commit f4c6e9ced3.
* docs: Remove status_ prefix from status module variables
* fix(windows): don't inherit stdin when executing commands
On Windows, inheriting stdin from starship might lead to leaking the
console reference to the command we're executing. `id.exe` supplied with
Git has been observed to disable the ENABLE_VIRTUAL_TERMINAL_PROCESSING
console flag if it inherits stdin -- leading to Windows Terminal not
processing ANSI escape sequences.
This change fixes#2254 by explicitly disabling stdin inheritance.
The fix was suggested by David Knaack.
* fix(username): don't call `id -u` on Windows
This was done to check if user is root by comparing the UID to 0. Windows
does not have a concept of UID 0 anyway, so it's pointless to call `id.exe`
(which is installed with MSYS2 or Git, for example).
* feat: add support for elvish shell
* improve doc
* elvish 0.15 is out
* fix example init
* update systax for 0.15 stable
* udpate second init example too
* remove warning from swift module
* add warning to status module docs
* prefix elvish version with v
In #1897 we replaced a 'wc -l' with a bash-native job counter, but
subsequently discovered that bash on MacOS folds '<<<' output into
a single line, preventing line counting.
A for loop works around that problem, is still bash-native, and works
on Linux as well.
While we're at it, also removed the need for command substitution and
an echo by doing the work directly on NUM_JOBS.
Fixes#2241.
I simplified the code in the git status module by moving everything from RwLock<_> to OnceCell<_>. I think this should also get rid of any remaining race conditions that remained after #1777.
We currently invoke `starship time` in a sub-shell to compute time, which is non-performant. By using $EPOCHREALTIME,
which is an inbuilt env-var in ZSH5, we can get better performance. This commit only targets ZSH5+ and maintains the
old behaviour.
* perf(zig): evaluate version lazily
* fix(zig): update format string; update tests
* refact(zig): remove redundant clone and put everything to do with version eval into match statement
* tiny optimization
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* perf(perl): evaluate version lazily
* fix(perl): update format string; update tests
* refact(perl): run rustfmt
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
* perf(utils): Add timeout to `utils::exec_cmd`
This adds a timeout to any command executed using the `utils::exec_cmd`.
The initial time limit is hard coded to 500ms but if required we can
make this configurable. Have also switched the tests to be a bit more
granular on which systems they are ignored.
* Terminate the processes if they timeout
* fix(nodejs): update format string
* test(nodejs): adjust tests to new format strings
* fix(nodejs): use once_cell's Lazy to implement hassleless lazy execution
* chore(nodejs): run rustfmt
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
* perf(dart): evaluate version lazily
* fix(dart): update format string
* fix: use suggested format string
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
* perf(java): evaluate version lazily
* fix(java): update format string
* fix: use suggested format string
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
* perf(elm): evaluate version lazily
* fix(elm): update format string
* fix: use suggested format string
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
* fix(dotnet): update dotnet format string
* fix(dotnet): update erlang format string
* fix(dotnet): update golang format string
* fix(dotnet): update helm format string
* fix(dotnet): update julia format string
* fix(dotnet): update nim format string
* fix(dotnet): update ruby format string
* fix(dotnet): update rust format string
* test: update formatted strings in unit tests
* Use suggested format strings
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Moritz Vetter <mv@3yourmind.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* perf(crystal): Lazily evaluate version command
This updates the module to lazily execute the `crystal --version`
command only when the `version` variable is used in the format string.
* perf(crystal): Update format string
Update format string to handle the `$version` variable not being set.
Have updated the deploy workflow to build a 32 bit version of Starship
for Linux. This switches the build steps to use the action-rs cargo
since it makes using cross a lot easier.
* fix(user): Fix username detection on Windows
This switches Windows to use the env var `USERNAME` rather than `USER`
for getting the username of the current user. I have also done some minor
refactoring to simplify some of the code and make the checks to see if
the user is root or another user a bit more robust.
* Update src/modules/username.rs
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
Have added support to the `utils::exec_cmd` to allow it to execute
commands that are not `.exe` on Windows. Have also added a timer to
measure how long a command took to execute.
I was surprised to see these (unprefixed) variables being set in my
shell. I think it's better to have them in the STARSHIP_ "namespace".
(Actually, STATUS got the new name STARSHIP_CMD_STATUS.)
* refactor: convert some vecs to static arrays and slices
* refactor(openstack): lazy yaml file reading, skip files without expected structure, and avoid panics for some edge cases
* feat(git_branch): Show remote name in addition to remote branch
* feat(git_branch): Fix table indentation in config README
* feat(git_branch): Use a different method to fetch remote information
* feat(git_branch): Fix the Clippy issue regarding string constant
* fix(git_commit): show last created tag on current commit
* style(git_commit): fixed linter & format alerts on PR checks
* test(git_commit): added 'test_latest_tag_shown_with_tag_enabled'
* test(git_commit): add a second between tags on same commit in 'test_latest_tag_shown_with_tag_enabled'
* feat: Try harder to guess if inside ssh
* Add test for SSH_CLIENT
* Update documentation on checking ssh connection
* Update docs/config/README.md
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* docs: Fix default format string for Conda module
#### Issues Addressed
The default `format` string for the Conda module starts with "via", as
seen [here](https://github.com/starship/starship/blob/2e763b5e7c41dd556c9515bdc36297bc177d7f46/src/configs/conda.rs#L19).
However, this is not reflected in the config docs.
Many similar modules include "via" in their default format string so I
assume including it is the intended behavior, and that the doc should
be updated.
#### Summary of Changes
Correct the default `format` string for the Conda module in the config
docs.
* Revert changes to i18n files
Revert changes to i18n files, as these must be handled by Crowdin
Changes the behaviour of a bg:none color string so that
it causes the background to have no color instead of
decoloring the entire string like it did before.
Update the python module to try multiple python binaries when
determining the version. With the new logic if starship doesn't find
`python` on the `PATH`, which is the default for some Linux Distros, it
will fallback to `python3` and then `python2`.
* feat(rust): Support new rust-toolchain format
* Match file parsing with rustup and update link
* Use cargo to deserialize the rust-toolchain file
* Filter empty channel strings after extraction
* Use the option value instead of rewrapping
* feat(git_branch): add remote branch name if different than local branch
* feat(git_branch): Implement a more customizable remote branch
* feat(git_branch): Use more explicit API function name
* feat(git_branch): Remove forgotten draft documentation
* feat(git_branch): Set less verbose defaults
* feat(git_branch): Handle case to always display remote
* feat(git_branch): Fix error in rebase operation
* feat(git_branch): add 'only_attached' config bool
This adds a new boolean, `only_attached`, to the configuration for
the `git_branch` module. This mirrors the `only_detached` config
value for the `git_commit` module: setting the value to true causes
the module to suppress its output when the user is not on a branch.
This allows users to have either a branch name or a commit hash in
their prompt, as opposed to having either a branch name or the
overly-wordy "HEAD (sha1)".
* Fix formatting
* Add CMakeCache.txt to cmake module
* Remove trailing whitespace
* Apply fixes by @andytom
* Add CMakeCache.txt to docs
* Revert documentation for languages other than en
* [f]Use_global_dollar_hook_for_lastExitCodeForPrompt Switched to use the dollar hook, as source of truth for exit code of las command, included comments to clarify.
* fix: Adjusted accordingly to comments on PR.
* fix: Moved last exit code handling inside if to reuse that variable.
Co-authored-by: Marcos Quezada Perez <marcos.quezadaperez@peakwork.com>
Have refactored the kubernetes module to better support stacked
kubeconfigs. Rather than trying to grab both the current-context and
namespace on a single pass we now do two passes. These changes should
fix the problems where the current-context is defined in one file but
the context and the namespace are defined in a different file.
Have switched to use a monotonic clock for calculating the timeout when
indexing the current directory for the context to avoid any issues with
calculating the timeout when the systems clock might change.
* fix: rust modules are compiled twice
The modules being declared both in the _library_ crate and the _binary_
crate made cargo compile everything twice:
1. for the library
2. for the binary
What happened was:
1. The library "starship" was compiled.
2. The binary "starship" (and all its modules) were compiled.
* fix: stop compiling every rust module twice
restrict visibility
* Run cargo fmt
* Add bug_report module
Co-authored-by: Matan Kushner <hello@matchai.dev>
Co-authored-by: Kevin Song <chips@ksong.dev>
* Update document for installing on windows
* Revert "Update document for installing on windows"
This reverts commit 5dc8db05c4.
* Update document (English version only) for installing on windows
* Change the expression
* Fixed the grammer misstake
When running the AWS module it will parse the AWS config found in
`~/.aws/config` to get the region. This means that tests that expect no
region to be set will fail if there exists a default profile with a
region set, which is probably true for most AWS users. To avoid this
have set the AWS tests that depend on the non-existance of a
`.aws/config` to be ignored.
Have added a little bit more context to the error messages that occur
when if starship is unable to setup the logger. This should hopefully
make it a bit easier to work out why starship can't setup the logger.
Have updated some of the config docs to correct the git_status default
that was incorrect. Have also taken the time to switch some of the
format strings to use toml literal strings rather than normal strings to
simplify the escape strings.
* ✨ Add --prompt rendering to python virtualenv
* Use pyvenv.cfg to find prompt
* Remove usage of VIRTUAL_ENV_PROMPT variable
Seeing how both venv and virtualenv set a pyvenv.cfg, this isn't needed.
Additionally pyvenv.cfg is set in earlier versions than VIRTUAL_ENV_PROMPT,
which at this moment is in the unrelased python 3.10
* Smarter result unwrapping thanks to clippy
* docs(python): Update the python_binary option
Have updated the documentation to make the `python_binary` option a bit
more prominent, since this is becoming a more requested requirement now
that more and more systems don't have a default `python` command.
* Correct order of python options
Some users have commit.gpgSign set to true in their global git config,
causing tests which run `git commit` to fail if the configured
user.signingKey is not present (as is often the case with PGP smart
cards). Passing this flag overrides the global git configuration,
preventing git from attempting sign the specified commit. This change
has no effect on users who haven't set commit.gpgSign to true.
Have reduced the log level when we fail to execute a command since this
is happening a lot more that expected, for example if a user checks out
a repo that contains a `.js` file but they don't have node installed.
The tests for git-state assume the default branch is `master`.
In git 2.28 support for a global option, `init.defaultBranch`, to
change the default branch name which causes git-state tests to fail.
Having a newline there means that an empty newline is printed everytime
the user runs a command or presses Enter, which for short commands
and/or small terminal windows can noticeably decrease the information
density.
This creates a custom logger for the log crate which logs everything to a file (/tmp/starship/session_$STARSHIP_SESSION_KEY.log) and it logs everything above Warn to stderr, but only if the log file does not contain the line that should be logged resulting in an error or warning to be only logged at the first starship invocation after opening the shell.
* docs: Update git_status module docs
Have updated the configuration docs for the `git_status` to remove a
non-existing option and to add an example for how to achieve the same
effect as with the new format strings.
* Add git_status changes to migration guide
Have added the change to the sync count to the migration guide. I also
corrected a few typos in the configuration.
The default `disabled: true` is actually only available within the module (when the config struct is used and not the user toml) but not all (the hg_branch) modules checked it there again.
Document this in all places and add the check (+ test) to the hg_branch module.
* add the exit code module
this allows to display more precisely the last command exit code
and to configure starship to not change the last charcter of the
prompt even in case of failure. It is disabled by default, because
it seems a bit redundant with the character module in its default
configuration.
* rename exit_code module to status
* Enforce a default disabled=true
In the outer places, we only check for the disabled flag in the config toml file, only when this is loaded into the real config struct, we see the default. And if the default is true, we have to abort at that place. For status and hg_branch that wasn't so. I also commented the rest
* fix spaces in markdown table for status module
* Add a tip that status module is disabled by default
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* Remove unrelated changes for default disabled=true
Co-authored-by: Gaëtan Lehmann <gaetan.lehmann@gmail.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* Start writing migration guide
* Add prefix/suffix migration to guide
* Update docs/migrating-to-0.45.0/README.md
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* Update docs/migrating-to-0.45.0/README.md
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* Add missing quote
* Detail the modules affected by the change
* Document character and time migration
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* feat: Add computational duration to all computed modules
This also means that in case we do some computations and these end up empty, we submit an empty module
* feat: Add timings subcommand
This outputs the timings of all computed modules, sorted by the duration it took to compute the module.
Useful for debugging why the prompt takes so long.
* feat: Add timings to explain output
* fix: Ensure that even empty custom modules get timings
* format main.rs
* feat: Only show interesting timings
* fix(tests): Change tests to look for empty string instead of None
* Use proper wording in timings help
* Revert "fix(tests): Change tests to look for empty string instead of None"
This reverts commit aca5bd1b03.
* fix(tests): Returning None in case the module produced an empty string
* fix: Ensure that linebreaks (and space) make a module not-empty
* Make cargo clippy happy
* Make Module.duration a proper Duration
* Only return a module if we would report it
* Change to cleaner way to return None for empty modules
* Avoid unnecessary module creation
* Simplify a string comparison
* Add timings to trace
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Have restored the `pyenv_prefix` option to the python module. This is
added as a new variable that will only be shown if `pyenv` is being used
to determine the version of python that is being used.
Previously the prompt function used in PowerShell would overwrite the $LASTEXITCODE and $? automatic variables that were set by the previous command run the user in the shell. This results in surprising behavior for the user if they inspect those variables looking for the result of the command they last ran.
This fixes the bug reported here: https://github.com/starship/starship/issues/1051
And goes further to also propagate the $? automatic variable which is not mentioned in that bug.
Previously, all modules would have prefixes, which lead to the first
module having a dangling prefix. This change ensures that the first
few modules would instead have suffixes so that we don't start or
end with a prefix or suffix.
* docs: Clarify that commands will be passed in on stdin
* docs: Clearer instruction how to include individual custom modules
* docs: Include link to #1252 in docs for custom modules
That issue is used to share custom modules.
* docs: Remove reference to prompt_order
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Convert-Path in the powershell prompt script works with -Path,
which interprets paths as wildcard patterns.
Not all valid paths are also valid wildcard patterns, possibly causing
the prompt to error (eg []*).
Replace it with -LiteralPath that makes Convert-Path use the path as-is.
We have had a few issues where users haave run the install script and
have ended up with a non-functioning version of starship because their
system doesn't have a required lib that we link against. To avoid these
problems it seems the easiest solution is to default to using the
statically compiled musl binaries. If a user knows that they are doing
they can use the non-statically compiled binaries by supplying the `-p`
argument to the installer. Note this is what other rust based tools such
as ripgrep do.
The hostname module does not provide any "number" variable, its presence
in the documentation is likely due to some copy&paste from the jobs
module section, so let's drop it.
Signed-off-by: Emanuele Aina <em@nerd.ocracy.org>
Often it is handy to get notified when the execution of a command finished.
This commit includes notify-rust in order to generate a desktop notification
when a command execution finished.
* fix(explain): align table correctly
* iterate over lines directly
* calculate desc_width with the actual space available
* custom unicode-aware textwrapping
* fix clippy error
* better width estimination
* explain +6
* move padding width into a constant
* initial commit of support for shlvl
* documentation for shlvl
* use a symbol instead
* test coverage for shlvl
* actually disable when the config says to
* fix docs
* tweak defaults some
* refactor from pr comments
* redisable
* return early to avoid indenting
* make default suffix empty space
* fixing tests after suffix change
* updating docs for format
* making shlvl compatible with formatting
* adding variables table for shlvl
* removing extra line
* doc clarity
Have updated the CI config to run clippy on all OSs. This will catch
any issues in OS specific codes. This might increase the amount of
annotations that are created in any of the common code but it should
be better than the alternative.
* Add gitignore for Emacs backup files.
* Add package version support for Maven pom.xml.
* Update docs with Maven package version support.
* Fix for clippy.
Do not try to analyze if the current process can write network location
on Windows. There's no way on Windows to tell if we can write a network
location because it's not being controlled by the OS itself. Thus now
the lock symbol is never shown on network locations.
This PR introduces a new unsafe call.
* refactor(java): parse version using regex
Mock java version retrieval & extend java module test suite with
rendering tests.
* chore: remove nom crate
* fix(java): support parsing version from both stdout & stderr
* fix(java): fix java command mock
* refactor(java): simplify version regex
We have been having some CI builds fail because they can't find some
dependencies on the OSX. I'm not sure if this is something wrong with
the CI setup, something bad in the cache or something wrong with the
Cargo.lock file. To try to narrow down the possible issues I've manually
updated the Cargo.lock file by running `cargo update`. This should
ensure that the the lock file is in a good state and also force a cache
refresh in the CI.
* ci: Auto publish for the AUR
* Add commit username + email to deploy.yml
* ci: Use ATiltedTree/create-aur-release
After testing with the other action it turns out that they forgot the `-s` `makepkg` flag meaning download all required dependencies.
I forked it fixed the issue and added a fix from some other fork that allows for multiple source files.
Co-authored-by: Kevin Song <chipbuster@gmail.com>
* Remove renames_index_to_workdir() option from git status
This option causes advanced files rename detection which causes inconsistency between `git status` and Starship reports.
Closes#1371
* add test for manually remaned and deleted files in git_state module
* fix tests
A recent refactor of modules to use format strings accidentally got rid
of the `trim()` on the NodeJS version string. This just adds it back so
that the prompt doesn't include an unnecessary line break when showing
that module.
This removes the hard requirement for a particular version of python in
the CI, and just uses the default version. Since #1297 was merged we
have not depended on the version of python that is installed. This
should stop us from having to update the version of python when the
github action updates the available versions.
Given how slow the Haskell module is (#1240), it is slowing down the entire prompt
from rendering when the module is active. This commit removes the module until we
can find a faster way to retreive the Haskell version.
* Git branch: read from HEAD on newly init repo
On a newly initialized git repo, there are no branches created until a
commit is made. Previously, starship handled this by having a default
branch "master" for when branch `head` could not be read.
However, if a user wants to set a different default branch name, that
name won't appear on starship until a commit is made to the branch.
If git2 provides a way to read the default branch name, we can use that,
but at the moment it's not obvious how.
For the moment, we can directly read `.git/HEAD`, which contains the
name of the default branch head reference. This commit implements this
strategy.
Closes#1327
* update git_branch test from unborn master to unborn default
* cargo fmt
Have switched the fallback shell used when the custom module can't use
the default to use `/usr/bin/env sh` rather than `/bin/env` since
`/usr/bin/env` is more commonly available.
Fixes git repo path contractions in two situations:
1. When path obtained from `PWD` is a logical path but git libraries
return physical paths.
2. When a git repository's subdirectory is symlinked to ouside of the
repository tree.
(1) is fixed by implementing a realpath()-like function, then reparsing
the (possibly logical) `PWD` using realpath() to convert logical
components into physical ones. The physical paths are then matched
against each other.
In the case of (2), the default behavior has been changed by simply
contracting to the home directory, exactly the same as if we are not in
a repo at all. Because determining the correct contraction is not
obvious, we bail out and just pretend we are not in a repo at all.
* Add option to change the python binary
We are going to start to have problems with the python binary as python2
is removed and replaced with python3. To make the transition easier I
have added an option to the python module to allow the user to pick a
particular binary, e.g `python3`, for the module to use when selecting
the version of python. I have also refactored the python tests moving
almost all of them into the module and removing the dependency on the
version of python that is installed on the system.
* Add advanced config section to python module docs
Have added an advanced config section to the python module docs and
moved the `python_binary` option into that section.
PHP will output error messages when displaying the version if, for
example, there is something wrong with the local `php.ini` file. Have
updated the command used to get the PHP version to only use the default
PHP config.
Adds several cross-platform utility functions to the install.sh script and
rewrites core functionality so that it might work on Windows. Among these are:
- Correct platform extensions to match the output of `detect_platform`
- Check to make sure installation directory actually exists
- If sudo is not available, print a message asking the user to manually
escalate
- Unpack zip files (used for Windows builds) without using pipes, since zip
files cannot be read through pipes
After these changes, install.sh works on a testing copy of Git Bash on Windows,
though it still has known issues (e.g. if the `unzip` program is not installed,
it will crash).
* Nim module and tests
* Add nim to docs
* parse_nim_version refactor, add nim desc
* Add nim symbol to Nerd Font preset
* Yellow with v prefix as default version
* Nim version fmt fix
* Update docs/config/README.md
Co-authored-by: Dario Vladović <d.vladimyr@gmail.com>
* Update src/modules/nim.rs
Co-authored-by: Dario Vladović <d.vladimyr@gmail.com>
* Nim module and tests
* Add nim to docs
* Yellow with v prefix as default version
* Update docs/config/README.md
Co-authored-by: Dario Vladović <d.vladimyr@gmail.com>
* Update src/modules/nim.rs
Co-authored-by: Dario Vladović <d.vladimyr@gmail.com>
* Add nim to docs, proper version formatting.
* Remove v from symbol, add to fmt string
* cargo fmt
Co-authored-by: Dario Vladovic <d.vladimyr@gmail.com>
* Creation of range field in TimeConfig
* time_range parsing
* Hide time module if outside of time_range
* Tidying of code, and properly handling more cases
* is_inside_time_range function
* Tests and fmt
* Update docs
* The configuration needs the 24-hours format
* Fix clippy errors
To improve overall support of PowerShell in custom modules,
the ability to pass arguments to the shell was also added. Additionally,
the arguments `-NoProfile -Command -` will be automatically passed
to PowerShell, unless other arguments are given by the user.
This fixes the Security Audit github workflow by consolidating the two
separte yaml documents that Github Actions didn't like into a single
workflow with multiple triggers. I also added a trigger for PRs as well
as pushes.
* Clean up the workflow file
This removes the trailing whitespace from the workflow, removes an
unused step and fixes up some yaml formatting.
* Make the caching more aggressive
This makes the caching more aggressive by allowing for partial
restoration of the cached data and use the cache for more jobs.
* Run all the tests in parallel
Have stopped the testsuites from requiring the compile checks, Github
Actions doesn't mind that we are running multiple tests in parallel and
this does over a bit of a speed up.
* Separate Security Audit into a separate workflow
Have moved the Cargo Audit check into it's own workflow and switched it
to use the `actions-rs/audit-check` to simplify the setup. Have also
added in a daily security scan.
* Added configs/purescript
* Added modules/purescript
* Added necessary codes
* Added tests
* Updated README
* Fixed color because black is hard to see
* Fixed of push mistake
* Fixed pointed out in PR
* feat: Modify config keys from shell
* chore: Fix clippy
* refactor: Add `configure` as alias
* chore: Remove redundant code
* fix: Soft error if user doesn't pass in valid key
* feat: Support integers and booleans
* chore: Fix clippy
* refactor: Use exit instead of abort
Co-Authored-By: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
The user's config is automatically loaded
in context.new_module. This change explicitly
sets the empty config to avoid depending on
the environment.
Without this fix, the tests do not pass
for users who have a custom symbol defined
for conda. This prevents installing/upgrading
from Arch Linux AUR.
According by this standards
> While "Julia" is a female name in many parts of the world, the programming language is not a person and does not have a gender.
* Use AWS_VAULT as the profile if set
[aws-vault](https://github.com/99designs/aws-vault) sets
the `AWS_VAULT` env var instead of `AWS_PROFILE` when an
aws-vault session is active.
This PR adds support for reading the AWS profile value from
the `AWS_VAULT` env var, giving priority to `AWS_VAULT` if both
it and `AWS_PROFILE` are set.
* Update docs for AWS_VAULT
* feat: add docker context module
Adds a simple module that checks for a Docker config file and if present, reads the `currentContext` value out and displays on the prompt with a whale.
* feat: add `only_with_compose_yml` option to docker_context
When enabled, will only show the docker context name if there's a docker-compose.yml file in the current directory.
* Update src/modules/docker_context.rs
Co-Authored-By: Thomas O'Donnell <andytom@users.noreply.github.com>
* Update src/modules/docker_context.rs
Co-Authored-By: Thomas O'Donnell <andytom@users.noreply.github.com>
* rename `only_with_compose_yml` configuration key to a more generic `only_with_files`
* Update src/modules/docker_context.rs
Co-Authored-By: Thomas O'Donnell <andytom@users.noreply.github.com>
* re-order configuration table
* Update docs/config/README.md
Co-Authored-By: Thomas O'Donnell <andytom@users.noreply.github.com>
* Update src/configs/docker_context.rs
Co-Authored-By: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* Allow kubernetes module to use aliases for contexts
* documentation for kubernetes context aliasing
* Apply suggestions from code review: consistent ordering of options in documentation
Co-Authored-By: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* fix: check if editor is not found for `configure`
STD_EDITOR falls back on `vi` if $EDITOR and $VISUAL is not set.
However, some machines might not have `vi` symlinked or installed and a
bad error message is displayed. This commit adds a better error message.
* fix lint errors
* Change NotFound to write to stderr instead of panic!
Oh wow writing rust makes my commit messages look very enthusiastic!
`private: true` in `package.json` files means that the package is not supposed to be published to npm, which makes the `version` field meaningless, so we should probably ignore it to not clutter the prompt too much.
This PR adds package version support for Gradle projects. The version number is extracted from the `build.gradle` file in the current directory, similar to existing support for other packages.
Replaces the existing nodejs module end-to-end tests with integration tests that don't require preinstalled environmental dependencies.
- Moved the tests to the same file as the module they test
- Created a render_module utility function for rendering modules within tests
- Removed Node.js installation during CI setup
- Add Shell to Context to allow for tests to not run shell-specific code
Currently the Java module detection looks for build.gradle specifically, but it's possible to rename build.gradle to *.gradle. This change adds Gradle files to the list of detected file extensions.
* ci: Replace setup-ruby with use-ruby-action
* ci: Update python version
* ci: Update Ruby version
* Set ruby action to master
* Try installing mercurial earlier in the workflow
* Remove mercurial installation
* Remove mercurial installation on all OSes
* Revert "Remove mercurial installation on all OSes"
This reverts commit 0e1a3e7e92.
* Update hg installation comment
* Revert Ruby update
* Add caching
* Add caching to audit
* Update workflow.yml
* Only cache during test steps
perf: don't use hg process to get branch / bookmark information, each call was taking 250ms and it was making on average 2 calls.
the branch and bookmark information is available in files in the root of the repo, use that instead.
now takes 300 micro seconds
fix: do not use .hgignore to decide if it is an hg repo. was providing false positives. #721
fix: after changing branch the new branch was not show (the old branch was shown), the new branch is now correctly shown. #722
fix: if no branch override was set it would say (no branch) however if you commited in that state you would commit to the branch default so say that instead
We can use `and_then()` to string `Option` values together so that we only need a single `?` assertion. This makes it generally possible to have e.g. `unwrap_or()` at the end.
This adds a sub command to generate the link. Information, such as operating system and it's version; the current shell's config; and current starship conf, is gathered from the environment and is included in the pre-filled text. The command will also try to open the link in the default browser. Should that fail it will print the link instead and ask the user to copy it.
This PR tries to improve the version detection across multiple Java VM vendors. The module captures both STDOUT and STDERR outputs of the java -Xinternalversion call.
Eclipse OpenJ9, Azul Zulu, SapMachine, Amazon Corretto and GraalVM outputs are unit tested now.
* Get pathbuf from logical path. (fixes#204)
(also fixes#397)
* fix: Update directory module so that use_logical_path will work properly
* Remove test directory::use_logical_and_physical_paths
* Fix merge errors
Co-authored-by: Matan Kushner <hello@matchai.me>
Also addresses a number of bugs:
- the percent sign not displaying correctly on some terminal emulators, including kitty
- changing the symbol in the configuration file didn't do anything
- swap being shown even if the system didn't have any
This removes ArgMatches from the Context struct and replaces it with a simple HashMap. This work is towards getting Starship in a better place for use as a library in other shells written in Rust so they don't need to use a command-line interface to invoke and configure things.
Contributes to #521
This updates the default AWS default symbol to include a space after the
symbol to make it a little bit more readable. Have also updated the
README to include the AWS module.
Structure the prompt as a function that returns a string instead of writing directly to stdout.
This makes it easier to embed Starship into other Rust programs such as shells written in Rust. It also decouples the arguments from the context for more programmatic initialization of the context.
Implements the Default trait for SegmentConfig to clean up construction of empty segments.
Also adds a segment::new() function to ease construction of simple segments.
Given the global nature of the Kubernetes module, the module has been disabled by default. The opportunity has also been taken to refactor the Kubernetes module to use the new config module.
- Replace hecrj/setup-rust-action with actions-rs tools
- Add a Cargo Audit test step
- Move cargo publish step from Azure Pipelines to GitHub Actions
- Use cargo-publish-all to publish multiple packages at once
- Automate the creation of release notes
Adds the ability to style individual segments in the prompt.
The segment documentation is not fully updated in this commit and is waiting on
a config refactor so that we can write unified docs.
Prevents the rust module from installing rustup toolchains.
Previously, the rust module would trigger rustup toolchain installations in some cases,
leading to frozen prompts while rustup downloads/installs components. This commit
changes the behaviour to avoid this.
- Replaced for loop that iterates over mutable state with a fold expression
- Unified the logging for the different accessors. The code is now screaming for further refactoring (get_module_config, get_as_bool, get_as_str, get_as_i64 and get_as_array are basically the same up to higher order functions but I didn't manage to get the life times right)
- Increased test coverage (especially a test case for none not at the end)
- Removed code comments that literally repeated the code in the next line (see e.g. https://blog.usejournal.com/stop-writing-code-comments-28fef5272752)
- Added TODO for the problematic line that swallows the None and produces Some(Style::new()) (this also happened before but in a less obvious way)
Previously, a set of empty segments would cause the module to print. This changes the
logic of Module::is_empty to check that all the segments are empty instead.
Shell inits are now in a separate directory in the source code, with each shell getting its own script. Also adds a little DRY + commenting in init/mod.rs.
A couple of optimizations are done in this PR. One, we now will check config ahead of time to see if a module is disabled before running any module code. Also, we won't try to discover a git repository unless the module requests access to it.
Add a configuration option (show_sync_count) to the git_status module that will show/hide the counts ahead/behind of the tracked branch. Currently have this default to false, and would opt-in to show this information.
Migrated CI from Azure Pipelines to GitHub Actions.
Until the release process is figured out in Actions, we'll stick to using Azure pipelines for releases.
Git branches can become very long (e.g. gitlab auto-generated branch
names), thus it would be nice to be able to truncate them to keep your
prompt lenght in line.
This patch adds two new options to the git_branch module:
* truncation_length: The amount of graphemes to of a gitbranch to
truncate to
* truncation_symbol: The symbol that should be used to indicate that a
branch name was trunctated
To be able to correctly work with UTF-8 graphemes, unicode-segmentation
was added as a dependency.
Debug logging in starship is done with [pretty_env_logger](https://crates.io/crates/pretty_env_logger).
To run starship with debug logs, set the `RUST_LOG` environment variable to the log level needed.
Debug logging in starship is done with our custom logger implementation.
To run starship with debug logs, set the `STARSHIP_LOG` environment variable to the log level needed.
For example, to enable the trace logs, run the following:
```sh
# Run installed starship
RUST_LOG=starship=trace starship
STARSHIP_LOG=trace starship
# Run with cargo
RUST_LOG=starship=trace cargo run
STARSHIP_LOG=trace cargo run
```
## Linting
@@ -44,46 +88,138 @@ Starship source files are linted with [clippy](https://crates.io/crates/clippy).
```sh
rustup component add clippy
cargo clippy
cargo clippy --all-targets --all-features
```
## Formatting
Starship source files are formatted with [rustfmt](https://crates.io/crates/rustfmt-nightly). Rustfmt will be ran as part of CI. Unformatted code will fail a build, so it is suggested that you run rustfmt locally:
Starship source files are formatted with [rustfmt](https://crates.io/crates/rustfmt-nightly), using the default configuration. Rustfmt will be ran as part of CI. Unformatted code will fail a build, so it is suggested that you run rustfmt locally:
```sh
rustup component add rustfmt
cargo fmt
```
## Testing
Testing is critical to making sure starship works as intended on systems big and small. Starship interfaces with many applications and system APIs when generating the prompt, so there's a lot of room for bugs to slip in.
Unit tests and a subset of acceptance tests can be run with `cargo test`.
The full acceptance test suite can be run in a Docker container with the included [`./integration_test`](integration_test) script.
Unit tests are written using the built-in Rust testing library in the same file as the implementation, as is traditionally done in Rust codebases. These tests can be run with `cargo test` and are run on GitHub as part of our GitHub Actions continuous integration to ensure consistent behavior.
### Unit Testing
All tests that test the rendered output of a module should use `ModuleRenderer`. For Example:
Unit tests are written using the built-in Rust testing library in the same file as the implementation, as is traditionally done in Rust codebases. These tests can be run with `cargo test`.
// The value that should be rendered by the module.
letexpected=Some(format!("{}",Color::Black.paint("THIS SHOULD BE RENDERED")));
// Assert that the actual and expected values are the same
assert_eq!(actual,expected);
// Close the tempdir
tempdir.close()
}
}
```
If a module depends on output of another program, then that output should be added to the match statement in [`utils.rs`](src/utils.rs). The match has to be exactly the same as the call to `utils::exec_cmd()`, including positional arguments and flags. The array of arguments are joined by a `" "`, so `utils::exec_cmd("program", &["arg", "more_args"])` would match with the `program arg more_args` match statement.
If the program cannot be mocked (e.g. It performs some filesystem operations, either writing or reading files) then it has to added to the project's GitHub Actions workflow file([`.github/workflows/workflow.yml`](.github/workflows/workflow.yml)) and the test has to be marked with an `#[ignored]`. This ensures that anyone can run the test suite locally without needing to pre-configure their environment. The `#[ignored]` attribute is bypassed during CI runs in GitHub Actions.
Unit tests should be fully isolated, only testing a given function's expected output given a specific input, and should be reproducible on any machine. Unit tests should not expect the computer running them to be in any particular state. This includes having any applications pre-installed, having any environment variables set, etc.
The previous point should be emphasized: even seemingly innocuous ideas like "if we can see the directory, we can read it" or "nobody will have their home directory be a git repo" have bitten us in the past. Having even a single test fail can completely break installation on some platforms, so be careful with tests!
### Acceptance Testing
### Test Programming Guidelines
Acceptance tests are located in the [`tests/`](tests) directory and are also written using the built-in Rust testing library.
Any tests that depend on File I/O should use [`sync_all()`](https://doc.rust-lang.org/std/fs/struct.File.html#method.sync_all) when creating files or after writing to files.
Acceptance tests should test full modules or the entire prompt. All integration tests expecting the testing environment to have preexisting state or making permanent changes to the filesystem should have the `#[ignore]` attribute. These tests will be run in a Docker container, by running the included [`./integration_test`](integration_test) script. All tests that don't depend on any preexisting state will be run alongside the unit tests with `cargo test`.
Any tests that use `tempfile::tempdir` should take care to call `dir.close()` after usage to ensure the lifecycle of the directory can be reasoned about. This includes `fixture_repo()` as it returns a TempDir that should be closed.
For tests that depend on having preexisting state, whatever needed state will have to be added to the project's Dockerfile ([`tests/Dockerfile`](tests/Dockerfile)) as well as the project's Azure Pipelines configuration ([`azure-pipelines.yml`](azure-pipelines.yml)).
## Documentation
The reason for having _both_ the Dockerfile as well as the Azure Pipelines configuration is in order to allow acceptance tests to be run on your local development environment via Docker, while also running our test suite on all supported OSes (Windows, Mac, Linux) on Azure Pipelines.
### Crowdin Translated Pages
### Benchmarking
Many documentation pages have versions in non-English languages. These
translated pages are managed by
[Crowdin](https://crowdin.com/project/starship-prompt). Please do not edit
these pages directly, even for changes that do not need to be translated (e.g.
whitespace or emoji changes), since this can cause merges to fail.
Benchmarks are located in the [`benches/`](benches) directory and are written using the [Criterion](https://crates.io/crates/criterion) library.
If you would like to contribute translations or corrections to the Crowdin
generated pages, please visit our Crowdin site.
For the time being, benchmarks aren't actively used, but we plan to integrate benchmark comparison reporting into our CI pipeline in the near future. For the time being, they can be manually run with `cargo bench`.
### Running the Documentation Website Locally
Changes to documentation can be viewed in a rendered state from the GitHub PR page
(go to the CI section at the bottom of the page and look for "deploy preview", then
click on "details"). If you want to view changes locally as well, follow these steps.
After cloning the project, you can do the following to run the VuePress website on your local machine:
1.`cd` into the `/docs` directory.
2. Install the project dependencies:
```sh
npm install
```
3. Start the project in development mode:
```sh
npm run dev
```
Once setup is complete, you can refer to VuePress documentation on the actual implementation here: <https://vuepress.vuejs.org/guide/>.
## Git/GitHub workflow
This is our preferred process for opening a PR on GitHub:
1. Fork this repository
2. Create a branch off of `master` for your work: `git checkout -b my-feature-branch`
3. Make some changes, committing them along the way
4. When your changes are ready for review, push your branch: `git push origin my-feature-branch`
5. Create a pull request from your branch to `starship/master`
6. No need to assign the pull request to anyone, we'll review it when we can
7. When the changes have been reviewed and approved, someone will squash and merge for you
**The minimal, blazing-fast, and infinitely customizable prompt for any shell!**
- **Fast:** it's fast –_really really_ fast! 🚀
- **Customizable:** configure every aspect of your prompt.
- **Universal:** works on any shell, on any operating system.
- **Intelligent:** shows relevant information at a glance.
- **Feature rich:** support for all your favorite tools.
- **Easy:** quick to install – start using it in minutes.
<p align="center">
<br>
<img alt="Starship with iTerm2 and the Snazzy theme" src="https://raw.githubusercontent.com/starship/starship/master/media/demo.gif" width="80%">
<br>
<br>
<a href="https://starship.rs/config/"><strong>Explore the Starship docs ▶</strong></a>
</p>
## 🍬 Features
- Prompt character turns red if the last command exits with non-zero code
- Current username if not the same as the logged-in user
- Current Node.js version(`⬢`)
- Current Rust version (`🦀`)
- Current Ruby version (`💎`)
- Current Python version (`🐍`)
- Current Go version (`🐹`)
- Nix-shell environment detection
- Current version of package in current directory (`📦`)
- npm (Node.js)
- cargo (Rust)
- poetry (Python)
- Current battery level and status
- Current Git branch and rich repo status:
-`=` — conflicting changes
-`⇡` — ahead of remote branch
-`⇣` — behind of remote branch
-`⇕` — diverged changes
-`?` — untracked changes
-`$` — stashed changes
-`!` — modified files
-`+` — added files
-`»` — renamed files
-`✘` — deleted files
- Execution time of the last command if it exceeds the set threshold
- Indicator for jobs in the background (`✦`)
<a name="🚀-installation"></a>
## 🚀 Installation
### Prerequisites
- A [Powerline font](https://github.com/powerline/fonts) installed and enabled in your terminal (for example, try [Fira Code](https://github.com/tonsky/FiraCode)).
- A [Nerd Font](https://www.nerdfonts.com/) installed and enabled in your terminal (for example, try the [Fira Code Nerd Font](https://www.nerdfonts.com/font-downloads)).
### Getting Started
**Note**: due to the proliferation of different platforms, only a subset of supported platforms are
shown below. Can't see yours? Have a look at the [extra platform instructions](https://starship.rs/installing/).
1. Install the **starship** binary:
**[Download archives of precompiled binaries](https://github.com/starship/starship/releases)** if you don't use the platforms below.
#### Install Latest Version
#### Homebrew
##### From prebuilt binary, with Shell:
```sh
$ brew install starship
curl -fsSL https://starship.rs/install.sh | bash
```
#### Rust (v1.33 or higher)
#### Install via Package Manager
##### Example: [Homebrew](https://brew.sh/):
```sh
$ cargo install starship
brew install starship
```
#### Arch Linux (AUR)
##### With [Scoop](https://scoop.sh):
Starship is available on the AUR under the name `starship`. Install it with `yay` or your favorite AUR helper.
```sh
$ yay -S starship
```powershell
scoop install starship
```
#### Nix (unstable)
```sh
$ nix-env --install starship
```
1. Add the init script to your shell's config file:
2. Add the init script to your shell's config file:
#### Bash
@@ -138,7 +193,7 @@ The prompt shows information you need while you're working, while staying sleek
```sh
# ~/.config/fish/config.fish
eval (starship init fish)
starship init fish | source
```
#### Zsh
@@ -151,64 +206,94 @@ The prompt shows information you need while you're working, while staying sleek
eval "$(starship init zsh)"
```
## 🔧 Configuration
#### PowerShell
For details on how to configure Starship, check out our [documentation](https://starship.rs/config/).
Add the following to the end of `Microsoft.PowerShell_profile.ps1`. You can check the location of this file by querying the `$PROFILE` variable in PowerShell. Typically the path is `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` or `~/.config/powershell/Microsoft.PowerShell_profile.ps1` on -Nix.
```powershell
Invoke-Expression (&starship init powershell)
```
#### Ion
Add the following to the end of `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
**Warning** Only elvish v0.15 or higher is supported.
Add the following to the end of `~/.elvish/rc.elv`:
```sh
# ~/.elvish/rc.elv
eval (starship init elvish)
```
#### Tcsh
Add the following to the end of `~/.tcshrc`:
```sh
# ~/.tcshrc
eval `starship init tcsh`
```
## 🤝 Contributing
We are always looking for contributors of **all skill levels**! If you're looking to ease your way into the project, try out a [good first issue](https://github.com/starship/starship/labels/🌱%20good%20first%20issue).
### High Priority Needs
- 👩💼 **Product Manager**
- We have a GitHub Project and many unorganized/unprioritized features, as well as ideas that haven't yet been made into issues. Starship needs someone to own the product direction!
- 👩🎨 **Designer**
- Like making eye-catching websites? Excellent! We are looking to create a beautiful landing page showing off Starship in all its glory. Helping design for Starship's brand is a great opportunity to try out new ideas!
- 👩💻 **Rust Developer**
- There is _a lot_ of low-hanging fruit when it comes to writing idiomatic Rust, designing effective Rust architecture, performance optimizations, cross-platform build optimizations, and more! I ([@matchai](https://github.com/matchai)) am a beginner to Rust. Come point us in the right direction!
If you are fluent in a non-English language, we greatly appreciate any help keeping our docs translated and up-to-date in other languages. If you would like to help, translations can be contributed on the [Starship Crowdin](https://translate.starship.rs/).
If you are interested in helping contribute to starship, please take a look at our [Contributing Guide](https://github.com/starship/starship/blob/master/CONTRIBUTING.md). Also, feel free to drop into our [Discord server](https://discord.gg/8Jzqu3T) and say hi. 👋
### Contributors
### Code Contributors
Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/docs/en/emoji-key)):
This project exists thanks to all the people who contribute. [[Contribute](https://github.com/starship/starship/blob/master/CONTRIBUTING.md)].
Support this project with your organization. Your logo will show up here with a link to your website. [[Contribute](https://opencollective.com/starship/contribute)]
["meta",{property:"og:description",content:"Starship is the minimal, blazing fast, and extremely customizable prompt for any shell! Shows the information you need, while staying sleek and minimal. Quick installation available for Bash, Fish, ZSH, Ion, and Powershell."}],
["meta",{name:"twitter:description",content:"Starship is the minimal, blazing fast, and extremely customizable prompt for any shell! Shows the information you need, while staying sleek and minimal. Quick installation available for Bash, Fish, ZSH, Ion, and Powershell."}],
description: Starship is the minimal, blazing fast, and extremely customizable prompt for any shell! Shows the information you need, while staying sleek and minimal. Quick installation available for Bash, Fish, ZSH, Ion, and PowerShell.
---
<div class="features">
<div class="feature">
<h2>Compatibility First</h2>
<p>Works on the most common shells on the most common operating systems. Use it everywhere!</p>
</div>
<div class="feature">
<h2>Rust-Powered</h2>
<p>Brings the best-in-class speed and safety of Rust, to make your prompt as quick and reliable as possible.</p>
</div>
<div class="feature">
<h2>Customizable</h2>
<p>Every little detail is customizable to your liking, to make this prompt as minimal or feature-rich as you'd like it to be.</p>
Add the following to the end of `Microsoft.PowerShell_profile.ps1`. You can check the location of this file by querying the `$PROFILE` variable in PowerShell. Typically the path is `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` or `~/.config/powershell/Microsoft.PowerShell_profile.ps1` on -Nix.
```sh
Invoke-Expression (&starship init powershell)
```
#### Ion
Add the following to the end of `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
::: warning
Only elvish v0.15 or higher is supported.
:::
Add the following to the end of `~/.elvish/rc.elv`:
If you like the result, add these lines to your shell configuration file
(`~/.bashrc` or `~/.zsrhc`) to make it permanent.
(`~/.bashrc` or `~/.zshrc`) to make it permanent.
For example, if you want to display your current directory in your terminal tab title,
add the following snippet to your `~/.bashrc` or `~/.zshrc`:
```bash
function set_win_title(){
echo -ne "\033]0; $(basename $PWD) \007"
}
starship_precmd_user_func="set_win_title"
```
## Style Strings
Style strings are a list of words, separated by whitespace. The words are not case sensitive (i.e. `bold` and `BoLd` are considered the same string). Each word can be one of the following:
-`bold`
-`underline`
-`dimmed`
-`bg:<color>`
-`fg:<color>`
-`<color>`
-`none`
where `<color>` is a color specifier (discussed below). `fg:<color>` and `<color>` currently do the same thing , though this may change in the future. The order of words in the string does not matter.
The `none` token overrides all other tokens in a string if it is not part of a `bg:` specifier, so that e.g. `fg:red none fg:blue` will still create a string with no styling. `bg:none` sets the background to the default color so `fg:red bg:none` is equivalent to `red` or `fg:red` and `bg:green fg:red bg:none` is also equivalent to `fg:red` or `red`. It may become an error to use `none` in conjunction with other tokens in the future.
A color specifier can be one of the following:
- One of the standard terminal colors: `black`, `red`, `green`, `blue`,
`yellow`, `purple`, `cyan`, `white`. You can optionally prefix these
with `bright-` to get the bright version (e.g. `bright-white`).
- A `#` followed by a six-digit hexadecimal number. This specifies an
[RGB color hex code](https://www.w3schools.com/colors/colors_hexadecimal.asp).
- A number between 0-255. This specifies an [8-bit ANSI Color Code](https://i.stack.imgur.com/KTSQa.png).
If multiple colors are specified for foreground/background, the last one in the string will take priority.
description: Starship is the minimal, blazing fast, and extremely customizable prompt for any shell! Shows the information you need, while staying sleek and minimal. Quick installation available for Bash, Fish, ZSH, Ion, and PowerShell.
1. Add the init script to your shell's config file:
#### Bash
Add the following to the end of `~/.bashrc`:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
Add the following to the end of `~/.config/fish/config.fish`:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
Add the following to the end of `~/.zshrc`:
```sh
# ~/.zshrc
eval "$(starship init zsh)"
```
#### Powershell
Add the following to the end of `Microsoft.PowerShell_profile.ps1`. You can check the location of this file by querying the `$PROFILE` variable in PowerShell. Typically the path is `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` or `~/.config/powershell/Microsoft.PowerShell_profile.ps1` on -Nix.
```sh
Invoke-Expression (&starship init powershell)
```
#### Ion
Add the following to the end of `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
::: warning Only elvish v0.15 or higher is supported. :::
Add the following to the end of `~/.elvish/rc.elv`:
While Starship is a versatile shell, sometimes you need to do more than edit `starship.toml` to get it to do certain things. This page details some of the more advanced configuration techniques used in starship.
::: warning
The configurations in this section are subject to change in future releases of Starship.
:::
## Custom pre-prompt and pre-execution Commands in Bash
Bash does not have a formal preexec/precmd framework like most other shells. Because of this, it is difficult to provide fully customizable hooks in `bash`. However, Starship does give you limited ability to insert your own functions into the prompt-rendering procedure:
- To run a custom function right before the prompt is drawn, define a new function and then assign its name to `starship_precmd_user_func`. For example, to draw a rocket before the prompt, you would do
```bash
function blastoff(){
echo"🚀"
}
starship_precmd_user_func="blastoff"
```
- To run a custom function right before a command runs, you can use the [`DEBUG` trap mechanism](https://jichu4n.com/posts/debug-trap-and-prompt_command-in-bash/). However, you **must** trap the DEBUG signal *before* initializing Starship! Starship can preserve the value of the DEBUG trap, but if the trap is overwritten after starship starts up, some functionality will break.
Some shell prompts will automatically change the window title for you (e.g. to reflect your working directory). Fish even does it by default. Starship does not do this, but it's fairly straightforward to add this functionality to `bash` or `zsh`.
First, define a window title change function (identical in bash and zsh):
```bash
function set_win_title(){
echo -ne "\033]0; YOUR_WINDOW_TITLE_HERE \007"
}
```
You can use variables to customize this title (`$USER`, `$HOSTNAME`, and `$PWD` are popular choices).
In `bash`, set this function to be the precmd starship function:
```bash
starship_precmd_user_func="set_win_title"
```
In `zsh`, add this to the `precmd_functions` array:
```bash
precmd_functions+=(set_win_title)
```
If you like the result, add these lines to your shell configuration file (`~/.bashrc` or `~/.zshrc`) to make it permanent.
For example, if you want to display your current directory in your terminal tab title, add the following snippet to your `~/.bashrc` or `~/.zshrc`:
```bash
function set_win_title(){
echo -ne "\033]0; $(basename $PWD) \007"
}
starship_precmd_user_func="set_win_title"
```
## Style Strings
Style strings are a list of words, separated by whitespace. The words are not case sensitive (i.e. `bold` and `BoLd` are considered the same string). Each word can be one of the following:
-`bold`
-`underline`
-`dimmed`
-`bg:<color>`
-`fg:<color>`
-`<color>`
-`none`
where `<color>` is a color specifier (discussed below). `fg:<color>` and `<color>` currently do the same thing , though this may change in the future. The order of words in the string does not matter.
The `none` token overrides all other tokens in a string if it is not part of a `bg:` specifier, so that e.g. `fg:red none fg:blue` will still create a string with no styling. `bg:none` sets the background to the default color so `fg:red bg:none` is equivalent to `red` or `fg:red` and `bg:green fg:red bg:none` is also equivalent to `fg:red` or `red`. It may become an error to use `none` in conjunction with other tokens in the future.
A color specifier can be one of the following:
- One of the standard terminal colors: `black`, `red`, `green`, `blue`, `yellow`, `purple`, `cyan`, `white`. You can optionally prefix these with `bright-` to get the bright version (e.g. `bright-white`).
- A `#` followed by a six-digit hexadecimal number. This specifies an [RGB color hex code](https://www.w3schools.com/colors/colors_hexadecimal.asp).
- A number between 0-255. This specifies an [8-bit ANSI Color Code](https://i.stack.imgur.com/KTSQa.png).
If multiple colors are specified for foreground/background, the last one in the string will take priority.
## How do I get command completion as shown in the demo GIF?
Completion support, or autocomplete, is provided by your shell of choice. In the case of the demo, the demo was done with [Fish Shell](https://fishshell.com/), which provides completions by default. If you use Z Shell (zsh), I'd suggest taking a look at [zsh-autosuggestions](https://github.com/zsh-users/zsh-autosuggestions).
## Do top level `format` and `<module>.disabled` do the same thing?
Yes, they can both be used to disable modules in the prompt. If all you plan to do is disable modules, `<module>.disabled` is the preferred way to do so for these reasons:
- Disabling modules is more explicit than omitting them from the top level `format`
- Newly created modules will be added to the prompt as Starship is updated
## The docs say Starship is cross-shell. Why isn't my preferred shell supported?
The way Starship is built, it should be possible to add support for virtually any shell. The starship binary is stateless and shell agnostic, so as long as your shell supports prompt customization and shell expansion, Starship can be used.
Here's a small example getting Starship working with bash:
```sh
# Get the status code from the last command executed
STATUS=$?
# Get the number of jobs running.
NUM_JOBS=$(jobs -p | wc -l)
# Set the prompt to the output of `starship prompt`
The [Bash implementation](https://github.com/starship/starship/blob/master/src/init/starship.bash) built into Starship is slightly more complex to allow for advanced features like the [Command Duration module](https://starship.rs/config/#command-duration) and to ensure that Starship is compatible with pre-installed Bash configurations.
For a list of all flags accepted by `starship prompt`, use the following command:
```sh
starship prompt --help
```
The prompt will use as much context as is provided, but no flags are "required".
## How do I run Starship on Linux distributions with older versions of glibc?
If you get an error like "_version 'GLIBC_2.18' not found (required by starship)_" when using the prebuilt binary (for example, on CentOS 6 or 7), you can use a binary compiled with `musl` instead of `glibc`:
## I see symbols I don't understand or expect, what do they mean?
If you see symbols that you don't recognise you can use `starship explain` to explain the currently showing modules.
## Why don't I see a glyph symbol in my prompt?
The most common cause of this is system misconfiguration. Some Linux distros in particular do not come with font support out-of-the-box. You need to ensure that:
- Your locale is set to a UTF-8 value, like `de_DE.UTF-8` or `ja_JP.UTF-8`. If `LC_ALL` is not a UTF-8 value, [you will need to change it](https://www.tecmint.com/set-system-locales-in-linux/).
- You have an emoji font installed. Most systems come with an emoji font by default, but some (notably Arch Linux) do not. You can usually install one through your system's package manager--[noto emoji](https://www.google.com/get/noto/help/emoji/) is a popular choice.
- You are using a [Nerd Font](https://www.nerdfonts.com/).
To test your system, run the following commands in a terminal:
```sh
echo -e "\xf0\x9f\x90\x8d"
echo -e "\xee\x82\xa0"
```
The first line should produce a [snake emoji](https://emojipedia.org/snake/), while the second should produce a [powerline branch symbol (e0a0)](https://github.com/ryanoasis/powerline-extra-symbols#glyphs).
If either symbol fails to display correctly, your system is still misconfigured. Unfortunately, getting font configuration correct is sometimes difficult. Users on the Discord may be able to help. If both symbols display correctly, but you still don't see them in starship, [file a bug report!](https://github.com/starship/starship/issues/new/choose)
## How do I uninstall Starship?
Starship is just as easy to uninstall as it is to install in the first place.
1. Remove any lines in your shell config (e.g. `~/.bashrc`) used to initialize Starship.
1. Delete the Starship binary.
If Starship was installed using a package manager, please refer to their docs for uninstallation instructions.
If Starship was installed using the `curl | bash` script, the following command will delete the binary:
**The minimal, blazing-fast, and infinitely customizable prompt for any shell!**
- **Fast:** it's fast –_really really_ fast! 🚀
- **Customizable:** configure every aspect of your prompt.
- **Universal:** works on any shell, on any operating system.
- **Intelligent:** shows relevant information at a glance.
- **Feature rich:** support for all your favorite tools.
- **Easy:** quick to install – start using it in minutes.
<p align="center">
<a href="https://starship.rs/config/"><strong>Explore the Starship docs ▶</strong></a>
</p>
<a name="🚀-installation"></a>
## 🚀 Installation
### Prerequisites
- A [Nerd Font](https://www.nerdfonts.com/) installed and enabled in your terminal (for example, try the [Fira Code Nerd Font](https://www.nerdfonts.com/font-downloads)).
### Getting Started
**Note**: due to the proliferation of different platforms, only a subset of supported platforms are shown below. Can't see yours? Have a look at the [extra platform instructions](https://starship.rs/installing/).
1. Install the **starship** binary:
#### Install Latest Version
##### From prebuilt binary, with Shell:
```sh
curl -fsSL https://starship.rs/install.sh | bash
```
#### Install via Package Manager
##### Example: [Homebrew](https://brew.sh/):
```sh
brew install starship
```
##### With [Scoop](https://scoop.sh):
```powershell
scoop install starship
```
2. Add the init script to your shell's config file:
#### Bash
Add the following to the end of `~/.bashrc`:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
Add the following to the end of `~/.config/fish/config.fish`:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
Add the following to the end of `~/.zshrc`:
```sh
# ~/.zshrc
eval "$(starship init zsh)"
```
#### PowerShell
Add the following to the end of `Microsoft.PowerShell_profile.ps1`. You can check the location of this file by querying the `$PROFILE` variable in PowerShell. Typically the path is `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` or `~/.config/powershell/Microsoft.PowerShell_profile.ps1` on -Nix.
```powershell
Invoke-Expression (&starship init powershell)
```
#### Ion
Add the following to the end of `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
**Warning** Only elvish v0.15 or higher is supported. Add the following to the end of `~/.elvish/rc.elv`:
```sh
# ~/.elvish/rc.elv
eval (starship init elvish)
```
#### Tcsh
Add the following to the end of `~/.tcshrc`:
```sh
# ~/.tcshrc
eval `starship init tcsh`
```
## 🤝 Contributing
We are always looking for contributors of **all skill levels**! If you're looking to ease your way into the project, try out a [good first issue](https://github.com/starship/starship/labels/🌱%20good%20first%20issue).
If you are fluent in a non-English language, we greatly appreciate any help keeping our docs translated and up-to-date in other languages. If you would like to help, translations can be contributed on the [Starship Crowdin](https://translate.starship.rs/).
If you are interested in helping contribute to starship, please take a look at our [Contributing Guide](https://github.com/starship/starship/blob/master/CONTRIBUTING.md). Also, feel free to drop into our [Discord server](https://discord.gg/8Jzqu3T) and say hi. 👋
### Code Contributors
This project exists thanks to all the people who contribute. [[Contribute](https://github.com/starship/starship/blob/master/CONTRIBUTING.md)].
Support this project with your organization. Your logo will show up here with a link to your website. [[Contribute](https://opencollective.com/starship/contribute)]
1. Tell your shell to use the starship binary as its prompt by modifying its init scripts
For most users, the instructions on [the main page](/guide/#🚀-installation) will work great. However, for some more specialized platforms, different instructions are needed.
There are so many platforms out there that they didn't fit into the main README.md file, so here are some installation instructions for other platforms from the community. Is yours not here? Please do add it here if you figure it out!
## [Chocolatey](https://chocolatey.org)
### Prerequisites
Head over to the [Chocolatey installation page](https://chocolatey.org/install) and follow the instructions to install Chocolatey.
Starship v0.45.0 is a release containing breaking changes, in preparation for the big v1.0.0. We have made some major changes around how configuration is done on the prompt, to allow for a greater degree of customization.
This guide is intended to walk you through the breaking changes.
## `prompt_order` has been replaced by a root-level `format`
Previously to v0.45.0, `prompt_order` would accept an array of module names in the order which they should be rendered by Starship.
Starship v0.45.0 instead accepts a `format` value, allowing for customization of the prompt outside of the modules themselves.
**Example pre-v0.45.0 configuration**
```toml
prompt_order=[
"username",
"hostname",
"directory",
"git_branch",
"git_commit",
"git_state",
"git_status",
"cmd_duration",
"custom",
"line_break",
"jobs",
"battery",
"time",
"character",
]
```
**Example v0.45.0 configuration**
```toml
format="""\
$username\
$hostname\
$directory\
$git_branch\
$git_commit\
$git_state\
$git_status\
$cmd_duration\
$custom\
$line_break\
$jobs\
$battery\
$time\
$character\
"""
```
## Module `prefix` and `suffix` have been replaced by `format`
Previously to v0.45.0, some modules would accept `prefix` and/or `suffix` in order to stylize the way that modules are rendered.
Starship v0.45.0 instead accepts a `format` value, allowing for further customization of how modules are rendered. Instead of defining a prefix and suffix for the context-based variables, the variables can now be substituted from within a format string, which represents the module's output.
**Example pre-v0.45.0 configuration**
```toml
[cmd_duration]
prefix="took "
```
**Example v0.45.0 configuration**
```toml
[cmd_duration]
# $duration – The command duration (e.g. "15s")
# $style – The default style of the module (e.g. "bold yellow")
format="took [$duration]($style) "
```
### Affected Modules
#### Character
| Removed Property | Replacement |
| ----------------------- | ---------------- |
| `symbol` | `success_symbol` |
| `use_symbol_for_status` | `error_symbol` |
| `style_success` | `success_symbol` |
| `style_failure` | `error_symbol` |
**Changes to the Default Configuration**
```diff
[character]
-- symbol = "❯"
-- error_symbol = "✖"
-- use_symbol_for_status = true
-- vicmd_symbol = "❮"
++ success_symbol = "[❯](bold green)"
++ error_symbol = "[❯](bold red)"
++ vicmd_symbol = "[❮](bold green)"
```
Previously, the `use_symbol_for_status` property was used to configure the prompt to show the `error_symbol` when the last command resulted in a non-zero status code.
With the release of v0.45.0, we now always use `error_symbol` after non-zero status codes, unifying `use_symbol_for_status` and `error_symbol` properties.
To configure the prompt to use the older `use_symbol_for_status = true` configuration, add the following to your config file:
```toml
[character]
error_symbol="[✖](bold red)"
```
*Note:* The `character` element automatically adds a space after, so unlike the other `format` strings, we specifically do not add one in the above examples.
#### Command Duration
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
**Changes to the Default Configuration**
```diff
[cmd_duration]
-- prefix = "took "
++ format = "took [$duration]($style) "
```
#### Directory
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
**Changes to the Default Configuration**
```diff
[directory]
-- prefix = "in "
++ format = "[$path]($style)[$read_only]($read_only_style) "
```
#### Environment Variable
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
| `suffix` | `format` |
**Changes to the Default Configuration**
```diff
[env_var]
-- prefix = ""
-- suffix = ""
++ format = "with [$env_value]($style) "
```
#### Git Commit
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
| `suffix` | `format` |
**Changes to the Default Configuration**
```diff
[git_commit]
-- prefix = "("
-- suffix = ")"
++ format = '[\($hash\)]($style) '
```
#### Git Status
| Removed Property | Replacement |
| ----------------- | ----------- |
| `prefix` | `format` |
| `suffix` | `format` |
| `show_sync_count` | `format` |
**Changes to the Default Configuration**
```diff
[git_status]
-- prefix = "["
-- suffix = "]"
-- show_sync_count = false
++ format = '([\[$all_status$ahead_behind\]]($style) )'
```
Previously, the `show_sync_count` property was used to configure the prompt to show the number of commits the branch was ahead or behind the remote branch.
With the release of v0.45.0, this has been replaced with three separate properties, `ahead`, `behind`, and `diverged`.
To configure the prompt to use the older `show_sync_count = true` configuration, set the following to your config file:
Here is a collection of community-submitted configuration presets for Starship. If you have a preset to share, please [submit a PR](https://github.com/starship/starship/edit/master/docs/presets/README.md) updating this file! 😊
## Nerd Font Symbols
This preset doesn't change anything except for the symbols used for each module. If emojis aren't your thing, this might catch your eye!
### Prerequisites
- A [Nerd Font](https://www.nerdfonts.com/) installed and enabled in your terminal (the example uses Fira Code Nerd Font)
description: Starship is the minimal, blazing fast, and extremely customizable prompt for any shell! Shows the information you need, while staying sleek and minimal. Quick installation available for Bash, Fish, ZSH, Ion, and PowerShell.
1. Add the init script to your shell's config file:
#### Bash
Add the following to the end of `~/.bashrc`:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
Add the following to the end of `~/.config/fish/config.fish`:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
Add the following to the end of `~/.zshrc`:
```sh
# ~/.zshrc
eval "$(starship init zsh)"
```
#### Powershell
Add the following to the end of `Microsoft.PowerShell_profile.ps1`. You can check the location of this file by querying the `$PROFILE` variable in PowerShell. Typically the path is `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` or `~/.config/powershell/Microsoft.PowerShell_profile.ps1` on -Nix.
```sh
Invoke-Expression (&starship init powershell)
```
#### Ion
Add the following to the end of `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
::: warning Only elvish v0.15 or higher is supported. :::
Add the following to the end of `~/.elvish/rc.elv`:
While Starship is a versatile shell, sometimes you need to do more than edit `starship.toml` to get it to do certain things. This page details some of the more advanced configuration techniques used in starship.
::: warning
The configurations in this section are subject to change in future releases of Starship.
:::
## Custom pre-prompt and pre-execution Commands in Bash
Bash does not have a formal preexec/precmd framework like most other shells. Because of this, it is difficult to provide fully customizable hooks in `bash`. However, Starship does give you limited ability to insert your own functions into the prompt-rendering procedure:
- To run a custom function right before the prompt is drawn, define a new function and then assign its name to `starship_precmd_user_func`. For example, to draw a rocket before the prompt, you would do
```bash
function blastoff(){
echo"🚀"
}
starship_precmd_user_func="blastoff"
```
- To run a custom function right before a command runs, you can use the [`DEBUG` trap mechanism](https://jichu4n.com/posts/debug-trap-and-prompt_command-in-bash/). However, you **must** trap the DEBUG signal *before* initializing Starship! Starship can preserve the value of the DEBUG trap, but if the trap is overwritten after starship starts up, some functionality will break.
Some shell prompts will automatically change the window title for you (e.g. to reflect your working directory). Fish even does it by default. Starship does not do this, but it's fairly straightforward to add this functionality to `bash` or `zsh`.
First, define a window title change function (identical in bash and zsh):
```bash
function set_win_title(){
echo -ne "\033]0; YOUR_WINDOW_TITLE_HERE \007"
}
```
You can use variables to customize this title (`$USER`, `$HOSTNAME`, and `$PWD` are popular choices).
In `bash`, set this function to be the precmd starship function:
```bash
starship_precmd_user_func="set_win_title"
```
In `zsh`, add this to the `precmd_functions` array:
```bash
precmd_functions+=(set_win_title)
```
If you like the result, add these lines to your shell configuration file (`~/.bashrc` or `~/.zshrc`) to make it permanent.
For example, if you want to display your current directory in your terminal tab title, add the following snippet to your `~/.bashrc` or `~/.zshrc`:
```bash
function set_win_title(){
echo -ne "\033]0; $(basename $PWD) \007"
}
starship_precmd_user_func="set_win_title"
```
## Style Strings
Style strings are a list of words, separated by whitespace. The words are not case sensitive (i.e. `bold` and `BoLd` are considered the same string). Each word can be one of the following:
-`bold`
-`underline`
-`dimmed`
-`bg:<color>`
-`fg:<color>`
-`<color>`
-`none`
where `<color>` is a color specifier (discussed below). `fg:<color>` and `<color>` currently do the same thing , though this may change in the future. The order of words in the string does not matter.
The `none` token overrides all other tokens in a string if it is not part of a `bg:` specifier, so that e.g. `fg:red none fg:blue` will still create a string with no styling. `bg:none` sets the background to the default color so `fg:red bg:none` is equivalent to `red` or `fg:red` and `bg:green fg:red bg:none` is also equivalent to `fg:red` or `red`. It may become an error to use `none` in conjunction with other tokens in the future.
A color specifier can be one of the following:
- One of the standard terminal colors: `black`, `red`, `green`, `blue`, `yellow`, `purple`, `cyan`, `white`. You can optionally prefix these with `bright-` to get the bright version (e.g. `bright-white`).
- A `#` followed by a six-digit hexadecimal number. This specifies an [RGB color hex code](https://www.w3schools.com/colors/colors_hexadecimal.asp).
- A number between 0-255. This specifies an [8-bit ANSI Color Code](https://i.stack.imgur.com/KTSQa.png).
If multiple colors are specified for foreground/background, the last one in the string will take priority.
## How do I get command completion as shown in the demo GIF?
Completion support, or autocomplete, is provided by your shell of choice. In the case of the demo, the demo was done with [Fish Shell](https://fishshell.com/), which provides completions by default. If you use Z Shell (zsh), I'd suggest taking a look at [zsh-autosuggestions](https://github.com/zsh-users/zsh-autosuggestions).
## Do top level `format` and `<module>.disabled` do the same thing?
Yes, they can both be used to disable modules in the prompt. If all you plan to do is disable modules, `<module>.disabled` is the preferred way to do so for these reasons:
- Disabling modules is more explicit than omitting them from the top level `format`
- Newly created modules will be added to the prompt as Starship is updated
## The docs say Starship is cross-shell. Why isn't my preferred shell supported?
The way Starship is built, it should be possible to add support for virtually any shell. The starship binary is stateless and shell agnostic, so as long as your shell supports prompt customization and shell expansion, Starship can be used.
Here's a small example getting Starship working with bash:
```sh
# Get the status code from the last command executed
STATUS=$?
# Get the number of jobs running.
NUM_JOBS=$(jobs -p | wc -l)
# Set the prompt to the output of `starship prompt`
The [Bash implementation](https://github.com/starship/starship/blob/master/src/init/starship.bash) built into Starship is slightly more complex to allow for advanced features like the [Command Duration module](https://starship.rs/config/#command-duration) and to ensure that Starship is compatible with pre-installed Bash configurations.
For a list of all flags accepted by `starship prompt`, use the following command:
```sh
starship prompt --help
```
The prompt will use as much context as is provided, but no flags are "required".
## How do I run Starship on Linux distributions with older versions of glibc?
If you get an error like "_version 'GLIBC_2.18' not found (required by starship)_" when using the prebuilt binary (for example, on CentOS 6 or 7), you can use a binary compiled with `musl` instead of `glibc`:
## I see symbols I don't understand or expect, what do they mean?
If you see symbols that you don't recognise you can use `starship explain` to explain the currently showing modules.
## Why don't I see a glyph symbol in my prompt?
The most common cause of this is system misconfiguration. Some Linux distros in particular do not come with font support out-of-the-box. You need to ensure that:
- Your locale is set to a UTF-8 value, like `de_DE.UTF-8` or `ja_JP.UTF-8`. If `LC_ALL` is not a UTF-8 value, [you will need to change it](https://www.tecmint.com/set-system-locales-in-linux/).
- You have an emoji font installed. Most systems come with an emoji font by default, but some (notably Arch Linux) do not. You can usually install one through your system's package manager--[noto emoji](https://www.google.com/get/noto/help/emoji/) is a popular choice.
- You are using a [Nerd Font](https://www.nerdfonts.com/).
To test your system, run the following commands in a terminal:
```sh
echo -e "\xf0\x9f\x90\x8d"
echo -e "\xee\x82\xa0"
```
The first line should produce a [snake emoji](https://emojipedia.org/snake/), while the second should produce a [powerline branch symbol (e0a0)](https://github.com/ryanoasis/powerline-extra-symbols#glyphs).
If either symbol fails to display correctly, your system is still misconfigured. Unfortunately, getting font configuration correct is sometimes difficult. Users on the Discord may be able to help. If both symbols display correctly, but you still don't see them in starship, [file a bug report!](https://github.com/starship/starship/issues/new/choose)
## How do I uninstall Starship?
Starship is just as easy to uninstall as it is to install in the first place.
1. Remove any lines in your shell config (e.g. `~/.bashrc`) used to initialize Starship.
1. Delete the Starship binary.
If Starship was installed using a package manager, please refer to their docs for uninstallation instructions.
If Starship was installed using the `curl | bash` script, the following command will delete the binary:
**The minimal, blazing-fast, and infinitely customizable prompt for any shell!**
- **Fast:** it's fast –_really really_ fast! 🚀
- **Customizable:** configure every aspect of your prompt.
- **Universal:** works on any shell, on any operating system.
- **Intelligent:** shows relevant information at a glance.
- **Feature rich:** support for all your favorite tools.
- **Easy:** quick to install – start using it in minutes.
<p align="center">
<a href="https://starship.rs/config/"><strong>Explore the Starship docs ▶</strong></a>
</p>
<a name="🚀-installation"></a>
## 🚀 Installation
### Prerequisites
- A [Nerd Font](https://www.nerdfonts.com/) installed and enabled in your terminal (for example, try the [Fira Code Nerd Font](https://www.nerdfonts.com/font-downloads)).
### Getting Started
**Note**: due to the proliferation of different platforms, only a subset of supported platforms are shown below. Can't see yours? Have a look at the [extra platform instructions](https://starship.rs/installing/).
1. Install the **starship** binary:
#### Install Latest Version
##### From prebuilt binary, with Shell:
```sh
curl -fsSL https://starship.rs/install.sh | bash
```
#### Install via Package Manager
##### Example: [Homebrew](https://brew.sh/):
```sh
brew install starship
```
##### With [Scoop](https://scoop.sh):
```powershell
scoop install starship
```
2. Add the init script to your shell's config file:
#### Bash
Add the following to the end of `~/.bashrc`:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
Add the following to the end of `~/.config/fish/config.fish`:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
Add the following to the end of `~/.zshrc`:
```sh
# ~/.zshrc
eval "$(starship init zsh)"
```
#### PowerShell
Add the following to the end of `Microsoft.PowerShell_profile.ps1`. You can check the location of this file by querying the `$PROFILE` variable in PowerShell. Typically the path is `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` or `~/.config/powershell/Microsoft.PowerShell_profile.ps1` on -Nix.
```powershell
Invoke-Expression (&starship init powershell)
```
#### Ion
Add the following to the end of `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
**Warning** Only elvish v0.15 or higher is supported. Add the following to the end of `~/.elvish/rc.elv`:
```sh
# ~/.elvish/rc.elv
eval (starship init elvish)
```
#### Tcsh
Add the following to the end of `~/.tcshrc`:
```sh
# ~/.tcshrc
eval `starship init tcsh`
```
## 🤝 Contributing
We are always looking for contributors of **all skill levels**! If you're looking to ease your way into the project, try out a [good first issue](https://github.com/starship/starship/labels/🌱%20good%20first%20issue).
If you are fluent in a non-English language, we greatly appreciate any help keeping our docs translated and up-to-date in other languages. If you would like to help, translations can be contributed on the [Starship Crowdin](https://translate.starship.rs/).
If you are interested in helping contribute to starship, please take a look at our [Contributing Guide](https://github.com/starship/starship/blob/master/CONTRIBUTING.md). Also, feel free to drop into our [Discord server](https://discord.gg/8Jzqu3T) and say hi. 👋
### Code Contributors
This project exists thanks to all the people who contribute. [[Contribute](https://github.com/starship/starship/blob/master/CONTRIBUTING.md)].
Support this project with your organization. Your logo will show up here with a link to your website. [[Contribute](https://opencollective.com/starship/contribute)]
1. Tell your shell to use the starship binary as its prompt by modifying its init scripts
For most users, the instructions on [the main page](/guide/#🚀-installation) will work great. However, for some more specialized platforms, different instructions are needed.
There are so many platforms out there that they didn't fit into the main README.md file, so here are some installation instructions for other platforms from the community. Is yours not here? Please do add it here if you figure it out!
## [Chocolatey](https://chocolatey.org)
### Prerequisites
Head over to the [Chocolatey installation page](https://chocolatey.org/install) and follow the instructions to install Chocolatey.
Starship v0.45.0 is a release containing breaking changes, in preparation for the big v1.0.0. We have made some major changes around how configuration is done on the prompt, to allow for a greater degree of customization.
This guide is intended to walk you through the breaking changes.
## `prompt_order` has been replaced by a root-level `format`
Previously to v0.45.0, `prompt_order` would accept an array of module names in the order which they should be rendered by Starship.
Starship v0.45.0 instead accepts a `format` value, allowing for customization of the prompt outside of the modules themselves.
**Example pre-v0.45.0 configuration**
```toml
prompt_order=[
"username",
"hostname",
"directory",
"git_branch",
"git_commit",
"git_state",
"git_status",
"cmd_duration",
"custom",
"line_break",
"jobs",
"battery",
"time",
"character",
]
```
**Example v0.45.0 configuration**
```toml
format="""\
$username\
$hostname\
$directory\
$git_branch\
$git_commit\
$git_state\
$git_status\
$cmd_duration\
$custom\
$line_break\
$jobs\
$battery\
$time\
$character\
"""
```
## Module `prefix` and `suffix` have been replaced by `format`
Previously to v0.45.0, some modules would accept `prefix` and/or `suffix` in order to stylize the way that modules are rendered.
Starship v0.45.0 instead accepts a `format` value, allowing for further customization of how modules are rendered. Instead of defining a prefix and suffix for the context-based variables, the variables can now be substituted from within a format string, which represents the module's output.
**Example pre-v0.45.0 configuration**
```toml
[cmd_duration]
prefix="took "
```
**Example v0.45.0 configuration**
```toml
[cmd_duration]
# $duration – The command duration (e.g. "15s")
# $style – The default style of the module (e.g. "bold yellow")
format="took [$duration]($style) "
```
### Affected Modules
#### Character
| Removed Property | Replacement |
| ----------------------- | ---------------- |
| `symbol` | `success_symbol` |
| `use_symbol_for_status` | `error_symbol` |
| `style_success` | `success_symbol` |
| `style_failure` | `error_symbol` |
**Changes to the Default Configuration**
```diff
[character]
-- symbol = "❯"
-- error_symbol = "✖"
-- use_symbol_for_status = true
-- vicmd_symbol = "❮"
++ success_symbol = "[❯](bold green)"
++ error_symbol = "[❯](bold red)"
++ vicmd_symbol = "[❮](bold green)"
```
Previously, the `use_symbol_for_status` property was used to configure the prompt to show the `error_symbol` when the last command resulted in a non-zero status code.
With the release of v0.45.0, we now always use `error_symbol` after non-zero status codes, unifying `use_symbol_for_status` and `error_symbol` properties.
To configure the prompt to use the older `use_symbol_for_status = true` configuration, add the following to your config file:
```toml
[character]
error_symbol="[✖](bold red)"
```
*Note:* The `character` element automatically adds a space after, so unlike the other `format` strings, we specifically do not add one in the above examples.
#### Command Duration
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
**Changes to the Default Configuration**
```diff
[cmd_duration]
-- prefix = "took "
++ format = "took [$duration]($style) "
```
#### Directory
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
**Changes to the Default Configuration**
```diff
[directory]
-- prefix = "in "
++ format = "[$path]($style)[$read_only]($read_only_style) "
```
#### Environment Variable
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
| `suffix` | `format` |
**Changes to the Default Configuration**
```diff
[env_var]
-- prefix = ""
-- suffix = ""
++ format = "with [$env_value]($style) "
```
#### Git Commit
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
| `suffix` | `format` |
**Changes to the Default Configuration**
```diff
[git_commit]
-- prefix = "("
-- suffix = ")"
++ format = '[\($hash\)]($style) '
```
#### Git Status
| Removed Property | Replacement |
| ----------------- | ----------- |
| `prefix` | `format` |
| `suffix` | `format` |
| `show_sync_count` | `format` |
**Changes to the Default Configuration**
```diff
[git_status]
-- prefix = "["
-- suffix = "]"
-- show_sync_count = false
++ format = '([\[$all_status$ahead_behind\]]($style) )'
```
Previously, the `show_sync_count` property was used to configure the prompt to show the number of commits the branch was ahead or behind the remote branch.
With the release of v0.45.0, this has been replaced with three separate properties, `ahead`, `behind`, and `diverged`.
To configure the prompt to use the older `show_sync_count = true` configuration, set the following to your config file:
Here is a collection of community-submitted configuration presets for Starship. If you have a preset to share, please [submit a PR](https://github.com/starship/starship/edit/master/docs/presets/README.md) updating this file! 😊
## Nerd Font Symbols
This preset doesn't change anything except for the symbols used for each module. If emojis aren't your thing, this might catch your eye!
### Prerequisites
- A [Nerd Font](https://www.nerdfonts.com/) installed and enabled in your terminal (the example uses Fira Code Nerd Font)
tagline: Minimale, super schnelle und unendlich anpassbare Prompt für jede Shell!
actionText: Loslegen →
actionLink: ./guide/
features:
-
title: Kompatibel
details: Läuft mit den beliebtesten Shells auf den beliebtesten Betriebssystemen. Überall einsetzbar!
-
title: Rust-Powered
details: Bringt die schnelligkeit und zuverlässigkeit von Rust in deinen Shell-prompt.
-
title: Individualisierbar
details: Jedes noch so kleine Detail kann nach Deinen Wünschen angepasst werden, um die Eingabeaufforderung so minimal oder funktionsreich zu gestalten, wie Du es möchtest.
description: Starship ist eine minimale, super schnelle, und extrem anpassbare Prompt für jede Shell! Shows the information you need, while staying sleek and minimal. Schnellinstallation verfügbar für Bash, Fish, ZSH, Ion und PowerShell.
1. Füge das init-Skript zur Konfigurationsdatei deiner Shell hinzu:
#### Bash
Trage folgendes am Ende der `~/.bashrc` ein:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
Trage folgendes am Ende der `~/.config/fish/config.fish` ein:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
Trage folgendes am Ende der `~/.zshrc` ein:
```sh
# ~/.zshrc
eval "$(starship init zsh)"
```
#### Powershell
Add the following to the end of `Microsoft.PowerShell_profile.ps1`. You can check the location of this file by querying the `$PROFILE` variable in PowerShell. Typically the path is `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` or `~/.config/powershell/Microsoft.PowerShell_profile.ps1` on -Nix.
```sh
Invoke-Expression (&starship init powershell)
```
#### Ion
Trage folgendes am Ende der `~/.config/ion/initrc` ein:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
::: warning Only elvish v0.15 or higher is supported. :::
Add the following to the end of `~/.elvish/rc.elv`:
Auch wenn Starship eine vielseitige Shell ist, reichen manche Konfigurationen in der `starship.toml` nicht aus, um erweiterte Einstellungen vorzunehmen. Diese Seite beschreibt einige fortgeschrittene Konfigurationen für Starship.
::: Warnung
Die hier beschriebenen Konfigurationen werden sich mit kommenden Updates von Starship verändern.
:::
## Benutzerdefinierte Pre-Prompt- und Pre-Execution-Befehle in der Bash
Die Bash Shell hat, im Gegensatz zu vielen anderen Shells, kein konventionelles preexec/precmd Framework. Daher gestaltet es sich schwierig, vollständig anpassbare Hooks für `bash` anzubieten. Starship bietet daher die begrenzte Möglichkeit, eigene Funktionen in das prompt rendering Verfahren einzufügen:
- Um eine benutzerdefinierte Funktion kurz vor Anzeige der Eingabeaufforderung auszuführen, definiere eine neue Funktion und weise den Namen `starship_precmd_user_func` zu. Um beispielsweise eine Rakete anzuzeigen, bevor die Eingabeaufforderung erscheint, würde man folgendes tun
```bash
function blastoff(){
echo "🚀"
}
starship_precmd_user_func="blastoff"
```
- Um eine benutzerdefinierte Funktion direkt vor der Ausführung eines Befehls auszulösen, kann man den [`DEBUG` trap](https://jichu4n.com/posts/debug-trap-and-prompt_command-in-bash/) Mechanismus verwenden. Allerdings **muss** das DEBUG Signal *vor* der Initialisierung von Starship getrapped werden! Starship kann den Wert der DEBUG-trap speichern. Wenn der Wert der DEBUG-trap überschrieben wird nachdem Starship gestartet ist kann es zu Fehlern im Bezug auf die verwendete DEBUG-trap kommen.
Manche shell prompts können den Fenstertitel ändern. Fish ist standardmäßig so konfiguriert. Starship ändert standardmäßig den Fenstertitel nicht, aber es ist sehr einfach die Funktion zu `bash` oder `zsh` hinzuzufügen.
Zuerst wird eine Funktion definiert um den Fenstertitel zu ändern ( für bash und zsh ist die Funktion identisch):
```bash
function set_win_title(){
echo -ne "\033]0; DEIN_FENSTERTITEL_HIER \007"
}
```
Sie können Variablen verwenden, um diesen Titel anzupassen (`$USER`, `$HOSTNAME`, `$PWD`).
Für `bash` muss die Funktion als "precmd starship"-Funktion gesetzt werden:
```bash
starship_precmd_user_func="set_win_title"
```
Füge dies in `Zsh` zum `precmd_functions`-Array hinzu:
```bash
precmd_functions+=(set_win_title)
```
If you like the result, add these lines to your shell configuration file (`~/.bashrc` or `~/.zshrc`) to make it permanent.
For example, if you want to display your current directory in your terminal tab title, add the following snippet to your `~/.bashrc` or `~/.zshrc`:
```bash
function set_win_title(){
echo -ne "\033]0; $(basename $PWD) \007"
}
starship_precmd_user_func="set_win_title"
```
## Style-Strings
Style-String sind Wortlisten, getrennt durch Leerzeichen. Die Wörter haben keine Groß- und Kleinschreibung (z.B. `bold` und `BoLd` werden als dieselbe Zeichenkette betrachtet). Jedes Wort kann eines der folgenden sein:
- `bold`
- `underline`
- `dimmed`
- `bg:<color>`
- `fg:<color>`
- `<color>`
- `none`
wobei `<color>` eine Farbspezifikation ist (siehe unten). `fg:<color>` und `<color>` tun derzeit dasselbe , das kann sich in Zukunft aber ändern. Die Reihenfolge der Wörter in der Liste spielt keine Rolle.
The `none` token overrides all other tokens in a string if it is not part of a `bg:` specifier, so that e.g. `fg:red none fg:blue` will still create a string with no styling. `bg:none` sets the background to the default color so `fg:red bg:none` is equivalent to `red` or `fg:red` and `bg:green fg:red bg:none` is also equivalent to `fg:red` or `red`. In der Zukunft könnte die Unterstützung von `none` in Verbindung mit anderen Tokens fallen gelassen werden.
Eine Farbspezifikation kann wie folgt aussehen:
- Einer der Standardfarben der Konsole: `black`, `red`, `green`, `blue`, `yellow`, `purple`, `cyan`, `white`. Optional kann ein `bright-` vorangestellt werden um die helle Version zu erhalten (z.B. `bright-white`).
- Eine `#` gefolgt von einer sechsstelligen Hexadezimalnummer. Dies ergibt einen [RGB hex Farbcode](https://www.w3schools.com/colors/colors_hexadecimal.asp).
- Eine Zahl zwischen 0-255. Dies ergibt einen [8-bit ANSI-Farbcode](https://i.stack.imgur.com/KTSQa.png).
Wenn mehrere Farben für Vordergrund oder Hintergrund angegeben werden, hat die letzte Farbe der Zeichenkette Priorität.
## How do I get command completion as shown in the demo GIF?
Completion support, or autocomplete, is provided by your shell of choice. In the case of the demo, the demo was done with [Fish Shell](https://fishshell.com/), which provides completions by default. If you use Z Shell (zsh), I'd suggest taking a look at [zsh-autosuggestions](https://github.com/zsh-users/zsh-autosuggestions).
## Do top level `format` and `<module>.disabled` do the same thing?
Ja, beide können benutzt werden, um Module in der Prompt zu deaktivieren. Wenn nur Module deaktiviert werden wollen, sollte `<module>.disabled` benutzt werden, aus den folgenden Gründen:
- Disabling modules is more explicit than omitting them from the top level `format`
- Mit der Aktualisierung von Starship werden neu erstellte Module an die Eingabezeile angefügt
## The docs say Starship is cross-shell. Why isn't my preferred shell supported?
Starship ist auf so eine Weise gebaut, das die Unterstützung so gut wie jeder Shell möglch sein sollte. Die Starship Binärdatei läuft völlig unabhängig von der Shell, und sollte auf jeder benutzt werden können, die eine Anpassung des Stils erlaubt.
Hier ist ein kleines Beispiel, wie man Starship auf bash zum Laufen bringt:
```sh
# Den Statuscode des zuletzt ausgeführten Befehls abrufen
STATUS=$?
# Gibt die Anzahl der laufenden Jobs an.
NUM_JOBS=$(jobs -p | wc -l)
# Set the prompt to the output of `starship prompt`
The [Bash implementation](https://github.com/starship/starship/blob/master/src/init/starship.bash) built into Starship is slightly more complex to allow for advanced features like the [Command Duration module](https://starship.rs/config/#command-duration) and to ensure that Starship is compatible with pre-installed Bash configurations.
Für eine Liste aller Flaggen, die von `Starship-Eingabeaufforderung` akzeptiert wird, verwenden Sie den folgenden Befehl:
```sh
starship prompt --help
```
Die Eingabeaufforderung verwendet so viel Kontext wie möglich, aber keine Flagge ist "notwendig".
## How do I run Starship on Linux distributions with older versions of glibc?
If you get an error like "_version 'GLIBC_2.18' not found (required by starship)_" when using the prebuilt binary (for example, on CentOS 6 or 7), you can use a binary compiled with `musl` instead of `glibc`:
## I see symbols I don't understand or expect, what do they mean?
If you see symbols that you don't recognise you can use `starship explain` to explain the currently showing modules.
## Why don't I see a glyph symbol in my prompt?
The most common cause of this is system misconfiguration. Some Linux distros in particular do not come with font support out-of-the-box. You need to ensure that:
- Your locale is set to a UTF-8 value, like `de_DE.UTF-8` or `ja_JP.UTF-8`. If `LC_ALL` is not a UTF-8 value, [you will need to change it](https://www.tecmint.com/set-system-locales-in-linux/).
- You have an emoji font installed. Most systems come with an emoji font by default, but some (notably Arch Linux) do not. You can usually install one through your system's package manager--[noto emoji](https://www.google.com/get/noto/help/emoji/) is a popular choice.
- You are using a [Nerd Font](https://www.nerdfonts.com/).
To test your system, run the following commands in a terminal:
```sh
echo -e "\xf0\x9f\x90\x8d"
echo -e "\xee\x82\xa0"
```
The first line should produce a [snake emoji](https://emojipedia.org/snake/), while the second should produce a [powerline branch symbol (e0a0)](https://github.com/ryanoasis/powerline-extra-symbols#glyphs).
If either symbol fails to display correctly, your system is still misconfigured. Unfortunately, getting font configuration correct is sometimes difficult. Users on the Discord may be able to help. If both symbols display correctly, but you still don't see them in starship, [file a bug report!](https://github.com/starship/starship/issues/new/choose)
## How do I uninstall Starship?
Starship is just as easy to uninstall as it is to install in the first place.
1. Remove any lines in your shell config (e.g. `~/.bashrc`) used to initialize Starship.
1. Delete the Starship binary.
If Starship was installed using a package manager, please refer to their docs for uninstallation instructions.
If Starship was installed using the `curl | bash` script, the following command will delete the binary:
**Minimale, super schnelle und unendlich anpassbare Prompt für jede Shell!**
- **Fast:** it's fast –_really really_ fast! 🚀
- **Customizable:** configure every aspect of your prompt.
- **Universal:** works on any shell, on any operating system.
- **Intelligent:** shows relevant information at a glance.
- **Feature rich:** support for all your favorite tools.
- **Easy:** quick to install – start using it in minutes.
<p align="center">
<a href="https://starship.rs/config/"><strong>Explore the Starship docs ▶</strong></a>
</p>
<a name="🚀-installation"></a>
## 🚀 Installation
### Voraussetzungen
- Eine [Nerd Schriftart](https://www.nerdfonts.com/) installiert und im Terminal aktiviert (zum Beispiel [Fira Code Nerd Font](https://www.nerdfonts.com/font-downloads)).
### Erste Schritte
**Note**: due to the proliferation of different platforms, only a subset of supported platforms are shown below. Can't see yours? Have a look at the [extra platform instructions](https://starship.rs/installing/).
1. Installiere **starship**:
#### Neueste Version installieren
##### Neuster GitHub Release über die Shell:
```sh
curl -fsSL https://starship.rs/install.sh | bash
```
#### Installation mithilfe eines Paket-Managers
##### Example: [Homebrew](https://brew.sh/):
```sh
brew install starship
```
##### Mit [scoop](https://scoop.sh):
```powershell
scoop install starship
```
2. Füge das init-Skript zur Konfigurationsdatei deiner Shell hinzu:
#### Bash
Trage folgendes am Ende der `~/.bashrc` ein:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
Trage folgendes am Ende der `~/.config/fish/config.fish` ein:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
Trage folgendes am Ende der `~/.zshrc` ein:
```sh
# ~/.zshrc
eval "$(starship init zsh)"
```
#### PowerShell
Add the following to the end of `Microsoft.PowerShell_profile.ps1`. You can check the location of this file by querying the `$PROFILE` variable in PowerShell. Typically the path is `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` or `~/.config/powershell/Microsoft.PowerShell_profile.ps1` on -Nix.
```powershell
Invoke-Expression (&starship init powershell)
```
#### Ion
Trage folgendes am Ende der `~/.config/ion/initrc` ein:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
**Warning** Only elvish v0.15 or higher is supported. Add the following to the end of `~/.elvish/rc.elv`:
```sh
# ~/.elvish/rc.elv
eval (starship init elvish)
```
#### Tcsh
Add the following to the end of `~/.tcshrc`:
```sh
# ~/.tcshrc
eval `starship init tcsh`
```
## 🤝 Mitwirken
Wir laden Leute **aller Erfahrungsstufen** herzlich ein mitzumachen! Falls du dich mit dem Projekt vertaut machen willst, versuche ein [good first issue](https://github.com/starship/starship/labels/🌱%20good%20first%20issue).
Wenn du eine andere Sprache flüssig sprichts, würden wir uns sehr freuen wenn du helfen würdest die Dokumentation in anderen Sprachen auf dem aktuellsten Stand zu halten. Hier kannst du bei der Übersetzung helfen [Starship Crowdin](https://translate.starship.rs/).
Falls du an Starship mitwirken willst, wirf bitte einen Blick auf den [Leitfaden zum Mitwirken](https://github.com/starship/starship/blob/master/CONTRIBUTING.md). Schau auch gerne auf unserem [Discord-Server](https://discord.gg/8Jzqu3T) vorbei. 👋
### Mitwirkenden
Das Projekt existiert dank aller der, die Mitwirken. [[Mitmachen](https://github.com/starship/starship/blob/master/CONTRIBUTING.md)].
Support this project with your organization. Your logo will show up here with a link to your website. [[Mitmachen](https://opencollective.com/starship/contribute)]
Bitte schaue dir diese früheren Projekte an, die dazu beigetragen haben, Starship zu kreieren. 🙏
- **[denysdovhan/spaceship-prompt](https://github.com/denysdovhan/spaceship-prompt)** - Ein ZSH-Prompt für Astronauten.
- **[denysdovhan/robbyrussell-node](https://github.com/denysdovhan/robbyrussell-node)** - Ein Shell-übergreifendes und in JavaScript geschriebenes robbyrussell-Theme.
- **[reujab/silver](https://github.com/reujab/silver)** - Shell-übergreifendes, anpassbares und Powerline-ähnliches Prompt mit Symbolen.
Um starship zu installieren, musst du zwei Dinge tun:
1. Get the **starship** binary onto your computer
1. Tell your shell to use the starship binary as its prompt by modifying its init scripts
For most users, the instructions on [the main page](/guide/#🚀-installation) will work great. However, for some more specialized platforms, different instructions are needed.
There are so many platforms out there that they didn't fit into the main README.md file, so here are some installation instructions for other platforms from the community. Is yours not here? Please do add it here if you figure it out!
## [Chocolatey](https://chocolatey.org)
### Voraussetzungen
Head over to the [Chocolatey installation page](https://chocolatey.org/install) and follow the instructions to install Chocolatey.
Starship v0.45.0 is a release containing breaking changes, in preparation for the big v1.0.0. We have made some major changes around how configuration is done on the prompt, to allow for a greater degree of customization.
This guide is intended to walk you through the breaking changes.
## `prompt_order` has been replaced by a root-level `format`
Previously to v0.45.0, `prompt_order` would accept an array of module names in the order which they should be rendered by Starship.
Starship v0.45.0 instead accepts a `format` value, allowing for customization of the prompt outside of the modules themselves.
**Example pre-v0.45.0 configuration**
```toml
prompt_order = [
"username",
"hostname",
"directory",
"git_branch",
"git_commit",
"git_state",
"git_status",
"cmd_duration",
"custom",
"line_break",
"jobs",
"battery",
"time",
"character",
]
```
**Example v0.45.0 configuration**
```toml
format = """\
$username\
$hostname\
$directory\
$git_branch\
$git_commit\
$git_state\
$git_status\
$cmd_duration\
$custom\
$line_break\
$jobs\
$battery\
$time\
$character\
"""
```
## Module `prefix` and `suffix` have been replaced by `format`
Previously to v0.45.0, some modules would accept `prefix` and/or `suffix` in order to stylize the way that modules are rendered.
Starship v0.45.0 instead accepts a `format` value, allowing for further customization of how modules are rendered. Instead of defining a prefix and suffix for the context-based variables, the variables can now be substituted from within a format string, which represents the module's output.
**Example pre-v0.45.0 configuration**
```toml
[cmd_duration]
prefix = "took "
```
**Example v0.45.0 configuration**
```toml
[cmd_duration]
# $duration – The command duration (e.g. "15s")
# $style – The default style of the module (e.g. "bold yellow")
format = "took [$duration]($style) "
```
### Affected Modules
#### Zeichen
| Removed Property | Replacement |
| ----------------------- | ---------------- |
| `symbol` | `success_symbol` |
| `use_symbol_for_status` | `error_symbol` |
| `style_success` | `success_symbol` |
| `style_failure` | `error_symbol` |
**Changes to the Default Configuration**
```diff
[character]
-- symbol = "❯"
-- error_symbol = "✖"
-- use_symbol_for_status = true
-- vicmd_symbol = "❮"
++ success_symbol = "[❯](bold green)"
++ error_symbol = "[❯](bold red)"
++ vicmd_symbol = "[❮](bold green)"
```
Previously, the `use_symbol_for_status` property was used to configure the prompt to show the `error_symbol` when the last command resulted in a non-zero status code.
With the release of v0.45.0, we now always use `error_symbol` after non-zero status codes, unifying `use_symbol_for_status` and `error_symbol` properties.
To configure the prompt to use the older `use_symbol_for_status = true` configuration, add the following to your config file:
```toml
[character]
error_symbol = "[✖](bold red)"
```
*Note:* The `character` element automatically adds a space after, so unlike the other `format` strings, we specifically do not add one in the above examples.
#### Befehlsdauer
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
**Changes to the Default Configuration**
```diff
[cmd_duration]
-- prefix = "took "
++ format = "took [$duration]($style) "
```
#### Verzeichnis
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
**Changes to the Default Configuration**
```diff
[directory]
-- prefix = "in "
++ format = "[$path]($style)[$read_only]($read_only_style) "
```
#### Umgebungsvariablen
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
| `suffix` | `format` |
**Changes to the Default Configuration**
```diff
[env_var]
-- prefix = ""
-- suffix = ""
++ format = "with [$env_value]($style) "
```
#### Git Commit
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
| `suffix` | `format` |
**Changes to the Default Configuration**
```diff
[git_commit]
-- prefix = "("
-- suffix = ")"
++ format = '[\($hash\)]($style) '
```
#### Git-Status
| Removed Property | Replacement |
| ----------------- | ----------- |
| `prefix` | `format` |
| `suffix` | `format` |
| `show_sync_count` | `format` |
**Changes to the Default Configuration**
```diff
[git_status]
-- prefix = "["
-- suffix = "]"
-- show_sync_count = false
++ format = '([\[$all_status$ahead_behind\]]($style) )'
```
Previously, the `show_sync_count` property was used to configure the prompt to show the number of commits the branch was ahead or behind the remote branch.
With the release of v0.45.0, this has been replaced with three separate properties, `ahead`, `behind`, and `diverged`.
To configure the prompt to use the older `show_sync_count = true` configuration, set the following to your config file:
Here is a collection of community-submitted configuration presets for Starship. If you have a preset to share, please [submit a PR](https://github.com/starship/starship/edit/master/docs/presets/README.md) updating this file! 😊
## Nerd Font Symbols
This preset doesn't change anything except for the symbols used for each module. If emojis aren't your thing, this might catch your eye!
### Voraussetzungen
- A [Nerd Font](https://www.nerdfonts.com/) installed and enabled in your terminal (the example uses Fira Code Nerd Font)
description: '¡Starship es el prompt minimalista, ultrarápido e infinitamente personalizable para cualquier intérprete de comandos! Muestra la información que necesitas, a la par que es elegante y minimalista. Instalación rápida disponible para Bash, Fish, ZSH, Ion y PowerShell.'
1. Añade el guión de inicio al archivo de configuración de tu intérprete de comandos:
#### Bash
Añade el siguiente código al final de `~/.bashrc`:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
Añade el siguiente código al final de `~/.config/fish/config.fish`:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
Añade el siguiente código al final de `~/.zshrc`:
```sh
# ~/.zshrc
eval "$(starship init zsh)"
```
#### Powershell
Añade lo siguiente al final de `Microsoft.PowerShell_profile.ps1`. Puedes comprobar la ubicación de este archivo consultando la variable `$PROFILE` en PowerShell. Normalmente la ruta es `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` o `~/.config/powershell/Microsoft.PowerShell_profile.ps1` en -Nix.
```sh
Invoke-Expression (&starship init powershell)
```
#### Ion
Añade el siguiente código al final de `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
::: advertencia Solo se admite Elvish v0.15 o superior. :::
Añade el siguiente código al final de `~/.elvish/rc.elv`:
```sh
# ~/.elvish/rc.elv
eval (starship init elvish)
```
#### Tcsh
Añade el siguiente código al final de `~/.tcshrc`:
Mientras que Starship es un prompt versátil, a veces necesitas más que editar `starhip.toml` para que haga ciertas cosas. Esta página detalla algunas de las técnicas de configuración más avanzadas en Starship.
::: aviso
Las configuraciones de esta sección están sujetos a cambios en futuras versiones de Starship.
:::
## Comandos pre-prompt y pre-ejecucución personalizados en Bash
Bash no posee un framework oficial de preexec/precmd como la mayoría de los demás intérpretes de comandos. Debido a esto, es difícil proporcionar "hooks" totalmente personalizables en `Bash`. Sin embargo, Starship te da la posibilidad de insertar de forma limitada tus propias funciones en el proceso de renderizado del prompt:
- Para ejecutar una función personalizada previa al renderizado del prompt, define una nueva función y asigna su nombre a `starship_precmd_user_func`. Por ejemplo, para renderizar un cohete antes del prompt, se puede realizar así:
```bash
function blastoff(){
echo "🚀"
}
starship_precmd_user_func="blastoff"
```
- Para ejecutar una función personalizada antes de que un comando sea ejecutado, es posible usar el [mecanismo trap `DEBUG`](https://jichu4n.com/posts/debug-trap-and-prompt_command-in-bash/). No obstante, ¡**debes** atrapar la señal DEBUG *antes* de inicializar Starship! Starship puede preservar el valor de la trampa DEBUG, pero si la trampa es reemplazada después de que Starship inicie, alguna funcionalidad fallará.
```bash
function blastoff(){
echo "🚀"
}
trap blastoff DEBUG # Trampa DEBUG *antes* de la ejecución de Starship
eval $(starship init bash)
```
## Cambiar el Título de la Ventana
Algunos intérpretes de comandos van a cambiar automáticamente el título de la ventana por ti (p. ej., para mostrar tu directorio actual). Fish incluso lo hace por defecto. Starship no hace esto, pero es bastante sencillo añadir esta funcionalidad a `Bash` o `zsh`.
Primero, define una función para el cambio de título de la ventana (idéntico en Bash y zsh):
```bash
function set_win_title(){
echo -ne "\033]0; TU_TÍTULO_DE_VENTANA_AQUÍ \007"
}
```
Puedes usar variables para personalizar este título (`$USER`, `$HOSTNAME` y `$PWD` son opciones populares).
En `Bash`, establece que esta función sea la función precmd de Starship:
```bash
starship_precmd_user_func="set_win_title"
```
En `zsh`, añade esto al array `precmd_functions`:
```bash
precmd_functions+=(set_win_title)
```
Si te gusta el resultado, añade estas líneas a tu archivo de configuración del intérprete de comandos (`~/.bashrc` o `~/.zsrhc`) para hacerlo permanente.
Por ejemplo, si quieres mostrar tu directorio actual en el título de la pestaña de la terminal, añade el siguiente fragmento a tu `~/.bashrc` o `~/.zshrc`:
```bash
function set_win_title(){
echo -ne "\033]0; $(basename $PWD) \007"
}
starship_precmd_user_func="set_win_title"
```
## Cadenas de Estilo
Las cadenas de estilo son una lista de palabras, separadas por espacios en blanco. Las palabras no son sensibles a mayúsculas (es decir, `bold` y `BoLd` se consideran la misma cadena). Cada palabra puede ser una de las siguientes:
- `bold`
- `underline`
- `dimmed`
- `bg:<color>`
- `fg:<color>`
- `<color>`
- `none`
donde `<color>` es un especificador de color (discutido a continuación). `fg:<color>` y `<color>` hacen actualmente lo mismo, aunque esto puede cambiar en el futuro. El orden de las palabras en la cadena no importa.
El token `none` anula todos los demás tokens en una cadena si no es parte de un especificador `bg:`, de modo que por ejemplo `fg:red none fg:blue` creará una cadena sin ningún estilo. `bg:none` establece el fondo al color por defecto, así que `fg:red bg:none` es equivalente a `red` o `fg:red` y `bg:green fg:red bg:none` también es equivalente a `fg:red` o `red`. Puede convertirse en un error usar `none` junto con otros tokens en el futuro.
Un especificador de color puede ser uno de los siguientes:
- Uno de los colores estándar del terminal: `black`, `red`, `green`, `blue`, `yellow`, `purple`, `cyan`, `white`. Opcionalmente puedes agregar el prefijo `bright-` para obtener la versión brillante (por ejemplo, `bright-white`).
- Un `#` seguido de un número hexadecimal de seis dígitos. Esto especifica un [código hexadecimal de color RGB](https://www.w3schools.com/colors/colors_hexadecimal.asp).
- Un número entre 0-255. Esto especifica un [Código de color ANSI de 8-bits](https://i.stack.imgur.com/KTSQa.png).
Si se especifican varios colores para el primer plano/fondo, el último en la cadena tendrá prioridad.
- **Intérprete de comandos**: [Fish Shell](https://fishshell.com/)
- **Configuración**: [archivos de configuración de matchai](https://github.com/matchai/dotfiles/blob/b6c6a701d0af8d145a8370288c00bb9f0648b5c2/.config/fish/config.fish)
- **Prompt**: [Starship](https://starship.rs/)
## ¿Cómo obtengo el autocompletado del comando como se muestra en el GIF?
El soporte de terminación, o autocompletado, es proporcionado por tu intérprete de comandos de elección. En el caso de la demo, la demo se realizó con [Fish Shell](https://fishshell.com/), que proporciona el completado por defecto. Si usas Z Shell (zsh), te sugerimos echar un vistazo a [zsh-autosuggeries,](https://github.com/zsh-users/zsh-autosuggestions).
## ¿`prompt_order` y `<module>.disabled` hacen lo mismo?
Sí, se pueden usar ambos para desactivar los módulos en el prompt. Si todo lo que planeas es desactivar módulos, `<module>.disabled` es el método preferido por las siguientes razones:
- Deshabilitar módulos es más explícito que omitirlos del nivel superior `format`
- Los nuevos módulos se añadirán al prompt en cuanto Starship se actualice
## La documentación dice que Starship es "cross-shell". ¿Por qué no es compatible mi intérprete de comandos preferido?
Por la forma en que Starship está construído, debería ser posible añadir soporte para prácticamente cualquier intérprete de comandos. El binario de Starship es sin estado y agnóstico, por lo que mientras que tu intérprete de comandos se pueda ampliar y soporte la personalización del prompt, puedes utilizar Starship.
Aquí tienes un pequeño ejemplo haciendo que Starship funcione con bash:
```sh
# Obtener el código de estado del último comando ejecutado
STATUS=$?
# Calcula el número de tareas ejecutándose.
NUM_JOBS=$(jobs -p | wc -l)
# Establece el prompt a la salida de `starship prompt`
The [Bash implementation](https://github.com/starship/starship/blob/master/src/init/starship.bash) built into Starship is slightly more complex to allow for advanced features like the [Command Duration module](https://starship.rs/config/#command-duration) and to ensure that Starship is compatible with pre-installed Bash configurations.
Para obtener una lista de todos los parámetros aceptados por `el prompt de Starship`, usa el siguiente comando:
```sh
starship prompt --help
```
El símbolo de sistema usará tanto contexto como le proveas, pero no hay parámetros "obligatorios".
## ¿Cómo lanzo Starship en distribuciones Linux con versiones antiguas de glibc?
Si obtienes un error como "_version 'GLIBC_2.18' not found (required by starship)_" al usar el binario precompilado (por ejemplo, en CentOS 6 o 7), puedes usar el binario compilado con `musl` en vez de `glibc`:
## Veo símbolos que no entiendo ni espero, ¿qué significan?
Si ves símbolos que no reconoces, puedes usar `starship explain` para explicar los módulos que se muestran actualmente.
## ¿Por qué no veo un símbolo de glifo en mi prompt?
La causa más común de esto es la mala configuración del sistema. Algunas distribuciones de Linux en particular no vienen con soporte de fuentes listos para usarse. Tienes que garantizar que:
- Tu configuración regional está establecida con un valor UTF-8, como `de_DE.UTF-8` o `ja_JP.UTF-8`. Si `LC_ALL` no es un valor UTF-8, [necesitarás cambiarlo](https://www.tecmint.com/set-system-locales-in-linux/).
- Tienes una fuente emoji instalada. La mayoría de los sistemas vienen con una fuente emoji por defecto, pero algunos (notablemente Arch Linux) no. Generalmente puedes instalar uno a través del gestor de paquetes del sistema --[noto emoji](https://www.google.com/get/noto/help/emoji/) es una elección popular.
- Estás usando un [Nerd Font](https://www.nerdfonts.com/).
Para probar tu sistema, ejecua los siguientes comandos en un terminal:
```sh
echo -e "\xf0\x9f\x90\x8d"
echo -e "\xee\x82\xa0"
```
La primera línea debe producir un [emoji snake](https://emojipedia.org/snake/), mientras que la segunda debe producir un [símbolo de rama de Powerline(e0a0)](https://github.com/ryanoasis/powerline-extra-symbols#glyphs).
Si cualquiera de los dos símbolos no se puede mostrar correctamente, su sistema todavía está mal configurado. Desafortunadamente, obtener la configuración correcta de las fuentes es a veces difícil. Los usuarios en el Discord pueden ayudar. Si ambos símbolos se muestran correctamente, pero todavía no los ves en Starship, [¡envía un informe de error!](https://github.com/starship/starship/issues/new/choose)
## ¿Cómo puedo desinstalar Starship?
Starship es tan fácil de desinstalar como de instalar en primer lugar.
1. Elimina cualquier línea de tu configuración de intérprete de comandos (por ejemplo, `~/.bashrc`) usada para inicializar Starship.
1. Elimina el binario de Starship.
Si Starship fue instalado usando un gestor de paquetes, por favor refiérete a sus documentos para instrucciones de desinstalación.
Si Starship fue instalado usando el script `curl | bash`, el siguiente comando eliminará el binario:
**¡El prompt minimalista, ultrarápido e infinitamente personalizable para cualquier intérprete de comandos!**
- **Rápido:** es rápido –_realmente_ rápido! 🚀
- **Personalizable:** configura cada parte de tu prompt.
- **Universal:** funciona en cualquier intérprete de comandos, en cualquier sistema operativo.
- **Inteligente:** muestra información relevante de un vistazo.
- **Repleto de funciones**: con soporte para tus herramientas favoritas.
- **Fácil:** rápido de instalar – empieza a usarlo en minutos.
<p align="center">
<a href="https://starship.rs/config/"><strong>Explora la documentación de Starship ▶</strong></a>
</p>
<a name="🚀-installation"></a>
## 🚀 Instalación
### Prerequisitos
- Una [Nerd Font](https://www.nerdfonts.com/) instalada y habilitada en tu terminal (por ejemplo, prueba [Fira Code Nerd Font](https://www.nerdfonts.com/font-downloads)).
### Comenzar
**Nota**: debido a la proliferación de diferentes plataformas, solo un subconjunto de plataformas soportadas se muestra a continuación. ¿No puedes ver el tuyo? Echa un vistazo a las [instrucciones adicionales de la plataforma](https://starship.rs/installing/).
1. Instala el binario de **Starship**:
#### Instalar la última versión
##### Desde un binario preconstruido, con el intérprete de comandos:
```sh
curl -fsSL https://starship.rs/install.sh | bash
```
#### Instalar con un gestor de paquetes
##### Ejemplo: [Homebrew](https://brew.sh/):
```sh
brew install starship
```
##### Con [Scoop](https://scoop.sh):
```powershell
scoop install starship
```
2. Añade el guión de inicio al archivo de configuración de tu intérprete de comandos:
#### Bash
Añade el siguiente código al final de `~/.bashrc`:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
Añade el siguiente código al final de `~/.config/fish/config.fish`:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
Añade el siguiente código al final de `~/.zshrc`:
```sh
# ~/.zshrc
eval "$(starship init zsh)"
```
#### PowerShell
Añade lo siguiente al final de `Microsoft.PowerShell_profile.ps1`. Puedes comprobar la ubicación de este archivo consultando la variable `$PROFILE` en PowerShell. Normalmente la ruta es `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` o `~/.config/powershell/Microsoft.PowerShell_profile.ps1` en -Nix.
```powershell
Invoke-Expression (&starship init powershell)
```
#### Ion
Añade el siguiente código al final de `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
**Advertencia** Sólo se admite Elvish v0.15 o superior. Añade el siguiente código al final de `~/.elvish/rc.elv`:
```sh
# ~/.elvish/rc.elv
eval (starship init elvish)
```
#### Tcsh
Añade el siguiente código al final de `~/.tcshrc`:
```sh
# ~/.tcshrc
eval `starship init tcsh`
```
## 🤝 Colaborando
¡Siempre estamos buscando colaboradores de **todos los niveles y habilidades**! Si estas buscando una manera fácil de ayudar este proyecto, puedes intentar resolver un problema con la etiqueta "[good first issue](https://github.com/starship/starship/labels/🌱%20good%20first%20issue)".
Si hablas con fluidez en un idioma que no sea inglés, agradecemos mucho cualquier ayuda para mantener nuestros documentos traducidos y actualizados en otros idiomas. Si quieres ayudar, puedes contribuir con las traducciones en el [Crowdin de Starship](https://translate.starship.rs/).
Si quieres ayudar a colaborar a Starship, por favor mira nuestra [Guía de Colaboradores](https://github.com/starship/starship/blob/master/CONTRIBUTING.md). Además, siéntete libre de entrar en nuestro [servidor de Discord](https://discord.gg/8Jzqu3T) y di "¡Hola!". 👋
### Desarrolladores
Este proyecto existe gracias a todas las personas que han ayudado. [[Contribuir](https://github.com/starship/starship/blob/master/CONTRIBUTING.md)].
Apoya este proyecto con tu organización. Su logo se mostrará aquí con un enlace a su sitio web. [[Contribuir](https://opencollective.com/starship/contribute)]
Por favor, revisa estos trabajos previos que ayudaron a inspirar la creación de starship. 🙏
- **[denysdovhan/spaceship-prompt](https://github.com/denysdovhan/spaceship-prompt)** - Un prompt ZSH para astronautas.
- **[denysdovhan/robbyrussell-node](https://github.com/denysdovhan/robbyrussell-node)** - robbyrussel, tema multi-intérprete de comandos escrito en JavaScript.
- **[reujab/silver](https://github.com/reujab/silver)** - Un prompt multi-intérprete de comandos personalizable, basada en Powerline con iconos.
<p align="center">
<br>
<img width="100" src="https://raw.githubusercontent.com/starship/starship/master/media/icon.png" alt="Icono de cohete de Starship">
Para instalar Starship, necesitas hacer dos cosas:
1. Consigue el binario de **Starship** en tu ordenador
1. Decirle a tu intérprete de comandos que use el binario de Starship como su prompt modificando sus guiones de inicio
Para la mayoría de los usuarios, las instrucciones en [la página principal](/guide/#🚀-installation) funcionarán genial. Sin embargo, para algunas plataformas más especializadas, se necesitan diferentes instrucciones.
Hay tantas plataformas ahí fuera que no cabían en el README.md principal, así que aquí están algunas instrucciones de instalación para otras plataformas de la comunidad. ¿No está usted aquí? ¡Por favor, añádelo aquí si lo encuentras!
## [Chocolatey](https://chocolatey.org)
### Prerequisitos
Dirígete a la página de instalación de [Chocolatey](https://chocolatey.org/install) y sigue las instrucciones para instalar Chocolatey.
Starship v0.45.0 es un lanzamiento que contiene cambios de ruptura, en preparación para la gran v1.0.0. Hemos hecho algunos cambios importantes en la forma en que se realiza la configuración en el prompt, para permitir un mayor grado de personalización.
Esta guía pretende guiarle a través de los cambios de ruptura.
## `prompt_order` ha sido reemplazado por un "nivel raíz" `format`
Anterioramente a v0.45.0, `prompt_order` aceptaría un arreglo de nombres de módulos en el orden que deberían ser renderizados por Starship.
En su lugar, Starship v0.45.0 acepta un valor de `format`, permitiendo la personalización del indicador fuera de los propios módulos.
**Configuración de ejemplo pre-v0.45.0**
```toml
prompt_order = [
"username",
"hostname",
"directory",
"git_branch",
"git_commit",
"git_state",
"git_status",
"cmd_duration",
"custom",
"line_break",
"jobs",
"battery",
"time",
"character",
]
```
**Configuración de ejemplo v0.45.0**
```toml
format = """\
$username\
$hostname\
$directory\
$git_branch\
$git_commit\
$git_state\
$git_status\
$cmd_duration\
$custom\
$line_break\
$jobs\
$battery\
$time\
$character\
"""
```
## El módulo `prefix` y `suffix` han sido reemplazados por `format`
Anteriormente a v0.45.0, algunos módulos aceptarían `prefix` y/o `suffix` para estilizar la forma en que se renderizan los módulos.
En su lugar, Starship v0.45.0 acepta un valor `format`, lo que permite una mayor personalización de cómo se renderizan los módulos. En lugar de definir un prefijo y un sufijo para las variables basadas en contextos, las variables ahora pueden ser sustituidas dentro de una cadena de formato, que representa la salida del módulo.
**Configuración de ejemplo pre-v0.45.0**
```toml
[cmd_duration]
prefix = "tomó "
```
**Configuración de ejemplo v0.45.0**
```toml
[cmd_duration]
# $duration – La duración del comando (p. ej. "15s")
# $style – El estilo por defecto del módulo (p. ej. "bold yellow")
format = "tomó [$duration]($style) "
```
### Módulos afectados
#### Character
| Propiedad eliminada | Reemplazo |
| ----------------------- | ---------------- |
| `symbol` | `success_symbol` |
| `use_symbol_for_status` | `error_symbol` |
| `style_success` | `success_symbol` |
| `style_failure` | `error_symbol` |
**Cambios a la configuración por defecto**
```diff
[character]
-- symbol = "❯"
-- error_symbol = "✖"
-- use_symbol_for_status = true
-- vicmd_symbol = "❮"
++ success_symbol = "[❯](bold green)"
++ error_symbol = "[❯](bold red)"
++ vicmd_symbol = "[❮](bold green)"
```
Anteriormente, la propiedad `use_symbol_for_status` fue usada para configurar el prompt para mostrar el `error_symbol` cuando el último comando resultó en un código de estado distinto de cero.
Con la liberación de v0.45.0, ahora siempre usamos las propiedades `error_symbol` después de códigos de estado diferentes de cero, unificando `use_symbol_for_status` y `error_symbol`.
Para configurar el prompt para usar la configuración anterior `use_symbol_for_status = true`, agrega lo siguiente a tu archivo de configuración:
```toml
[character]
error_symbol = "[✖](bold red)"
```
*Nota:* El elemento `character` añade automáticamente un espacio, así que a diferencia del otras cadenas `format`, no añadimos uno en los ejemplos anteriores.
#### Tiempo de Ejecución
| Propiedad eliminada | Reemplazo |
| ------------------- | --------- |
| `prefix` | `format` |
**Cambios a la configuración por defecto**
```diff
[cmd_duration]
-- prefix = "took "
++ format = "took [$duration]($style) "
```
#### Directory
| Propiedad eliminada | Reemplazo |
| ------------------- | --------- |
| `prefix` | `format` |
**Cambios a la configuración por defecto**
```diff
[directory]
-- prefix = "in "
++ format = "[$path]($style)[$read_only]($read_only_style) "
```
#### Variable de entorno
| Propiedad eliminada | Reemplazo |
| ------------------- | --------- |
| `prefix` | `format` |
| `suffix` | `format` |
**Cambios a la configuración por defecto**
```diff
[env_var]
-- prefix = ""
-- suffix = ""
++ format = "with [$env_value]($style) "
```
#### Git commit
| Propiedad eliminada | Reemplazo |
| ------------------- | --------- |
| `prefix` | `format` |
| `suffix` | `format` |
**Cambios a la configuración por defecto**
```diff
[git_commit]
-- prefix = "("
-- suffix = ")"
++ format = '[\($hash\)]($style) '
```
#### Git status
| Propiedad eliminada | Reemplazo |
| ------------------- | --------- |
| `prefix` | `format` |
| `suffix` | `format` |
| `show_sync_count` | `format` |
**Cambios a la configuración por defecto**
```diff
[git_status]
-- prefix = "["
-- suffix = "]"
-- show_sync_count = false
++ format = '([\[$all_status$ahead_behind\]]($style) )'
```
Anteriormente, la propiedad `show_sync_count` fue usada para configurar el prompt para mostrar el número de confirmaciones que la rama estaba por delante o detrás de la rama remota.
Con el lanzamiento de v0.45.0, esto ha sido reemplazado por tres propiedades separadas, `ahead`, `behind`, y `diverged`.
Para configurar el prompt para usar la configuración anterior `show_sync_count = true`, establece lo siguiente en tu archivo de configuración:
Aquí hay una colección de ajustes por defecto creados por la comunidad de Starship. ¡Si quieres compartir un ajuste por defecto, por favor, [envía un PR](https://github.com/starship/starship/edit/master/docs/presets/README.md) actualizando este archivo! 😊
## Símbolos de Nerd Font
Este ajuste por defecto no modifica nada excepto los símbolos usados para cada módulo. Si los emojis no son lo tuyo, ¡esto podría llamar tu atención!
### Prerequisitos
- Una [Nerd Font](https://www.nerdfonts.com/) instalada y habilitada en tu terminal (el ejemplo usa Fira Code Nerd Font)
## How do I get command completion as shown in the demo GIF?
Completion support, or autocomplete, is provided by your shell of choice. In the case of the demo, the demo was done with [Fish Shell](https://fishshell.com/), which provides completions by default. If you use Z Shell (zsh), I'd suggest taking a look at [zsh-autosuggestions](https://github.com/zsh-users/zsh-autosuggestions).
## Do top level `format` and `<module>.disabled` do the same thing?
Yes, they can both be used to disable modules in the prompt. If all you plan to do is disable modules, `<module>.disabled` is the preferred way to do so for these reasons:
- Disabling modules is more explicit than omitting them from the top level `format`
- Newly created modules will be added to the prompt as Starship is updated
## The docs say Starship is cross-shell. Why isn't my preferred shell supported?
The way Starship is built, it should be possible to add support for virtually any shell. The starship binary is stateless and shell agnostic, so as long as your shell supports prompt customization and shell expansion, Starship can be used.
Here's a small example getting Starship working with bash:
```sh
# Get the status code from the last command executed
STATUS=$?
# Get the number of jobs running.
NUM_JOBS=$(jobs -p | wc -l)
# Set the prompt to the output of `starship prompt`
The [Bash implementation](https://github.com/starship/starship/blob/master/src/init/starship.bash) built into Starship is slightly more complex to allow for advanced features like the [Command Duration module](https://starship.rs/config/#command-duration) and to ensure that Starship is compatible with pre-installed Bash configurations.
For a list of all flags accepted by `starship prompt`, use the following command:
```sh
starship prompt --help
```
The prompt will use as much context as is provided, but no flags are "required".
## How do I run Starship on Linux distributions with older versions of glibc?
If you get an error like "_version 'GLIBC_2.18' not found (required by starship)_" when using the prebuilt binary (for example, on CentOS 6 or 7), you can use a binary compiled with `musl` instead of `glibc`:
tagline: L'invite minimaliste, ultra-rapide et personnalisable à l'infini pour n'importe quel shell !
actionText: Commencez →
actionLink: ./guide/
features:
-
title: Compatibilité avant tout
details: Fonctionne sur tous les principaux shells et système d'exploitation. Utilisez-le partout !
-
title: Propulsé par Rust
details: Profiter de toute la rapidité et la sécurité de Rust pour rendre votre invite de commandes le plus rapide et fiable possible.
-
title: Personnalisable
details: Tous les petits détails sont personnalisable à votre goût, pour rendre votre invite de commandes aussi léger ou complet que le vous souhaitez.
description: Starship est un invite minimaliste, ultra-rapide et hautement personnalisable pour n'importe quel shell ! Montre les informations dont vous avez besoin tout en restant élégant et minimaliste. Installation rapide disponible pour Bash, Fish, ZSH, Ion et PowerShell.
1. Ajouter le script d’initialisation au fichier configuration de votre shell:
#### Bash
Ajouter ce qui suit à la fin de `~/.bashrc`:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
Ajoute ce qui suit à la fin de `~/.config/fish/config.fish`:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
Ajouter ce qui suit à la fin de `~/.zshrc`:
```sh
# ~/.zshrc
eval "$(starship init zsh)"
```
#### Powershell
Ajoutez ce qui suit à la fin de `Microsoft.PowerShell_profile.ps1`. Vous pouvez vérifier l'emplacement de ce fichier en regardant la variable `$PROFILE` dans PowerShell. Typically the path is `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` or `~/.config/powershell/Microsoft.PowerShell_profile.ps1` on -Nix.
```sh
Invoke-Expression (&starship init powershell)
```
#### Ion
Ajouter ce qui suit à la fin de `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
::: warning Only elvish v0.15 or higher is supported. :::
Add the following to the end of `~/.elvish/rc.elv`:
Même si Starship est un shell polyvalent, éditer `starship.toml` ne suffit parfois pas pour faire certaines choses. Cette page détaille quelques techniques de configuration avancées utilisées dans starship.
::: warning
Les configurations dans cette section sont sujettes à modification dans les futures versions de Starship.
:::
## Personnalisation des commandes pré-commande et pré-exécution en Bash
Bash n'a pas de structure officielle préexec/précmd comme la plupart des autres shells. C'est pourquoi il est difficile de fournir des hooks entièrement personnalisables dans `bash`. Cependant, Starship vous donne une capacité limitée à insérer vos propres fonctions dans la procédure de rendu commande :
- Pour exécuter une fonction personnalisée juste avant que commande soit dessinée, définissez une nouvelle fonction et assignez son nom à `starship_precmd_user_func`. Par exemple, pour dessiner une fusée avant la commande, vous feriez
```bash
function blastoff(){
echo "🚀"
}
starship_precmd_user_func="blastoff"
```
- Pour exécuter une fonction personnalisée juste avant l'exécution d'une commande, vous pouvez utiliser le [` DEBUG` mécanisme d'interruption ](https://jichu4n.com/posts/debug-trap-and-prompt_command-in-bash/). Cependant, vous **devez** piéger le signal DEBUG *avant* initialisation du Starship ! Starship peut préserver la valeur du piège DEBUG, mais si le piège est écrasé après le démarrage de Starship, certaines fonctionnalités vont casser.
```bash
function blastoff(){
echo "🚀"
}
trap blastoff DEBUG # Pièger DEBUG *avant* l'initiation de starship
eval $(starship init bash)
```
## Modifier le style des fenêtres commande
Certaines commandes du shell changeront automatiquement le titre de la fenêtre (par exemple, refléter votre répertoire de travail). Fish le fait par défaut. Starship ne le fait pas, mais il est assez simple d'ajouter cette fonctionnalité à `bash` ou `zsh`.
Tout d'abord, définir une fonction de changement de titre de fenêtre (identique en bash et zsh) :
```bash
function set_titre_fenetre(){
echo -ne "\033]0; TON_TITRE_FENETRE_ICI \007"
}
```
Vous pouvez utiliser des variables pour personnaliser ce titre (`$USER`, `$HOSTNAME`, et `$PWD` sont des choix populaires).
Dans `bash`, définissez cette fonction comme la fonction precmd Starship :
```bash
starship_precmd_user_func="set_titre_gagnante"
```
Dans `zsh`, ajoutez ceci au tableau `precmd_functions` :
```bash
précmd_functions+=(set_titre_gagnant)
```
Si vous aimez le résultat, ajoutez ces lignes à votre fichier de configuration shell (`~/.bashrc` ou `~/.zshrc`) pour le rendre permanent.
Par exemple, si vous voulez afficher votre répertoire actuel dans votre titre d'onglets de terminal, ajoutez le snippet suivant à votre `~/.bashrc` ou `~/.zshrc`:
```bash
function set_win_title(){
echo -ne "\033]0; $(basename $PWD) \007"
}
starship_precmd_user_func="set_win_title"
```
## Chaînes de style
Les chaînes de style sont une liste de mots, séparés par des espaces. Les mots ne sont pas sensibles à la casse (c'est-à-dire `gras` et `GrAs` sont considérés comme le même mot). Chaque mot peut être l'un des suivants :
- `bold`
- `underline`
- `dimmed`
- `bg:<color>`
- `fg:<color>`
- `<color>`
- `none`
où `<color>` est un spécificateur de couleur (discuté ci-dessous). `fg:<color>` et `<color>` font actuellement la même chose, même si cela peut changer plus tard. L'ordre des mots dans le string n'a pas d'importance.
The `none` token overrides all other tokens in a string if it is not part of a `bg:` specifier, so that e.g. `fg:red none fg:blue` will still create a string with no styling. `bg:none` sets the background to the default color so `fg:red bg:none` is equivalent to `red` or `fg:red` and `bg:green fg:red bg:none` is also equivalent to `fg:red` or `red`. Il peut devenir une erreur d'utiliser `none` en conjonction avec d'autres jetons dans le futur.
Un spécificateur de couleur peut être l'un des éléments suivants :
- Une des couleurs standard du terminal : `black`, `red`, `green`, `blue`, `yellow`, `purple`, `cyan`, `white`. Vous pouvez éventuellement les préfixer avec `bright-` pour obtenir la version lumineuse (par exemple `bright-white`).
- Un `#` suivi d'un nombre hexadécimal de six chiffres. Ceci spécifie un [ Code hexadécimal de couleur RVB ](https://www.w3schools.com/colors/colors_hexadecimal.asp).
- Un nombre entre 0-255. Ceci spécifie un [code de couleur ANSI 8 bits](https://i.stack.imgur.com/KTSQa.png).
Si plusieurs couleurs sont spécifiées pour le premier plan/arrière-plan, la dernière dans le string prendra la priorité.
- **Configuration**: [Dotfiles de matchai](https://github.com/matchai/dotfiles/blob/b6c6a701d0af8d145a8370288c00bb9f0648b5c2/.config/fish/config.fish)
- **Invite de commande**: [Starship](https://starship.rs/)
## Comment puis-je obtenir la complétion de commandes comme montré dans le GIF de démo?
L'aide à la complétion ou autocomplétion est fournie par le shell que vous avez choisi. Dans le cas de la démo, elle a été faite avec [Fish Shell](https://fishshell.com/), qui fournit des complétions par défaut. Si vous utilisez le Shell Z (zsh), vous pouvez jeter un œil à [zsh-autosuggestions](https://github.com/zsh-users/zsh-autosuggestions).
## Est-ce que l'option globale `format` et `<module>.disabled` font la même chose ?
Oui, ils peuvent tous deux être utilisés pour désactiver les modules dans l'invite de commande. Si tout ce que vous prévoyez de faire est de désactiver les modules, `<module>.disabled` est le meilleur moyen de le faire pour ces raisons :
- Désactiver les modules est plus explicite que de les omettre du `format global`
- Les modules nouvellement créés seront ajoutés à l'invite de commande au fur et à mesure que Starship sera mis à jour
## The docs say Starship is cross-shell. Why isn't my preferred shell supported?
Étant donné la façon dont Starship est construit, il devrait être possible d'ajouter le support pour pratiquement n'importe quel shell. Starship est sans état et agnostique, donc tant que votre shell supporte la personnalisation rapide et l'expansion, Starship peut être utilisé.
Voici un petit exemple pour que Starship fonctionne avec bash :
```sh
# Récupère le code d'état de la dernière commande exécutée
STATUS=$?
# Récupère le nombre de tâches en cours d'exécution.
NUM_JOBS=$(jobs -p | wc -l)
# Définit l'invite de commande a `starship prompt`
The [Bash implementation](https://github.com/starship/starship/blob/master/src/init/starship.bash) built into Starship is slightly more complex to allow for advanced features like the [Command Duration module](https://starship.rs/config/#command-duration) and to ensure that Starship is compatible with pre-installed Bash configurations.
Pour une liste de tous les flags acceptés par `starship`, utilisez la commande suivante :
```sh
starship prompt --help
```
L'invite utilisera autant de contexte que possible, mais aucun paramètre n'est "requis".
## Comment utiliser Starship sur des distributions Linux avec des versions de glibc plus ancienne ?
Si vous obtenez une erreur du type "_version 'GLIBC_2.18' not found (required by starship)_" lors de l'utilisation de l'exécutable précompilé (par exemple sur CentOS 6 ou 7), vous pouvez utiliser un exécutable compilé avec `musl` au lieu de `glibc`:
## I see symbols I don't understand or expect, what do they mean?
If you see symbols that you don't recognise you can use `starship explain` to explain the currently showing modules.
## Why don't I see a glyph symbol in my prompt?
The most common cause of this is system misconfiguration. Some Linux distros in particular do not come with font support out-of-the-box. You need to ensure that:
- Votre locale est définie à une valeur UTF-8, comme `de_DE.UTF-8` ou `ja_JP.UTF-8`. Si `LC_ALL` n'est pas une valeur UTF-8, [vous aurez besoin de la modifier](https://www.tecmint.com/set-system-locales-in-linux/).
- Vous avez une police emoji installée. La plupart des systèmes sont fournis avec une police emoji par défaut, mais certains (notamment Arch Linux) ne le font pas. Vous pouvez habituellement en installer un par le biais du gestionnaire de paquets de votre système -[noto emoji](https://www.google.com/get/noto/help/emoji/) est un choix populaire.
- Vous utilisez une police [Nerd Font](https://www.nerdfonts.com/).
To test your system, run the following commands in a terminal:
```sh
echo -e "\xf0\x9f\x90\x8d"
echo -e "\xee\x82\xa0"
```
The first line should produce a [snake emoji](https://emojipedia.org/snake/), while the second should produce a [powerline branch symbol (e0a0)](https://github.com/ryanoasis/powerline-extra-symbols#glyphs).
If either symbol fails to display correctly, your system is still misconfigured. Unfortunately, getting font configuration correct is sometimes difficult. Users on the Discord may be able to help. If both symbols display correctly, but you still don't see them in starship, [file a bug report!](https://github.com/starship/starship/issues/new/choose)
## How do I uninstall Starship?
Starship is just as easy to uninstall as it is to install in the first place.
1. Supprimez les lignes de la configuration de votre shell (par exemple `~/.bashrc`) utilisées pour initialiser Starship.
1. Supprimer l'exécutable de Starship.
If Starship was installed using a package manager, please refer to their docs for uninstallation instructions.
If Starship was installed using the `curl | bash` script, the following command will delete the binary:
**L'invite minimaliste, ultra-rapide et personnalisable à l'infini pour n'importe quel shell !**
- **Rapide** : il est rapide - _vraiment vraiment_ rapide ! 🚀
- **Personnalisable:** configurer chaque élément de votre invite.
- **Universel:** fonctionne avec n'importe quel shell, sur n'importe quel système d'exploitation.
- **Intelligent:** affiche les informations utiles en un coup d'œil.
- **Riche en fonctionnalités:** supporte tous vos outils favoris.
- **Facile:** rapide à installer -commencer à l'utiliser en quelques minutes.
<p align="center">
<a href="https://starship.rs/config/"><strong>Consulter la documentation de Starship ▶</strong></a>
</p>
<a name="🚀-installation"></a>
## 🚀 Installation
### Pré-requis
- Une police [Nerd Font](https://www.nerdfonts.com/) installée et activée dans votre terminal (Par exemple, essayez [Fira Code](https://www.nerdfonts.com/font-downloads)).
### Démarrage rapide
**Note**: due to the proliferation of different platforms, only a subset of supported platforms are shown below. Can't see yours? Have a look at the [extra platform instructions](https://starship.rs/installing/).
1. Installer l'exécutable **starship** :
#### Installer la dernière version
##### Depuis une version pré-compilée, depuis le shell:
```sh
curl -fsSL https://starship.rs/install.sh | bash
```
#### Installer via le gestionnaire de paquets
##### Example: [Homebrew](https://brew.sh/):
```sh
brew install starship
```
##### Avec [Scoop](https://scoop.sh):
```powershell
scoop install starship
```
2. Ajouter le script d’initialisation au fichier de configuration de votre shell:
#### Bash
Ajouter ce qui suit à la fin de `~/.bashrc`:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
Ajoute ce qui suit à la fin de `~/.config/fish/config.fish`:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
Ajouter ce qui suit à la fin de `~/.zshrc`:
```sh
# ~/.zshrc
eval "$(starship init zsh)"
```
#### PowerShell
Ajouter ce qui suit à la fin de `Microsoft.PowerShell_profile.ps1`. Vous pouvez vérifier l'emplacement de ce fichier en regardant la variable `$PROFILE` dans PowerShell. Typically the path is `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` or `~/.config/powershell/Microsoft.PowerShell_profile.ps1` on -Nix.
```powershell
Invoke-Expression (&starship init powershell)
```
#### Ion
Ajouter ce qui suit à la fin de `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
**Warning** Only elvish v0.15 or higher is supported. Add the following to the end of `~/.elvish/rc.elv`:
```sh
# ~/.elvish/rc.elv
eval (starship init elvish)
```
#### Tcsh
Add the following to the end of `~/.tcshrc`:
```sh
# ~/.tcshrc
eval `starship init tcsh`
```
## 🤝Contribution
Nous sommes toujours à la recherche de contributeurs de **tous niveaux de compétence**! Si vous cherchez à faciliter votre entrée dans le projet, essayez un [good first issue](https://github.com/starship/starship/labels/🌱%20good%20first%20issue).
If you are fluent in a non-English language, we greatly appreciate any help keeping our docs translated and up-to-date in other languages. If you would like to help, translations can be contributed on the [Starship Crowdin](https://translate.starship.rs/).
Si vous êtes intéressé pour aider et contribuer à Starship, veuillez jeter un coup d'œil à notre [Guide de contribution](https://github.com/starship/starship/blob/master/CONTRIBUTING.md). Aussi, n'hésitez pas à vous rendre sur notre [serveur Discord](https://discord.gg/8Jzqu3T) pour dire bonjour. 👋
### Contributeurs
Ce projet existe grâce à toutes les personnes qui y contribuent. [[Contribuer](https://github.com/starship/starship/blob/master/CONTRIBUTING.md)].
Soutenez ce projet avec votre organisation. Votre logo apparaîtra ici avec un lien vers votre site Web. [[Contribuer](https://opencollective.com/starship/contribute)]
Pour installer starship, vous devez faire deux choses:
1. Installez le binaire **starship** sur votre ordinateur
1. Dites à votre shell d'utiliser le binaire de starship comme invite en modifiant ses scripts d'initialisation
Pour la plupart des utilisateurs, les instructions sur [la page principale](/guide/#🚀-installation) fonctionneront bien. Cependant, pour certaines plateformes plus spécialisées, des instructions différentes sont nécessaires.
Il y a tellement de plates-formes, qu'il aurait été déraisonnable de les faire apparaître dans le README principal, voici donc quelques instructions d'installation supplémentaires pour celles-ci, écrient par la commaunauté. La vôtre n'est-elle pas là ? S'il vous plaît, ajoutez-la ici pour les suivants !
## [Chocolatey](https://chocolatey.org)
### Pré-requis
Head over to the [Chocolatey installation page](https://chocolatey.org/install) and follow the instructions to install Chocolatey.
Starship v0.45.0 is a release containing breaking changes, in preparation for the big v1.0.0. We have made some major changes around how configuration is done on the prompt, to allow for a greater degree of customization.
This guide is intended to walk you through the breaking changes.
## `prompt_order` has been replaced by a root-level `format`
Previously to v0.45.0, `prompt_order` would accept an array of module names in the order which they should be rendered by Starship.
Starship v0.45.0 instead accepts a `format` value, allowing for customization of the prompt outside of the modules themselves.
**Example pre-v0.45.0 configuration**
```toml
prompt_order = [
"username",
"hostname",
"directory",
"git_branch",
"git_commit",
"git_state",
"git_status",
"cmd_duration",
"custom",
"line_break",
"jobs",
"battery",
"time",
"character",
]
```
**Example v0.45.0 configuration**
```toml
format = """\
$username\
$hostname\
$directory\
$git_branch\
$git_commit\
$git_state\
$git_status\
$cmd_duration\
$custom\
$line_break\
$jobs\
$battery\
$time\
$character\
"""
```
## Module `prefix` and `suffix` have been replaced by `format`
Previously to v0.45.0, some modules would accept `prefix` and/or `suffix` in order to stylize the way that modules are rendered.
Starship v0.45.0 instead accepts a `format` value, allowing for further customization of how modules are rendered. Instead of defining a prefix and suffix for the context-based variables, the variables can now be substituted from within a format string, which represents the module's output.
**Example pre-v0.45.0 configuration**
```toml
[cmd_duration]
prefix = "took "
```
**Example v0.45.0 configuration**
```toml
[cmd_duration]
# $duration – The command duration (e.g. "15s")
# $style – The default style of the module (e.g. "bold yellow")
format = "took [$duration]($style) "
```
### Affected Modules
#### Caractères
| Removed Property | Replacement |
| ----------------------- | ---------------- |
| `symbol` | `success_symbol` |
| `use_symbol_for_status` | `error_symbol` |
| `style_success` | `success_symbol` |
| `style_failure` | `error_symbol` |
**Changes to the Default Configuration**
```diff
[character]
-- symbol = "❯"
-- error_symbol = "✖"
-- use_symbol_for_status = true
-- vicmd_symbol = "❮"
++ success_symbol = "[❯](bold green)"
++ error_symbol = "[❯](bold red)"
++ vicmd_symbol = "[❮](bold green)"
```
Previously, the `use_symbol_for_status` property was used to configure the prompt to show the `error_symbol` when the last command resulted in a non-zero status code.
With the release of v0.45.0, we now always use `error_symbol` after non-zero status codes, unifying `use_symbol_for_status` and `error_symbol` properties.
To configure the prompt to use the older `use_symbol_for_status = true` configuration, add the following to your config file:
```toml
[character]
error_symbol = "[✖](bold red)"
```
*Note:* The `character` element automatically adds a space after, so unlike the other `format` strings, we specifically do not add one in the above examples.
#### Temps d'exécution
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
**Changes to the Default Configuration**
```diff
[cmd_duration]
-- prefix = "took "
++ format = "took [$duration]($style) "
```
#### Dossier
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
**Changes to the Default Configuration**
```diff
[directory]
-- prefix = "in "
++ format = "[$path]($style)[$read_only]($read_only_style) "
```
#### Environment Variable
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
| `suffix` | `format` |
**Changes to the Default Configuration**
```diff
[env_var]
-- prefix = ""
-- suffix = ""
++ format = "with [$env_value]($style) "
```
#### Git Commit
| Removed Property | Replacement |
| ---------------- | ----------- |
| `prefix` | `format` |
| `suffix` | `format` |
**Changes to the Default Configuration**
```diff
[git_commit]
-- prefix = "("
-- suffix = ")"
++ format = '[\($hash\)]($style) '
```
#### Git Status
| Removed Property | Replacement |
| ----------------- | ----------- |
| `prefix` | `format` |
| `suffix` | `format` |
| `show_sync_count` | `format` |
**Changes to the Default Configuration**
```diff
[git_status]
-- prefix = "["
-- suffix = "]"
-- show_sync_count = false
++ format = '([\[$all_status$ahead_behind\]]($style) )'
```
Previously, the `show_sync_count` property was used to configure the prompt to show the number of commits the branch was ahead or behind the remote branch.
With the release of v0.45.0, this has been replaced with three separate properties, `ahead`, `behind`, and `diverged`.
To configure the prompt to use the older `show_sync_count = true` configuration, set the following to your config file:
Voici un ensemble de configuration par défaut soumis par la communauté pour Starship. Si vous avez une configuration à partager, veuillez [proposer une PR](https://github.com/starship/starship/edit/master/docs/presets/README.md) pour mettre à jour ce fichier! 😊
## Nerd Font Symbols
Cette configuration ne modifie rien sauf les symboles utilisés pour chaque module. Si les émoticônes ne sont pas votre tasse de thé, elle pourrait retenir votre attention!
### Pré-requis
- Une [Nerd Font](https://www.nerdfonts.com/) est installée et activée dans votre terminal (l'exemple utilise Fira Code Nerd Font)
tagline: Il prompt minimalista, super veloce e infinitamente personalizzabile per qualsiasi shell!
actionText: Inizia →
actionLink: ./guide/
features:
-
title: Prima la compatibilità
details: Funziona sulle shell e sui sistemi operativi più comuni. Usalo ovunque!
-
title: Generato in Rust
details: Sfrutta la velocità e sicurezza migliori di Rust, per rendere il tuo prompt il più veloce e il più affidabile.
-
title: Personalizzabile
details: Ogni più piccolo dettaglio è personalizzabile a piacere, per rendere questo messaggio prompt minimalista o ricco delle funzionalità che desideri.
description: Starship è il prompt minimalista, super veloce ed estremamente personalizzabile per qualsiasi shell! Mostra le informazioni di cui hai bisogno, rimanendo elegante e minimale. Installazione rapida disponibile per Bash, Fish, ZSH, Ion e PowerShell.
1. Aggiungi lo script di inizializzazione al file di configurazione della shell:
#### Bash
Aggiungi quanto segue alla fine di `~/.bashrc`:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
Aggiungi quanto segue alla fine di `~/.config/fish/config.fish`:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
Aggiungi quanto segue alla fine di `~/.zshrc`:
```sh
# ~/.zshrc
eval "$(starship init zsh)"
```
#### Powershell
Aggiungi quanto segue alla fine di `Microsoft.PowerShell_profile.ps1`. Puoi controllare la posizione di questo file interrogando la variabile `$PROFILE` in PowerShell. In genere il percorso è `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` oppure `~/.config/powershell/Microsoft.PowerShell_profile.ps1` in -Nix.
```sh
Invoke-Expression (&starship init powershell)
```
#### Ion
Aggiungi quanto segue alla fine di `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
::: warning Only elvish v0.15 or higher is supported. :::
Aggiungi quanto segue alla fine di `~/.elvish/rc.elv`:
Nonostante Starship sia una shell versatile, a volte devi fare qualche modifica in più in `starship.toml` per ottenere alcune cose. Questa pagina descrive alcune tecniche di configurazione avanzate utilizzate in Starship.
::: Attenzione
Le configurazioni in questa sezione sono soggette a modifiche nelle future versioni di Starship.
:::
## Comandi personalizzati di pre-prompt e pre-esecuzione per Bash
Bash non ha un framework preexec/precmd formale come la maggior parte delle altre shell. Per questo motivo, è difficile fornire hook completamente personalizzabile in `bash`. Tuttavia, Starship dà la limitata possibilità di inserire le tue funzioni nella procedura prompt-rendering:
- Per eseguire una funzione personalizzata a destra del prompt prima che venga disegnato, definisci una nuova funzione e assegna il suo nome a `starship_precmd_user_func`. Per esempio, per visualizzare l'icona di un razzo prima del prompt, si può usare il codice seguente
```bash
function blastoff(){
echo "🚀"
}
starship_precmd_user_func="blastoff"
```
- Per eseguire una funzione personalizzata prima dell'esecuzione di un comando, è possibile utilizzare il meccanismo trappola [`DEBUG`](https://jichu4n.com/posts/debug-trap-and-prompt_command-in-bash/). Tuttavia, **devi** intrappolare il segnale DEBUG *prima di* inizializzare Starship! Starship può preservare il valore trappola di DEBUG, ma se la trappola viene sovrascritta dopo l'avvio di Starship, alcune funzionalità non funzioneranno.
```bash
function blastoff(){
echo "🚀"
}
trap blastoff DEBUG # Trap DEBUG *prima* di eseguire starship
eval $(starship bash)
```
## Cambia il titolo della finestra
Alcune shell prompt cambieranno automaticamente il titolo della finestra (ad esempio per riflettere la directory di lavoro). Fish lo fa per impostazione predefinita. Starship non lo fa, ma è abbastanza semplice aggiungere questa funzionalità a `bash` o `zsh`.
Innanzitutto, bisogna definire una funzione per il cambio del titolo della finestra (identica sia per bash che zsh):
```bash
function set_win_title(){
echo -ne "\033]0; IL_TUO_TITOLO_QUI \007"
}
```
Puoi usare delle variabili per personalizzare questo titolo (`$USER`, `$HOSTNAME`, e `$PWD` sono le scelte più popolari).
In `bash`, impostare questa funzione per essere la precmd Starship function:
```bash
starship_precmd_user_func="set_win_title"
```
In `zsh`, aggiungi questo `precmd_functions` all'array:
```bash
precmd_functions+=(set_win_title)
```
Se ti piace il risultato, aggiungi queste righe al tuo file shell di configurazione (`~/. ashrc` o `~/.zshrc`) per renderlo permanente.
Ad esempio, se desideri visualizzare la directory corrente nel titolo della scheda del terminale, aggiungi la seguente snippet al tuo `~/. ashrc` or `~/.zshrc`:
```bash
function set_win_title(){
echo -ne "\033]0; $(basename $PWD) \007"
}
starship_precmd_user_func="set_win_title"
```
## Stringhe di stile
Le stringhe di stile sono un elenco di parole, separate da spazi bianchi. Le parole non sono sensibili alle maiuscole (cioè `grassetto` e `BoLd` sono considerate la stessa stringa). Ogni parola può essere una delle seguenti:
- `bold`
- `underline`
- `dimmed`
- `bg:<color>`
- `fg:<color>`
- `<color>`
- `none`
dove `<color>` è un colore specifico (discusso in seguito). `fg:<color>` e `<color>` attualmente fanno la stessa cosa , anche se questo potrebbe cambiare in futuro. L'ordine delle parole nella stringa non conta.
Il token `none` sovrascrive tutti gli altri token in una stringa se non fa parte di uno specificatore `bg:`, così ad esempio `fg:red none fg:blue` creerà una stringa senza stile. `bg:none` imposta come colore di sfondo quello predefinito così `fg:red bg:none` è equivalente a `red` o `fg:red` e `bg:green fg:red bg:none` è equivalente a `fg:red` o `rosso`. Potrà diventare un errore usare `nessuno` in combinazione con altri token in futuro.
Uno colore specifico può essere uno di questi:
- Uno dei colori standard del terminale: `nero`, `rosso`, `verde`, `blu`, `giallo`, `viola`, `ciano`, `bianco`. Puoi eventualmente utilizzare il prefisso `bright-` per ottenere la versione luminosa (es. `bright-white`).
- Un `#` seguito da un valore esadecimale a sei cifre. Questo specifica un [colore esagesimale in RGB](https://www.w3schools.com/colors/colors_hexadecimal.asp).
- Un numero compreso tra 0-255. Specifica un [codice colore ANSI a 8 bit](https://i.stack.imgur.com/KTSQa.png).
Se sono specificati più colori per il primo piano/sfondo, l'ultimo nella stringa avrà la priorità.
## Come posso ottenere il completamento dei comandi come mostrato nella GIF demo?
Completion support, or autocomplete, is provided by your shell of choice. Nel caso della demo, la demo è stata fatta con [Fish Shell](https://fishshell.com/), che fornisce i completamenti per impostazione predefinita. Se usi Z Shell (zsh), ti suggerirei di dare un'occhiata a [zsh-autosuggestions](https://github.com/zsh-users/zsh-autosuggestions).
## Il formato di primo livello `` e `<module>.disabled` fanno la stessa cosa?
Sì, entrambi possono essere utilizzati per disabilitare i moduli nel prompt. Se tutto quello che pensi di fare è disabilitare i moduli, `<module>.disabled` è il modo preferito per per queste ragioni:
- Disabilitare i moduli è più esplicito che ometterli dal primo `formato` di livello
- I nuovi moduli creati saranno aggiunti al prompt come Starship viene aggiornato
## The docs say Starship is cross-shell. Why isn't my preferred shell supported?
Il modo in cui Starship è costruito, dovrebbe rendere possibile aggiungere il supporto per qualsiasi shell. Il binario di Starship è apolide e indipendente dalla shell, fino a quando la tua shell supporterà prompt personalizzati, Starship può essere utilizzato.
Ecco un piccolo esempio per avere Starship lavorando con bash:
```sh
# Ottenere lo status code dall'ultimo comando eseguito
STATUS=$?
# Ottieni il numero di processi in esecuzione.
NUM_JOBS=$(jobs -p | wc -l)
# Imposta il prompt come output di `starship prompt`
The [Bash implementation](https://github.com/starship/starship/blob/master/src/init/starship.bash) built into Starship is slightly more complex to allow for advanced features like the [Command Duration module](https://starship.rs/config/#command-duration) and to ensure that Starship is compatible with pre-installed Bash configurations.
Per un elenco di tutti i flag accettati da `starship prompt`, utilizzare il seguente comando:
```sh
starship prompt --help
```
The prompt will use as much context as is provided, but no flags are "required".
## Come faccio a eseguire le distribuzioni Starship su Linux con vecchie versioni di glibc?
Se si ottiene un errore come "_versione 'GLIBC_2. 8' non trovato (richiesta da Starship)_" quando si utilizza il binario precostruito (per esempio, su CentOS 6 o 7), puoi usare un binario compilato con `musl` invece di `glibc`:
## I see symbols I don't understand or expect, what do they mean?
If you see symbols that you don't recognise you can use `starship explain` to explain the currently showing modules.
## Why don't I see a glyph symbol in my prompt?
The most common cause of this is system misconfiguration. Some Linux distros in particular do not come with font support out-of-the-box. You need to ensure that:
- In locale sia impostato un valore UTF-8, come `de_DE.UTF-8` o `ja_JP.UTF-8`. Se `LC_ALL` non è un valore UTF-8, [dovrai cambiarlo](https://www.tecmint.com/set-system-locales-in-linux/).
- Hai un font emoji installato. La maggior parte dei sistemi ha un font emoji per impostazione predefinita, ma alcuni (in particolare Arch Linux) non lo fanno. Di solito puoi installarne uno attraverso il gestore dei pacchetti del tuo sistema-[noto emoji](https://www.google.com/get/noto/help/emoji/) è uno dei popolari.
- Stai usando un [font Nerd](https://www.nerdfonts.com/).
To test your system, run the following commands in a terminal:
```sh
echo -e "\xf0\x9f\x90\x8d"
echo -e "\xee\x82\xa0"
```
The first line should produce a [snake emoji](https://emojipedia.org/snake/), while the second should produce a [powerline branch symbol (e0a0)](https://github.com/ryanoasis/powerline-extra-symbols#glyphs).
If either symbol fails to display correctly, your system is still misconfigured. Unfortunately, getting font configuration correct is sometimes difficult. Users on the Discord may be able to help. If both symbols display correctly, but you still don't see them in starship, [file a bug report!](https://github.com/starship/starship/issues/new/choose)
## How do I uninstall Starship?
Starship is just as easy to uninstall as it is to install in the first place.
1. Rimuovi qualsiasi riga utilizzata per inizializzare Starship nella configurazione della tua shell (ad es. `~/.bashrc`).
1. Elimina il binario di Starship.
If Starship was installed using a package manager, please refer to their docs for uninstallation instructions.
If Starship was installed using the `curl | bash` script, the following command will delete the binary:
**Il prompt minimalista, super veloce e infinitamente personalizzabile per qualsiasi shell!**
- **Velocità:** è veloce –_davvero_ veloce! 🚀
- **Personalizzabile:** configura ogni aspetto del tuo prompt.
- **Universale:** funziona su qualsiasi shell, con qualsiasi sistema operativo.
- **Intelligente:** mostra le informazioni rilevanti a colpo d'occhio.
- **Ricco di funzionalità:** supporta tutti i tuoi strumenti preferiti.
- **Facile:** veloce da installare - inizia ad usarlo in pochi minuti.
<p align="center">
<a href="https://starship.rs/config/"><strong>Esplora la documentazione di Starship ▶</strong></a>
</p>
<a name="🚀-installation"></a>
## 🚀 Installazione
### Prerequisiti
- Un [Nerd Font](https://www.nerdfonts.com/) installato e abilitato nel tuo terminale (per esempio, prova [Fira Code Nerd Font](https://www.nerdfonts.com/font-downloads)).
### Inizia
**Nota**: a causa della proliferazione di piattaforme diverse, un sottoinsieme di piattaforme supportate sono mostrate di seguito. Non riesci a vedere la tua? Dai un'occhiata alle [istruzioni aggiuntive della piattaforma](https://starship.rs/installing/).
1. Installa il binario **starship**:
#### Installa l'ultima Versione
##### Da un binario precompilato, con Shell:
```sh
curl -fsSL https://starship.rs/install.sh | bash
```
#### Installa via Package Manager
##### Esempio: [Homebrew](https://brew.sh/):
```sh
brew install starship
```
##### Con [Scoop](https://scoop.sh):
```powershell
scoop install starship
```
2. Aggiungi lo script di inizializzazione al file di configurazione della shell:
#### Bash
Aggiungi quanto segue alla fine di `~/.bashrc`:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
Aggiungi quanto segue alla fine di `~/.config/fish/config.fish`:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
Aggiungi quanto segue alla fine di `~/.zshrc`:
```sh
# ~/.zshrc
eval "$(starship init zsh)"
```
#### PowerShell
Aggiungi quanto segue alla fine di `Microsoft.PowerShell_profile.ps1`. Puoi controllare la posizione di questo file interrogando la variabile `$PROFILE` in PowerShell. Tipicamente il percorso è `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` oppure `~/.config/powershell/Microsoft.PowerShell_profile.ps1` su -Nix.
```powershell
Invoke-Expression (&starship init powershell)
```
#### Ion
Aggiungi quanto segue alla fine di `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
**Attenzione** È supportato solo elvish v0.15 o superiore. Aggiungi quanto segue alla fine di `~/.elvish/rc.elv`:
```sh
# ~/.elvish/rc.elv
eval (starship init elvish)
```
#### Tcsh
Aggiungi quanto segue alla fine di `~/.tcshrc`:
```sh
# ~/.tcshrc
eval `starship init tcsh`
```
## 🤝 Contribuire
Siamo sempre alla ricerca di collaboratori di **tutti i livelli**! Se stai cercando di entrare facilmente nel progetto, prova un [buon primo problema](https://github.com/starship/starship/labels/🌱%20good%20first%20issue).
Se parli correntemente una lingua diversa dall'inglese, apprezziamo molto qualsiasi aiuto per mantenere i nostri documenti tradotti e aggiornati in altre lingue. Se desideri collaborare, le traduzioni possono essere fornite su [Starship Crowdin](https://translate.starship.rs/).
Se sei interessato ad aiutare a contribuire a Starship, dai un'occhiata alla nostra [Guida al Contributo](https://github.com/starship/starship/blob/master/CONTRIBUTING.md). Inoltre, sentiti libero di entrare nel nostro [server Discord](https://discord.gg/8Jzqu3T) e dire ciao. 👋
### Contributori di codice
Questi progetto esiste grazie a tutte le persone che contribuiscono. [[Contributo](https://github.com/starship/starship/blob/master/CONTRIBUTING.md)].
Supporta questo progetto con la tua organizzazione. Il tuo logo apparirà qui con un link al tuo sito web. [[Contribuisci](https://opencollective.com/starship/contribute)]
1. Tell your shell to use the starship binary as its prompt by modifying its init scripts
For most users, the instructions on [the main page](/guide/#🚀-installation) will work great. However, for some more specialized platforms, different instructions are needed.
There are so many platforms out there that they didn't fit into the main README.md file, so here are some installation instructions for other platforms from the community. Is yours not here? Please do add it here if you figure it out!
## [Chocolatey](https://chocolatey.org)
### Prerequisiti
Head over to the [Chocolatey installation page](https://chocolatey.org/install) and follow the instructions to install Chocolatey.
Starship v0.45.0 è una versione contenente importanti cambiamenti in preparazione della grande versione 1.0.0. Abbiamo apportato alcuni importanti cambiamenti per come la configurazione viene fatta sul prompt, al fine di consentire un maggior grado di personalizzazione.
Questa guida è destinata ad attraversare questi grandi cambiamenti.
## `prompt_order` è stato sostituito da un formato root-level ``
Previously to v0.45.0, `prompt_order` would accept an array of module names in the order which they should be rendered by Starship.
Starship v0.45.0 invece accetta un valore `format`, consentendo la personalizzazione del prompt al di fuori dei moduli stessi.
**Esempio di configurazione pre-v0.45.0**
```toml
prompt_order = [
"username",
"hostname",
"directory",
"git_branch",
"git_commit",
"git_state",
"git_status",
"cmd_duration",
"custom",
"line_break",
"jobs",
"battery",
"time",
"character",
]
```
**Esempio di configurazione v0.45.0**
```toml
format = """\
$username\
$hostname\
$directory\
$git_branch\
$git_commit\
$git_state\
$git_status\
$cmd_duration\
$custom\
$line_break\
$jobs\
$battery\
$time\
$character\
"""
```
## Il prefisso `del modulo` e il suffisso `` sono stati sostituiti dal formato ``
Precedentemente la v0.45.0, alcuni moduli accetterebbero `prefisso` e/o `suffisso` per stilare il modo in cui i moduli vengono renderizzati.
Starship v0.45.0 invece accetta un valore `format`, consentendo la personalizzazione del prompt al di fuori dei moduli stessi. Invece di definire un prefisso e un suffisso per le variabili basate sul contesto, le variabili possono ora essere sostituite da una stringa di formato, che rappresenta l'output del modulo.
**Esempio di configurazione pre-v0.45.0**
```toml
[cmd_duration]
prefisso = "tak"
```
**Esempio di configurazione v0.45.0**
```toml
[cmd_duration]
# $duration – The command duration (e.g. "15s")
# $style – The default style of the module (e.g. "bold yellow")
format = "took [$duration]($style) "
```
### Moduli soggetti
#### Character
| Proprietà rimossa | Sostituta |
| ----------------------- | ---------------- |
| `symbol` | `success_symbol` |
| `use_symbol_for_status` | `error_symbol` |
| `style_success` | `success_symbol` |
| `style_failure` | `error_symbol` |
**Modifiche alla configurazione predefinita**
```diff
[character]
-- symbol = "❯"
-- error_symbol = "✖"
-- use_symbol_for_status = true
-- vicmd_symbol = "❮"
++ success_symbol = "[❯](bold green)"
++ error_symbol = "[❯](bold red)"
++ vicmd_symbol = "[❮](bold green)"
```
Precedentemente, la proprietà `use_symbol_for_status` è stata utilizzata per configurare il prompt per mostrare `error_symbol` quando l'ultimo comando ha prodotto un codice di stato diverso da zero.
Con il rilascio di v0.45.0, ora usiamo sempre `error_symbol` dopo codici di stato diversi da zero, unificando le proprietà `use_symbol_for_status` e `error_symbol`.
Per configurare il prompt al fine di usare la vecchia configurazione `use_symbol_for_status = true`, aggiungi quanto segue al tuo file di configurazione:
```toml
[character]
error_symbol = "[✖](bold red)"
```
*Nota:* L'elemento `carattere` aggiunge dopo automaticamente uno spazio, quindi a differenza delle altre stringhe `formato`, non ne aggiungiamo uno specificamente agli esempi di cui sopra.
#### Command Duration
| Proprietà rimossa | Sostituta |
| ----------------- | --------- |
| `prefix` | `format` |
**Modifiche alla configurazione predefinita**
```diff
[cmd_duration]
-- prefix = "took "
++ format = "took [$duration]($style) "
```
#### Directory
| Proprietà rimossa | Sostituta |
| ----------------- | --------- |
| `prefix` | `format` |
**Modifiche alla configurazione predefinita**
```diff
[directory]
-- prefix = "in "
++ format = "[$path]($style)[$read_only]($read_only_style) "
```
#### Variabili di ambiente
| Proprietà rimossa | Sostituta |
| ----------------- | --------- |
| `prefix` | `format` |
| `suffix` | `format` |
**Modifiche alla configurazione predefinita**
```diff
[env_var]
-- prefix = ""
-- suffix = ""
++ format = "with [$env_value]($style) "
```
#### Git Commit
| Proprietà rimossa | Sostituta |
| ----------------- | --------- |
| `prefix` | `format` |
| `suffix` | `format` |
**Modifiche alla configurazione predefinita**
```diff
[git_commit]
-- prefix = "("
-- suffix = ")"
++ format = '[\($hash\)]($style) '
```
#### Git Status
| Proprietà rimossa | Sostituta |
| ----------------- | --------- |
| `prefix` | `format` |
| `suffix` | `format` |
| `show_sync_count` | `format` |
**Modifiche alla configurazione predefinita**
```diff
[git_status]
-- prefix = "["
-- suffix = "]"
-- show_sync_count = false
++ format = '([\[$all_status$ahead_behind\]]($style) )'
```
Precedentemente, la proprietà `show_sync_count` è stata utilizzata per configurare il prompt per mostrare il numero di commit che il ramo era avanti o dietro il ramo in remoto.
Con il rilascio della v0.45.0, questo è stato sostituito con tre proprietà separate, `ahead`, ` behind` e `diverged`.
Per configurare il prompt al fine di usare la vecchia configurazione `show_sync_count = true`, aggiungi quanto segue al tuo file di configurazione:
Ecco una raccolta dei preset di configurazione inviati dalla community per Starship. Se hai un preset da condividere, per favore [ invia un PR ](https://github.com/starship/starship/edit/master/docs/presets/README.md) aggiornando questo file! 😊
## Nerd Font Symbols
Questo preset non cambia nulla tranne i simboli utilizzati per ogni modulo. Se gli emoji non fanno per te, questo potrebbe attirare la tua attenzione!
### Prerequisiti
- Un [ Nerd Font ](https://www.nerdfonts.com/) installato e abilitato nel tuo terminale (l'esempio usa Fira Code Nerd Font)
Add the following to the end of `Microsoft.PowerShell_profile.ps1`. You can check the location of this file by querying the `$PROFILE` variable in PowerShell. 通常、パスは `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` または -Nix 上では `~/.config/powershell/Microsoft.PowerShell_profile.ps1` です。
```sh
Invoke-Expression (&starship init powershell)
```
#### Ion
`~/.config/ion/initrc `の最後に次を追加してください
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
::: warning Only elvish v0.15 or higher is supported. :::
`none` トークンは、文字列中の`bg:` 指定子の一部でない場合、他のすべてのトークンをオーバーライドします。そのため、たとえば、`fg:red none fg:blue` と指定した場合、スタイルなしの文字列が作られます。 `bg:none` sets the background to the default color so `fg:red bg:none` is equivalent to `red` or `fg:red` and `bg:green fg:red bg:none` is also equivalent to `fg:red` or `red`. 将来 `none` を他の単語と一緒に使用することはエラーになるかもしれません。
The [Bash implementation](https://github.com/starship/starship/blob/master/src/init/starship.bash) built into Starship is slightly more complex to allow for advanced features like the [Command Duration module](https://starship.rs/config/#command-duration) and to ensure that Starship is compatible with pre-installed Bash configurations.
一行目は[蛇の絵文字](https://emojipedia.org/snake/)、二行目は[powerline branch symbol (e0a0)](https://github.com/ryanoasis/powerline-extra-symbols#glyphs)が表示されるはずです。
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Matan Kushner
