Have switched all vi/vim symbols to have the same prefix 'vim'. To
preserve backwards compatibility with existing configs I have added an
alias for the previous config name.
* add proper vi mode detection for fish shell
* update tests
* fix test
* update config-schema.json
* update docs
* add warning about symbols only supported in fish
* check for go.work file to display go version
* add test to check for go.work file
* update docs to include go.work file
* chore(dprint): fmt & upgrade plugins (#3969)
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
This is an actualization of PR #559 as originally envisioned by qryxip.
Adds the ability to display toolchain versions, either as extracted from
environment/settings files or by getting the host triple. As part of
this, several other major changes were needed:
- Many of the smaller functions within the code have been fused, moved,
or dropped.
- The Rustup environmental info is now initialized lazily using
OnceCells. This will hopefully lead to a performance increase.
- New configuration variables (`toolchain` and `numver`) have been added
to allow finer-grained configuration.
- Override information is no longer read from `rustup` output. Instead,
it is parsed from the same files that rustup would use to determine
this info.
Co-authored-by: qryxip <qryxip@gmail.com>
Co-authored-by: qryxip <qryxip@gmail.com>
* feat(package): Extract package version from PEP621 pyproject.toml
* Update docs explaining PEP 621 package version
* Only read pyproject.toml once
* Simplify get_pep621_version
* Handle version formatting in get_pyproject_version
* fix: Do not panic in config if editor not found
* Add tests for edit_configuration
Adds tests for no-panic condition on editor by adding an override to
edit_configuration.
* Sorry clippy :(
Have added so additional spaces around the vuepress markers, `:::`, to
ensure that the don't get included in the line above and below and cause
formatting errors in the translated versions of the documentation.
* perf(package): only try to read files that exist
Have refactored the package module to improve performance. Before this
change the module would try to open every single file that could contain
some package information until it found a valid version. This resulted
in a lot of unneeded disk IO. Have added a new fn, `read_file_from_pwd`
that uses the current context to check if that file already exists and
fast failing if it doesn't. From my local testing this speeds up the
package module from taking ~1ms to ~50µs in an empty directory.
* refactor: move read_file_from_pwd to context
* refactor(haskell): use read_files_from_pwd
* refactor(nodejs): use read_files_from_pwd
* refactor: replace module_config_derive with serde
Changes include:
* Removing `starship_module_config_derive` and replacing it with `serde::Deserialize`
* Removing `RootModuleConfig::load_config`. While potentially useful, it was only used in tests. And it would require something like `serde::DeserializeSeed` which is not derived by serde.
* Merging `RootModuleConfig` into `ModuleConfig`
* Implementing a `ValueDeserializer` that holds a reference to a `toml::Value` in `serde_utils.rs`
* Deserialization errors (invalid type) are now logged and include the current key and the struct names
* Unknown keys are now considered an error. "Did you mean?"-messages are still possible
* fix typo
Co-authored-by: Matan Kushner <hello@matchai.dev>
Co-authored-by: Matan Kushner <hello@matchai.dev>
* add option to force AWS display
Even if no credentials or credential_process have been setup
* change README wording
* Include sso_start_url in the description
* Change option name to force_display
* feat(haskell): add haskell module and implement ghc version detection
* feat(haskell): implement stack resolver version detection
* fix(haskell): handle more complex resolvers
* fix(haskell): rename resolver_version to snapshot
* fix(haskell): change default color to bold purple
* feat(haskell): add tests
* fix(haskell): format
* fix(haskell): replace incorrect `or` with `or_else`
* fix(haskell): use write_all instead of write
* fix(haskell): λ as Haskell icon by default
* fix(haskell): fix tests and add a real stack.yaml testcase
* fix(haskell): make clippy happy
* Rename m.aws.alias_region to alias_name
* Add aws profile aliases
* Document aws.profile_aliases, with examples
* Add tests for new aws.profile_aliases feature
* Tidy alias_handling a bit
* Use relative links
* Remove migrating link
* Fix zh-* config
* Adjust how sidebar is generated
* Enable evergreen
* Format
* Update docs/.vuepress/config.js
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
By default, unzip will attempt to query the user when files to be
installed already exist. Unfortunately, if the install script is run
with `sh -s`, unzip will read the remaining portion of the script as
input, resulting in a mess on the terminal.
This commit changes the unzip behavior to clobber existing files: this
already happens for platforms using tar, so it's not hugely breaking
(and I could find no evidence that we believe this is more likely to
cause issues on Windows)
The installation script warns about `BIN_DIR` not being found in `$PATH`
when the users pass a trailing forward slash.
This has been discussed in #1310, #1341, and #3486.
Fixes#3493
* New preset system
* Add Rust to NerdFonts preset
* Add more links and access
Add image titles and links in headers to make things more accessible.
* Shrink + optimize PNG images
Fixes a bug in the Rust module where overrides would match
against both full path components as well as partial ones
(e.g. "/etc/passwd" would be considered a prefix of
"/etc/passwd_new") on Windows.
Solution is to convert back to a PathBuf after lossy conversion
so that Path::starts_with is used instead of str::starts_with.
* feat: Add a Windows application manifest
Closes#3589
* Enable longPathAware
* Switch to winres crate
* Only depend on winres on Windows
* Switch to cfg attribute
* only display aws on credential_process defined
* add check for both credential_process and valid credentials
* fix tests
* update aws module documentation
* add better explanation of requirements to documentation
* add support for AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, and update docs
* remove credential_process env var
* Use global:error[0] for most recent error
The current version use $error[0], which is for the module instead of the global status and is always $null, so the $lastExitCodeForPrompot is always $origLastExitCode (see https://github.com/starship/starship/issues/3485 for a related bug).
It should be replaced with $global:error[0]
Comments are also updated
* fix(pwsh): make Semantic PR bot happy
* fix(#3554): Print the command line argv on clap error
This is a very bare implementation that just prints the error
and then a note with the arguments passed, it does this manually
and doesn't use clap. I've also chosen to use `Vec`'s `Debug`
implementation instead of rolling my own one because I thought it was
good enough, but there might be a better way of doing all this.
Altogether, I think this will be very useful to help in the diagnostic
of other bugs :)
* fix(#3554): Print the command line argv on clap error
This is a very bare implementation that just prints the error
and then a note with the arguments passed, it does this manually
and doesn't use clap. I've also chosen to use `Vec`'s `Debug`
implementation instead of rolling my own one because I thought it was
good enough, but there might be a better way of doing all this.
Altogether, I think this will be very useful to help in the diagnostic
of other bugs :)
EDIT: removed `dbg!`, set it to exit always.
* correctness(exit): don't print argv / exit with error on help and
version error kinds
* fix: Avoid panicking when stdout/stderr closing unexpectedly
* refactor(cli): use `use_stderr` instead of manual match for error kinds
`clap` uses `use_stderr` to reliably check whether the error given is
actually an error coming from user input or rather a hint to display
other info (version, help, etc.)
Also reworded/moved a couple of comments so that they explain better
what is the thought process behind the code
* fix(status): Enable to convert from i64 to hex_status by casting instead of parsing status.
* Apply comment to src/context.rs
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* Update README.md in configuration
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
In #1019 the undistract feature has been added to starship without
enabling it by default due to the system dependency on libdbus. With
recent versions of notify-rust the dependency is no longer required and
the feature can be enabled by default.
* fix: use e718 as the default of symbol in node configuration
* wip: change nodejs symbol in docs/config & add a nodejs symbol configuration in docs/presets
* wip: update CONTRIBUTING.md
* Allow customization of notification timeout
* Document new notification duration option
* Check for out-of-bounds timeout and correct it
* Implement ModuleConfig for u32
* Revert "Check for out-of-bounds timeout and correct it"
This reverts commit 52109ab5f7.
* Switch notification_timeout to u32
* Note notification_daemons might not honor timout
* Notification timeout defaults to daemon timeout
* Leave default value of notification_timeout blank in docs
The `$PWD` environment variable used by starship is not updated on startup by `elvish`. `elvish` also provides a separate `$pwd` variable that does get updated and seems to be be a better indicator for the current logical path.
* ci: Fix aws::expiration_date_set_from_file race
While aws::expiration_date_set_from_file will almost-always work
perfectly locally, it is theoretically possible for the thread running
the test to be scheduled away betwen writing the file with timing
information and then actually reading it, resulting in a
shorter-than-expected time appearing in the module. This can also happen
if the test triggers right at the very end of a second (e.g. at
10:45:47.999995).
This appears to actually happen sometimes on heavily-loaded GitHub
Actions runners. To fix this issue, we allow for up to a two-second
delay between when the file is written and when the test actually fires
(allowing "30m", "29m59s", and "29m58s" as possible values).
* Fix typo
Have updated the workflow to only run the "Block Translated Changes" job
on PRs since it will fail when run on pushes to a branch. Have fixed the
formatting while I was here.
* ci: Add workflow to block crowdin changes
* Add a change which should not block the PR (will be reverted later)
* Repair broken workflows
* Add a change which should stop the PR
* Revert "Add a change which should not block the PR (will be reverted later)"
This reverts commit eafb5eaed1.
* Revert "Add a change which should stop the PR"
This reverts commit bfe6e7a39d.
* test: add mock method for absolute files
Signed-off-by: Harald Hoyer <harald@hoyer.xyz>
* feat(module): add a container indicator module
Adds a container type indicator, if inside a container,
detected via the presence of some marker files.
E.g. inside a podman container entered with `toolbox enter`
the prompt changes to the container name and version.
```
starship on container_rebased [$!] is 📦 v1.0.0 via 🦀 v1.56.1
❯ toolbox enter
starship on container_rebased [$!] is 📦 v1.0.0 via 🦀 v1.56.1
⬢ [fedora-toolbox:35] ❯
```
Signed-off-by: Harald Hoyer <harald@hoyer.xyz>
As the number of supported systems and shells has grown, we've had to hand-pick what installation methods would be the "blessed" ones to show on our README. This change changes that to include all installation methods, but hides them each into OS and shell-specific collapsed sections, as is done by the excellent ajeetdsouza/zoxide.
* ci: Add jobs for `cargo check` with all features and no features
Augmenting #3435: These jobs will check that compilation still succeeds when no features are selected and with all features selected. So when in the future new features are added, these quick checks can prevent miss-compilation for users that like to tweak with feature sets.
* (fixup) More descriptive job names
* ci: Make the new `cargo_check_*` jobs depend on `cargo_check`
* Fixed starship config location
config file during creation and when used as export variable into shells are different.
Fixed to make it uniform and avoid errors
* Update README.md
* Update docs/config/README.md
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* Update docs/config/README.md
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* 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>
* fix(pwsh): Avoid polluting the global function namespace
This is an alternative to #3386
* Review changes
* Move continuation prompt after setting starship env
* feat: add support for cmd
* add preprompt and precmd support
* add keymap support
* add info about minimum Clink version
* simplify escaping
* add handling for cmd custom commands
* add support for transient_prompt and transient_rprompt
* Revert 9140579525
This reverts commit "add support for transient_prompt and transient_rprompt"
* Apply suggestions from code review
* disable cmd shell custom commands
* any shell other than cmd can be used
* better error and correct script location
* move shell check in `map_no_escaping`
* feat: set a continuation prompt for supporting shells (#3134)
* docs: fixed wording of documentation
* fix: continuation prompt is now only set once
* fix(docs): fixed typo in advanced-config/README.md
Co-authored-by: Segev Finer <segev208@gmail.com>
* fix: update --continuation argument
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* fix: updated continuation prompt
- PROMPT2 was fixed to be set only once in zsh.
- `continuation_symbol` and `continuation_format` were removed in
place of a single variable; `continuation_prompt`.
- The continuation prompt was moved out of the character module.
* fix: ran rustfmt
* docs: updated continuation prompt docs
Co-authored-by: Segev Finer <segev208@gmail.com>
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* perf(git_status): tweak flags to omit extra info
`git status` can be prohibitively slow on some repos, so allow the
config to influence what flags are passed to git. For instance, if there
is no configured symbol for untracked files, tell git to omit them from
its output. This can easily result in a 2~10x speedup in many cases, but
requires the user to opt-in to hiding information from the prompt.
* docs(git_status): add ignore_submodules option
* feat: Experimental Windows path formatting via path_slash::PathBufExt
* Rework the slash path conversion into a real PR
* Add a test for convert_slash = false
* Attempt fixing CI failures
* Fix lint and fmt
* Fix docs/config/README.md getting messed up
* Rename convert_slash/from_slash
* Move convert_path_sep calls in tests
* Keep path_vec immutable
* Run rustfmt
* perf(rust): additionally check `rustup default` for faster result.
After checking directory overrides we were directly falling back to the
relatively slow call to `rustc --version`.
Inserting a call to `rustup default` leads to a quicker response.
* use `context.exec_cmd` instead of `create_command`
Previous code would render all components as empty, resulting
in an empty string even if min_time was 0. This adds a special
case which forces prompt to render "0ms"
When opening a directory as a file the intial open works, while
subsequent line-reads will fail with _is a directory_.
Since erroring line-reads were just skipped this lead to an
endless loop.
These need to be stored before calling any PowerShell function or executable.
Otherwise the values will be overwritten and cannot be properly restored
or passed to starship.
Fixes: #3315
* add feature - sudo module
* add sudo module identifiers and entry point
* fix test test_sudo_not_cached
* add test test_sudo_cached
* add `allow_windows` and `binary` options
* rustfmt sudo_x_cached and rmv them on windows
* add false `allow_windows` block windows test
* add `doas` cached/not_cached tests
* better description in `starship explain`
* fix `test_doas_cached` with `-n` flag
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* rmv `binary` alternatives and their tests
* fix symbol and update config/README
* fix all mocks to use `sudo -n true`
* fix expected output in `test_sudo_cached`
* proper checking for blocked sudo
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* add `allow_windows = true` to non-windows tests
* allow sudo_* tests to run on windows + fix parsed
* rustfmt `blocks_windows` test
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* docs(faq): Add debugging docs to the FAQ.
Have added some basic docs on debugging to the FAQ.
* docs(faq): Add question about commands timing out
Have added a question and answer about commands timing out and what to
do.
* Update docs/faq/README.md
Co-authored-by: Matan Kushner <hello@matchai.dev>
Co-authored-by: Matan Kushner <hello@matchai.dev>
This should fix some modules not working correctly in the fish
`RPROMPT`. I have done this the very naive way by simply duplicating the
code that is currently in the `fish_prompt` function to avoid having to
change the scope of any of the variables (currently all local).
* add crystal shard (package) version support
* module package: crystal shard version: read shard.yml directly
* module package: add test for crystal shard version
* format src/modules/package.rs
* use yaml-rust instead of serde-yaml
* document shards package support
* 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>
* allow unset KEYMAP and STARSHIP_DURATION in zsh
which prevents errors if a user has `set -u` on in there terminal.
* fix: allow unset KEYMAP and STARSHIP_DURATION in zsh
Add `terminal-width` argument to explicitly define terminal's width
Update pwsh,bash,zsh,fish init scripts with `terminal-width` argument
Co-authored-by: Kevin Song <chips@ksong.dev>
Co-authored-by: Kevin Song <4605384+chipbuster@users.noreply.github.com>
Changes the parsing for pipestatus to allow for multiple arguments, a
single argument of space-separated values, or any mix of the two. All
inputs are flattened into a single array where no elements have spaces
in them.
Changes the initscripts to no longer fail when an empty pipestatus
is passed as an argument by quoting and changing expansions.
Have updated which extentions trigger the terraform module, to remove
the `hcl` since this gives false positives as it is used by other
Hashicorp products and add the `tfstate` and `tfplan` which are more
accurate indicators.
* Refactored the usage function to use printf
Using printf to print the usage function instead of a here doc handles
the formatting for us so it will be consistent across a wide variety of
terminal emulators. Here docs also tend to mess up auto-formatters so
removing it has that added benefit.
* Made the install instructions their own function
The function loops through simular install instructions so this way we
won't have to repeat ourselves every time we add a new supported shell.
* Set default config_file location
The default location is based on the name of the shell. It is overwritten when needed.
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Due to the introduction of utils::create_command, commands now have
stdin set to null, and stdout and stderr set to piped.
This prevents console editors from working when invoked via
starship config
* Correct the "VLang" configuration example
This commit is a document correction only; to avoid the configuration error.
The documents to be corrected are "docs/[lang]/README.md".
With a config key of `[v]` on macOS, it has the following error.
```
[WARN] - (starship::configs::starship_root): Unknown config key 'v'
```
I think it might be the error in other OS as well.
In the other document "docs/[lang]/presets/README.md", the config key is `[vlang]`.
* Touch only the English docs
The changes to the translated pages will be done automatically.
Have added version formatting to the red and vlang modules. Note the
docs for red already mentioned the `version_format` string but it had
not actually been added.
* feat: Add the symbol and number thresholds respecting the threshold option
* fix: Maintain the old behavior + add lots of tests
* docs: Fix the jobs module documentation
* git_status: added symbol for when local branch is up-to-date with upstream
* updated docs
* removed unused variable, moved location of config comment
* changed uptodate default to empty string, simplified and made safer
* added uptodate default line back into docstring
* fixed linting and formatting errors
* refactored uptodate to up_to_date, removed redundant else statement
Have added the ability to use format the version of the package using
the `version_format` option. While doing this I have also done some
refactoring of the module to remove the if/else if/... block and replace
it with an iterator. This should make fix some edge cases where versions
are not correctly picked up due to other files an example would be a
python project that has a `pyproject.toml` file but using the
`setup.cfg` for the package version. It should also make it easier to
make the order of the list configurable in the future.
* feat: Add pipestatus display in status module
This MR is based on this one https://github.com/starship/starship/pull/370
* Documentation
* Add a test with map_symbol false
* Handle bash preexec pipestatus
* Add zsh support
* Add fish support
Thanks kidonng for the diff patch
* Rename sucess_symbol to success_symbol
* Support package version from setup.cfg (python).
Add an additional package version extraction function to parse
the 'version' attribute under the 'metadata' section in a python
package 'setup.cfg' file.
Also add similar tests from the poetry extraction function to test
the desired behaviour.
This adds a dependency on ConfigParser:
https://crates.io/crates/configparser.
* Clean up comments
* Use rust_ini over ConfigParser
* Add mention to setup.cfg version parsing in docs
* feat: add support for xonsh
* xonsh: add STARSHIP_SESSION_KEY
* xonsh: implement STARSHIP_SESSION_KEY in xonsh
* docs: mention tcsh, elvish, and nu in more places
* xonsh: change STARSHIP_SESSION_KEY implementation
See https://github.com/starship/starship/pull/2807#discussion_r667064149
* xonsh: fix jobs implementation
* xonsh: do not silently discard stderr from starship
On Windows when running commands with their name instead of the path with Command::new, executable with that name from the current working directory will be executed.
This PR replaces all instances of Command::new with a new create_command function which will first resolve any executable paths and avoid this issue.
Get-Error does not exist in all versions of PowerShell, and attempting to use it on machines where it does not exist pollutes $error. Someone may be tempted to use -ErrorAction Ignore but since the command does not exist, it still ends up in $error
This is a dual bug fix because it actually gets errors on all machines now and it does not pollute $error.
This PR adds a new module named git_metrics. It shows the added/deleted lines in the current git repository following the format: "[+$added_lines]($added_style) [-$deleted_lines]($deleted_style)".
* Add support for `rust-toolchain.toml`
* fix(rust): support for `rust-toolchain.toml`
* This commit adds support for `rusttoolchain.toml`.
* Added some tests.
* Added some comments on what the tests are checking.
* Changed code for `read_channel` to match the behavier of rustup.
* Update src/modules/rust.rs
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* Update rust module
Added back the functionality to cache
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* docs(character): Add warning about missing feature
Have added some additional docs to indicate that `vicmd_symbol` doesn't
work for bash's vi mode.
* Update docs/config/README.md
* feat(formatter): Allow scoped variables (#1094)
* feat: Allow scoped variables
, with the following improvements to the format string parser.
- Add documentation to spec
- Simplify some syntax in the spec
- Rewrite for loop with iterators
* Added support for R programming language.
* Removed unnecessary debug log used during dev process.
* Make the `R` command upper case as the *nix OS executables are case sensitives and the correct command is upper-case.
* Changed comments to reflect R features (rather than node.js where code was coming from).
* feat(format_string): Allow positional segments (#1138)
* feat(format_string): Allow using variables in a style string (#1130)
* fix(format_string): Allow multiple variable mappers (#1142)
* refactor: Add error handling to variables (#1148)
* Squashed commit of changes with meta variables:
commit 5beb3bca18f0b0c822b740afb3778ccb1e3a7d19
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Mon Apr 27 09:52:59 2020 +0800
fix: Cache variables in meta variables properly
commit 49b9324942dd55350c87107d0e8c7d1592d92e8a
Merge: cc575bc 260a1ab
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Sun Apr 26 21:34:52 2020 +0800
Merge branch 'feat/format-string' into meta-variables
commit cc575bc27cbf87c4197e96d2fa5416d4932e45d7
Merge: 3ed2d32 e0c1901
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Sun Apr 26 12:16:12 2020 +0800
Merge branch 'feat/format-string' into meta-variables
commit 3ed2d326c9f625930bdd72cea736c1d0eab6d381
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Sun Apr 26 11:06:28 2020 +0800
refactor(format_string): Allow returning error in variable mapper
commit 766732fe69
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Sat Apr 25 22:56:02 2020 +0800
fix: Add test for StyleVariableHolder
commit 444334ad20
Merge: 479d4a79796a66
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Sat Apr 25 22:52:27 2020 +0800
Merge branch 'positional-segments' into style-variables
commit 9796a66a96
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Sat Apr 25 22:51:26 2020 +0800
test: Add tests for VariableHolder
commit 479d4a72fa
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Sat Apr 25 22:41:47 2020 +0800
feat: Add trait StyleVariableHolder
commit 21d40c6f4e
Merge: 3b459f4e7dd987
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Sat Apr 25 22:17:11 2020 +0800
Merge branch 'positional-segments' into style-variables
commit e7dd987fd7
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Sat Apr 25 15:10:12 2020 +0800
misc: Minor changes on docs and codes
commit 71020b0397
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Fri Apr 24 20:51:45 2020 +0800
feat(format_string): Add syntax for positional segments
commit 3b459f4379
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Wed Apr 22 17:49:15 2020 +0800
fix: Fix clippy
commit 2fb052d68c
Author: heyrict <xiezh0831@yahoo.co.jp>
Date: Wed Apr 22 17:02:09 2020 +0800
feat: Add map_style method to feed values in style string
* fix: Change error type of StringFormatter::new
* fix: Fix rustfmt
* tests: Add tests to variable errors
* docs: Add documentation
* chore: Rename positional to conditional (#1166)
* docs: Add docs for format strings (#1083)
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* refactor(rust): Use format strings (#1063)
* Updated to latest string formatter's changes.
* feat(format-string): add format string support to battery module (#1158)
* update battery module with format string
* update battery module docs
* update battery module with format string
* update battery module docs
* fix battery module with new StringFormatter api
* fix clippy warnings
* Update docs/config/README.md
Co-authored-by: Zhenhui Xie <xiezh0831@yahoo.co.jp>
* battery symbols now supports format-string
* battery symbols now support format-string
remove space between symbol and percentage
fix battery config
Co-authored-by: Zhenhui Xie <xiezh0831@yahoo.co.jp>
* refactor(golang): Use format strings (#1066)
* refactor(golang): Use format strings
* docs(golang): Update docs
* docs(golang): Update docs
* fix: Update to upstream API changes
* docs(golang): Update docs
Co-authored-by: heyrict <xiezh0831@yahoo.co.jp>
* Fixed a few inconsistencies.
* Removed string clone in favor of a reference.
* Update src/modules/r.rs
Reverting the r version string formatting to a more idiomatic way of handling it.
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
* Update src/configs/r.rs
Co-authored-by: Zhenhui Xie <xiezh0831@yahoo.co.jp>
* Updated documentation to reflect changes in config.
* refactor(java): Added formatter support for Java module. (#1084)
* refactor(haskell): Added formatter support for the Haskell module. (#1111)
* Added formatter support for the Haskell module.
* Updated haskell module with latest formatter code changes.
* Changed documentation for latest Haskell string formatter changes.
* Fixed a few inconsistencies.
* Removed unnecessary variable cloning for using reference instead.
* refactor(env_var): Added formatter support for the env_var module (#1180)
* refactor(memory_usage): Added formatter support for memory_usage module (#1182)
* Migrated the memory usage module to string formatter' support.
* Fixed a few inconsistencies.
* Removed cloning of variables to instead use references.
* refactor(cmd_duration): Use format strings (#1200)
* Fixed format issue in code.
* Fixed compilation error after adding new 'r' module in root config.
* Added .Rproj extension file to be detected with R prog lang.
* Aligned R module code with existing ones.
* Update src/configs/r.rs
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* fix: Added rconfig to fullconfig and fixed broken api calls
* Apply suggestions from code review
Co-authored-by: Dario Vladović <d.vladimyr@gmail.com>
* Update src/modules/r.rs
Co-authored-by: Dario Vladović <d.vladimyr@gmail.com>
* Addressed PR comments.
Cleaned up code and fixed code errors.
* Updated docs for consistency purpose.
Co-authored-by: Milo <50248166+Milo123459@users.noreply.github.com>
* refactor: Renamed the `r` module to `rlang`
* test: Provided R fixture and R module renderer test
* doc: Updated rlang mod config to reflect latest detection changes
* fix: Added missing rlang entry in config/mod
* feat: Added version formatted fined grained configuration
* Added version_format in R lang documentation.
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* review: Addressed later comments
* fix: README was missing a previously present section for Python
* Fix: Test was not updated for previous version string upgrade.
* fix: Upgraded R version in remaining test.
Co-authored-by: Zhenhui Xie <xiezh0831@yahoo.co.jp>
Co-authored-by: Thomas O'Donnell <andytom@users.noreply.github.com>
Co-authored-by: Luca Rinaldi <lucarin@protonmail.com>
Co-authored-by: John Letey <johnletey@gmail.com>
Co-authored-by: Tilmann Meyer <47182955+ATiltedTree@users.noreply.github.com>
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
Co-authored-by: Dario Vladović <d.vladimyr@gmail.com>
Co-authored-by: Milo <50248166+Milo123459@users.noreply.github.com>
* feat(nim): add support for nimble project package version
* Replace find_file with context scanner. Fixes the failing tests.
* Replace `utils::exec_cmd` with `context.exec_cmd` so that it uses
global timeout
* Add tests for nimble project version
* Add docs for nimble in package version module for english language
* Update docs/config/README.md
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* Add test for a case when nimble is not available
* Remove extract_vlang_version
I don't know why it did not come up while I was fixing merge conflicts
on rebase.
Co-authored-by: David Knaack <davidkna@users.noreply.github.com>
* format crystal version with VersionFormatter
* update crystal dosc
* format crystal module
* fix typos
* format dart version with VersionFormatter
* fix dart malformed test
* update dart docs
* format cmake version with VersionFormatter
* update cmake docs
* format deno version with VersionFormatter
* update deno docs
* remove Version type
* format dotnet version with VersionFormatter
* update dotnet docs
* format erlang version with VersionFormatter
* update erlang docs
* format golang version with VersionFormatter
* refactor formatting in my modules
* format helm version with VersionFormatter
* format julia version with VersionFormatter
* format kotlin version with VersionFormatter
* format lua version with VersionFormatter
* format nim version with VersionFormatter
* format perl version with VersionFormatter
* format php version with VersionFormatter
* format purescript version with VersionFormatter
* format scala version with VersionFormatter
* format swift version with VersionFormatter
* format terraform version with VersionFormatter
* format vagrant version with VersionFormatter
* format zig version with VersionFormatter
* format elixir version with VersionFormatter
* format ocaml version with VersionFormatter
* update elixir docs
* update golang docs
* update helm docs
* update julia docs
* update kotlin docs
* update lua docs
* update nim docs
* update ocaml docs
* update perl docs
* update php docs
* update purescript docs
* update scala docs
* update swift docs
* update terraform docs
* update vagrant docs
* update zig docs
* format elm version with VersionFormatter
* update elm docs
* pass module_name as &str to format_module_version
* Revert "fix(zsh): Set PROMPT just once (#2428)"
This reverts commit 6fd7d7b501.
* Reintroduce fixes around START_TIME
* Bring back disabling virtualenv
* Expand the jobstates before passing the number to starship
Credit goes to @vladimyr
* Add support for `reverse` keyword in style strings
* Duplicate test case and keep original
* Rename keyword to `inverted`
* Add explanatory sentence in readme
* feat: Add a symbol option to `battery.display`
* feat: Add a symbol option to `battery.display`
* use `impl defaulat` instead of `RootModuleConfig`
* edit the code according to clippy's linting
* change variable type to `Option<'a str>`
* update the documentation on the battery module
* updated documentation and source code according to review comment
* remove the unnecessary method and write the default value of BatteryDisplayConig to the document
* add 'charging_symbol' option to battery.display
Quote expansion of $PWD to prevent word-splitting of its value, which
gives an incorrect result if there is a single space and an error
message if there is more than one space:
❯ basename /tmp/foo
foo
❯ basename /tmp/foo bar
foo
❯ basename /tmp/foo bar baz
basename: extra operand ‘baz’
Try 'basename --help' for more information.
* style(init): Cleanup the unknown shell message
Have make a small change to the message that is printed when an unknow
shell is used. This correct the placement of the trailing `"` so that
the two training new lines are correctly printed and updates the list of
supported shells.
* refactor(init): consolidate unknown shell errors
Have consolidated the two unknown shell errors
* refactor(init): Quote the shell name in the output
Quote the shell name in the script and combined the shell_name and
shell_basename to simplify the code a little.
Previously attempting to use conditional format strings with
`$indicator` would never display an indicator, e.g.:
```toml
[shell]
fish_indicator = ""
bash_indicator = "B "
format = "($indicator )"
disabled = false
```
This would always display an empty string.
Fixes#2474.
* 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.
* **winget:** Add support for winget package manager ([#4042](https://github.com/starship/starship/issues/4042)) ([ef52f9e](https://github.com/starship/starship/commit/ef52f9e77ec66f5189a18acfdce399882c37fdd8))
### Bug Fixes
* **character:** Standadise Vim config names ([#4081](https://github.com/starship/starship/issues/4081)) ([6761938](https://github.com/starship/starship/commit/67619386cdd7537f0ab9af77e701409e97a87917))
* **install:** Have fixed a spacing issue in output ([#4082](https://github.com/starship/starship/issues/4082)) ([2ffe173](https://github.com/starship/starship/commit/2ffe1737f06db4ce89a21b2b5238f3ad76c94bca))
* Add support for Daml ([#4004](https://github.com/starship/starship/issues/4004)) ([3fe6cc0](https://github.com/starship/starship/commit/3fe6cc023cd52917ae60a4d06ee6f1f78baa19e7))
* **kubernetes:** add user alias ([#4008](https://github.com/starship/starship/issues/4008)) ([df5c2d8](https://github.com/starship/starship/commit/df5c2d8836622677460e34fa8082faa6b1a52835))
* **release:** add windows msi installers ([#4031](https://github.com/starship/starship/issues/4031)) ([89fd532](https://github.com/starship/starship/commit/89fd5320af248207e8b253790bd191d8daa88dbe))
### Bug Fixes
* escape text segments in meta variables ([#3563](https://github.com/starship/starship/issues/3563)) ([7d31bac](https://github.com/starship/starship/commit/7d31bac1cc3f39bd02f2e188e69283c566b816ed))
* **fish:** add proper vi mode detection for fish shell ([#3839](https://github.com/starship/starship/issues/3839)) ([1469763](https://github.com/starship/starship/commit/146976351ec804ab1594d5262a1e0dd2d2de4972))
* **install:** ignore tarfile ownership values when installing as root ([#4046](https://github.com/starship/starship/issues/4046)) ([1a91510](https://github.com/starship/starship/commit/1a91510beda1de2c3b149b7aacc0d76cf4652482))
* **nu:** don't use `cygpath` for starship binary path in init ([#4001](https://github.com/starship/starship/issues/4001)) ([9b52475](https://github.com/starship/starship/commit/9b52475e541f751e8c650587cd8c1615fe00b1d0))
* some typos ([e7c1976](https://github.com/starship/starship/commit/e7c19765282eb31daf85e5eba26e13828bc2f6c7))
* **go:** check for go.work file to show Go module in prompt ([#3968](https://github.com/starship/starship/issues/3968)) ([9ebfce1](https://github.com/starship/starship/commit/9ebfce1e366656bd1c199bb50cc7e1bd6cdb90ad))
* **hostname:** add `ssh_symbol` for ssh connections ([#3806](https://github.com/starship/starship/issues/3806)) ([2bf30dc](https://github.com/starship/starship/commit/2bf30dc89fbce6f4da37657b8af6077f15a543d0))
* **package:** Extract package version from PEP 621 compliant pyproject.toml ([#3950](https://github.com/starship/starship/issues/3950)) ([1b938fd](https://github.com/starship/starship/commit/1b938fd48420ceedf1e9886bd95ea738374680f7))
* **ci:** Version bump and fix Crowdin Pretranslate ([#3992](https://github.com/starship/starship/issues/3992)) ([a0a6c94](https://github.com/starship/starship/commit/a0a6c942fe3fc85d599aec883406224c9ecb589f))
* Do not panic in config if editor not found ([#3766](https://github.com/starship/starship/issues/3766)) ([2e80aec](https://github.com/starship/starship/commit/2e80aec5cb6f7376359e7a25a76a492a98717554))
* **module:** list option not working ([#3919](https://github.com/starship/starship/issues/3919)) ([6fe6735](https://github.com/starship/starship/commit/6fe6735927170b9f2aaa10cb84fa3a4d754e3bd6))
* **nu:** use the most recent starship init ([#3908](https://github.com/starship/starship/issues/3908)) ([382445d](https://github.com/starship/starship/commit/382445dc4d21d190959f5582fb9b9febe056299a))
* Use git2::Repository::open_ext() instead of discover() ([#3591](https://github.com/starship/starship/issues/3591)) ([81a696a](https://github.com/starship/starship/commit/81a696a914f6761d42b69f139018c3fa663ff197))
* **git_branch:** correct variable name for remote branch ([#3897](https://github.com/starship/starship/issues/3897)) ([bd7957f](https://github.com/starship/starship/commit/bd7957f01c7fa2b14f068e4130f1aedea61f4a76))
* **schema:** move config-schema into docs folder ([#3878](https://github.com/starship/starship/issues/3878)) ([094f982](https://github.com/starship/starship/commit/094f982df184eecd85ea2832b3bf638629118c10))
### Performance Improvements
* **package:** only try to read files that exist ([#3904](https://github.com/starship/starship/issues/3904)) ([2a650bf](https://github.com/starship/starship/commit/2a650bfd140d561f955705cae124fb254ec549a1))
### Reverts
* **schema:** move config-schema back into .github folder ([#3886](https://github.com/starship/starship/issues/3886)) ([9b2ce42](https://github.com/starship/starship/commit/9b2ce4240c602df368f966996d870ef9197e65ac))
* Add a module for C projects ([#3631](https://github.com/starship/starship/issues/3631)) ([0863146](https://github.com/starship/starship/commit/0863146f072ae8382be63db26dcf9ddeff967aea))
* **aws:** add option to force AWS display ([#3720](https://github.com/starship/starship/issues/3720)) ([e04f126](https://github.com/starship/starship/commit/e04f126a107eba2e40009f21942c14894385d6b0))
* **cmd_duration:** make notify feature optional (compat with nix darwin) ([#3855](https://github.com/starship/starship/issues/3855)) ([efaab49](https://github.com/starship/starship/commit/efaab49e4753bee1ce90ad08311a1d4dc04052b8))
* **username:** Detect Admin access in Windows ([#2791](https://github.com/starship/starship/issues/2791)) ([c89c130](https://github.com/starship/starship/commit/c89c13038a34a52291d253e6d4b15c0dd4aa5dfa))
### Bug Fixes
* **bash:** ensure `checkwinsize` is enabled for `$COLUMNS` ([#3832](https://github.com/starship/starship/issues/3832)) ([0334327](https://github.com/starship/starship/commit/03343272b778260016216266facd190936f9e7d3))
* **directory:** enable repo_root_style when truncation_length is zero. ([#3536](https://github.com/starship/starship/issues/3536)) ([441ebb3](https://github.com/starship/starship/commit/441ebb39b9cd451564959d259409d2395e7afb01))
* **docker_context:** ignore the "default" context ([#3803](https://github.com/starship/starship/issues/3803)) ([#3804](https://github.com/starship/starship/issues/3804)) ([230e85b](https://github.com/starship/starship/commit/230e85be37a0fc12999d1e6ff1209e7d5f99ecd1))
* **fish:** allow generating session keys in older versions of fish ([#3697](https://github.com/starship/starship/issues/3697)) ([0fb4219](https://github.com/starship/starship/commit/0fb421969058ec07a09f7c927dddc1258de75631))
* **init:** Change Elvish init to `catch` for 0.18 ([#3769](https://github.com/starship/starship/issues/3769)) ([538329d](https://github.com/starship/starship/commit/538329d9b406cd6358d0fe31d58e0c9f578ceffa))
* **nu:** Use `=` instead of space to pass command line parameters ([#3833](https://github.com/starship/starship/issues/3833)) ([2608db3](https://github.com/starship/starship/commit/2608db3a38b0dca13d91e94950fb4246b0ed1d82))
* **nu:** use shell-provided terminal width ([#3800](https://github.com/starship/starship/issues/3800)) ([859b780](https://github.com/starship/starship/commit/859b780b46780fdcac8141a9d165066880c36261))
@@ -8,9 +8,9 @@ If you have any questions that aren't addressed in this document, please don't h
## Glossary
- **Module**: A component in the prompt giving information based on contextual information from your OS. For example, the `nodejs` module shows the version of NodeJS that is currently installed on your computer, if your current directory is a NodeJS project.
- **Module**: A component in the prompt giving information based on contextual information from your OS. For example, the `rust` module shows the version of Rust that is currently installed on your computer, if your current directory is a Rust project.
- **Segment**: Smaller sub-components that compose a module. For example, the `symbol` segment in the `nodejs` module contains the character that is shown before the version number (`⬢` by default).
- **Segment**: Smaller sub-components that compose a module. For example, the `symbol` segment in the `rust` module contains the character that is shown before the version number (`🦀` by default).
## Philosophy
@@ -24,18 +24,105 @@ The project begins in [`main.rs`](src/main.rs), where the appropriate `print::`
Any styling that is applied to a module is inherited by its segments. Module prefixes and suffixes by default don't have any styling applied to them.
## Environment Variables and external commands
We have custom functions to be able to test our modules better. Here we show you how.
### Environment Variables
To get an environment variable we have special function to allow for mocking of vars. Here's a quick example:
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,69 +131,178 @@ 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). Markdown and TOML files (among others) are formatted with [dprint](https://github.com/dprint/dprint). Unformatted code will fail the CI, so it is suggested that you run these tools locally.
For rustfmt:
```sh
rustup component add rustfmt
cargo fmt
```
For dprint:
```sh
cargo install dprint
dprint fmt
```
Editor plugins/functionality may help you run these automatically so that you don't accidentally create a PR that fails.
If your changes cause changes to the configuration, you will need to update the configuration schema in `.github/config-schema.json` with `cargo run --features config-schema -- config-schema > .github/config-schema.json`.
## 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 [`./acceptance_test`](acceptance_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 acceptance tests expecting the testing environment to have preexisting state or making permanent changes to the filesystem should have the `#[ignore]` attribute. 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.
Acceptance tests require Docker to be installed, as they are run inside a Docker container. This can be done as described in the official [documentation](https://docs.docker.com/install/). The acceptance tests can then be executed by running the included [`./acceptance_test`](acceptance_test) script. It might be necessary to run [`./acceptance_test`](acceptance_test) with `sudo` if your user is not part of the `docker` group.
## Documentation
### Crowdin Translated Pages
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)).
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.
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.
If you would like to contribute translations or corrections to the Crowdin
generated pages, please visit our Crowdin site.
### Benchmarking
### Running the Documentation Website Locally
Benchmarks are located in the [`benches/`](benches) directory and are written using the [Criterion](https://crates.io/crates/criterion) library.
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
If you are contributing to the design of Starship's website, the following section will help you get started.
### Setup
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:
```
$ npm install
```
3. Start the project in development mode:
```
$ npm run dev
```
Once setup is complete, you can refer to VuePress documentation on the actual implementation here: https://vuepress.vuejs.org/guide/.
```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
## New Module Checklist
We love getting new modules for starship! While we try to keep the barrier for
writing new modules low, starship provides a lot of functionality for a module,
which requires quite a few things be done. These are listed here to help
everyone remember what they are. Don't worry: most of them are quite simple!
- [ ] Add a section to `docs/config/README.md` describing the module, and
its configuration options/variables (more documentation is often
appropriate--this is a bare minimum).
- [ ] Add the variable to the appropriate location in the "Default Prompt
Format" section of the documentation
- [ ] Add an appropriate choice of options to each preset in `docs/presets/README.md`
- [ ] Update the config file schema by running `cargo run --features config-schema -- config-schema > .github/config-schema.json`
- [ ] Create configs structs/traits in `src/configs/<module>.rs` and add the
following:
- [ ] An entry in `PROMPT_ORDER` (`src/configs/starship_root.rs`)
- [ ] An entry in `FullConfig` and the `Default` impl (`src/configs/mod.rs`)
- [ ] An entry in `ALL_MODULES` (`src/module.rs`)
- [ ] A `mod` declaration at the top of `src/modules/mod.rs`
- [ ] An entry in `handle()` (`src/modules/mod.rs`)
- [ ] A description for the `description()` function (`src/modules/mod.rs`)
Finally, you should make sure to write your module's code in `src/modules`
and add any commands that need to be mocked when testing in `src/utils.rs`.
Command output can also be mocked in test by using `ModuleRenderer::cmd`.
**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 Java version(`☕`)
- Current Node.js version(`⬢`)
- Current Rust version (`🦀`)
- Current Ruby version (`💎`)
- Current Python version (`🐍`)
- Current Go version (`🐹`)
- Nix-shell environment detection
- Print an environment variable
- 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 (`✦`)
- Current Kubernetes Cluster and Namespace (`☸`)
- Current AWS profile (`☁️`)
<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
### Step 1. Install Starship
1. Install the **starship** binary:
Select your operating system from the list below to view installation instructions:
**[Download archives of precompiled binaries](https://github.com/starship/starship/releases)** if you don't use the platforms below.
<details>
<summary>Android</summary>
#### Homebrew
Install Starship using any of the following package managers:
```sh
$ brew install starship
```
| Repository | Instructions |
| ---------- | ---------------------- |
| [Termux] | `pkg install starship` |
#### Rust (v1.38 or higher)
</details>
```sh
$ cargo install starship
```
<details>
<summary>BSD</summary>
#### Arch Linux (AUR)
Install Starship using any of the following package managers:
Starship is available on the AUR under the name `starship`. Install it with `yay` or your favorite AUR helper.
Configure your shell to initialize starship. Select yours from the list below:
eval "$(starship init zsh)"
```
<details>
<summary>Bash</summary>
#### Powershell
Add the following to the end of `~/.bashrc`:
Add the following to the end of `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` (or `~/.config/powershell/Microsoft.PowerShell_profile.ps1` on -Nix):
```sh
eval"$(starship init bash)"
```
```sh
# ~\Documents\PowerShell\Profile.ps1
Invoke-Expression (&starship init powershell)
```
</details>
## 🔧 Configuration
<details>
<summary>Cmd</summary>
For details on how to configure Starship, check out our [documentation](https://starship.rs/config/).
You need to use [Clink](https://chrisant996.github.io/clink/clink.html) (v1.2.30+) with Cmd.
Create a file at this path `%LocalAppData%\clink\starship.lua` with the following contents:
```lua
load(io.popen('starship init cmd'):read("*a"))()
```
</details>
<details>
<summary>Elvish</summary>
Add the following to the end of `~/.elvish/rc.elv`:
```sh
eval(starship init elvish)
```
Note: Only Elvish v0.18+ is supported
</details>
<details>
<summary>Fish</summary>
Add the following to the end of `~/.config/fish/config.fish`:
```fish
starship init fish|source
```
</details>
<details>
<summary>Ion</summary>
Add the following to the end of `~/.config/ion/initrc`:
```sh
eval$(starship init ion)
```
</details>
<details>
<summary>Nushell</summary>
Add the following to the end of your Nushell env file (find it by running `$nu.env-path` in Nushell):
```sh
mkdir ~/.cache/starship
starship init nu | save ~/.cache/starship/init.nu
```
And add the following to the end of your Nushell configuration (find it by running `$nu.config-path`):
```sh
source ~/.cache/starship/init.nu
```
Note: Only Nushell v0.61+ is supported
</details>
<details>
<summary>PowerShell</summary>
Add the following to the end of your PowerShell configuration (find it by running `$PROFILE`):
```powershell
Invoke-Expression(&starshipinitpowershell)
```
</details>
<details>
<summary>Tcsh</summary>
Add the following to the end of `~/.tcshrc`:
```sh
eval`starship init tcsh`
```
</details>
<details>
<summary>Xonsh</summary>
Add the following to the end of `~/.xonshrc`:
```python
execx($(starshipinitxonsh))
```
</details>
<details>
<summary>Zsh</summary>
Add the following to the end of `~/.zshrc`:
```sh
eval"$(starship init zsh)"
```
</details>
### Step 3. Configure Starship
Start a new shell instance, and you should see your beautiful new shell prompt.
If you're happy with the defaults, enjoy!
If you're looking to further customize Starship:
- **[Configuration](https://starship.rs/config/)** – learn how to configure Starship to tweak your prompt to your liking
- **[Presets](https://starship.rs/presets/)** – get inspired by the pre-built configuration of others
## 🤝 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
Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/docs/en/emoji-key)):
<!-- ALL-CONTRIBUTORS-LIST:START - Do not remove or modify this section -->
"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, Tcsh, Elvish, Nu, Xonsh, Cmd, and Powershell.",
"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, Tcsh, Elvish, Nu, Xonsh, Cmd, 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, Tcsh, Elvish, Nu, Xonsh, Cmd, 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 `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` (or `~/.config/powershell/Microsoft.PowerShell_profile.ps1` on -Nix):
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
# ~\Documents\PowerShell\Profile.ps1
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.18 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`
```
#### Nushell
::: warning
This will change in the future.
Only Nushell v0.61+ is supported.
:::
Add the following to to the end of your Nushell env file (find it by running `$nu.env-path` in Nushell):
```sh
mkdir ~/.cache/starship
starship init nu | save ~/.cache/starship/init.nu
```
And add the following to the end of your Nushell configuration (find it by running `$nu.config-path`):
```sh
source ~/.cache/starship/init.nu
```
#### Xonsh
Add the following to the end of `~/.xonshrc`:
```sh
# ~/.xonshrc
execx($(starship init xonsh))
```
#### Cmd
You need to use [Clink](https://chrisant996.github.io/clink/clink.html) (v1.2.30+) with Cmd. Add the following to a file `starship.lua` and place this file in Clink scripts directory:
Some shells support a right prompt which renders on the same line as the input. Starship can
set the content of the right prompt using the `right_format` option. Any module that can be used
in `format` is also supported in `right_format`. The `$all` variable will only contain modules
not explicitly used in either `format` or `right_format`.
Note: The right prompt is a single line following the input location. To right align modules above
the input line in a multi-line prompt, see the [`fill` module](/config/#fill).
`right_format` is currently supported for the following shells: elvish, fish, zsh, xonsh, cmd.
### Example
```toml
# ~/.config/starship.toml
# A minimal left prompt
format="""$character"""
# move the rest of the prompt to the right
right_format="""$all"""
```
Produces a prompt like the following:
```
▶ starship on rprompt [!] is 📦 v0.57.0 via 🦀 v1.54.0 took 17s
```
## Continuation Prompt
Some shells support a continuation prompt along with the normal prompt. This prompt is rendered instead of the normal prompt when the user has entered an incomplete statement (such as a single left parenthesis or quote).
Starship can set the continuation prompt using the `continuation_prompt` option. The default prompt is `"[∙](bright-black) "`.
Note: `continuation_prompt` should be set to a literal string without any variables.
Note: Continuation prompts are only available in the following shells:
-`bash`
-`zsh`
-`PowerShell`
### Example
```toml
# ~/.config/starship.toml
# A continuation prompt that displays two filled in arrows
continuation_prompt="▶▶"
```
## 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`
-`bold`
-`italic`
-`underline`
-`dimmed`
-`inverted`
-`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.
where `<color>` is a color specifier (discussed below). `fg:<color>` and `<color>` currently do the same thing, though this may change in the future.`inverted` swaps the background and foreground colors. The order of words in the string does not matter.
The `none` token overrides all other tokens in a string, so that e.g. `fg:red none fg:blue` will still create a string with no styling. It may become an error to use `none` in conjunction with other tokens in the future.
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).
- 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, Tcsh, Elvish, Nu, Xonsh, Cmd, and PowerShell.
- تثبيت [Nerd Font](https://www.nerdfonts.com/) وتمكينه في موجه الأوامر الخاصة بك.
### تثبيت سريع
1. تثبيت **starship**:
#### تثبيت أحدث إصدار
بإستخدام Shell:
```sh
curl -sS https://starship.rs/install.sh | sh
```
لتحديث Starship نفسه، أعد تشغيل البرنامج النصي أعلاه. سيتم استبدال الإصدار الحالي بدون لمس تكوين Starship.
#### التثبيت عبر مدير الحزم
بإستخدام [Homebrew](https://brew.sh/):
```sh
brew install starship
```
بإستخدام [Scoop](https://scoop.sh):
```powershell
scoop install starship
```
1. أضف ما يلي إلى ملف تكوين موجه الأوامر الخاص بك:
#### Bash
أضف ما يلي إلى نهاية `~/.bashrc`:
```sh
# ~/.bashrc
eval "$(starship init bash)"
```
#### Fish
أضف ما يلي إلى نهاية `~/.config/fish/config.fish`:
```sh
# ~/.config/fish/config.fish
starship init fish | source
```
#### Zsh
أضف ما يلي إلى نهاية `~/.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
أضف ما يلي إلى نهاية `~/.config/ion/initrc`:
```sh
# ~/.config/ion/initrc
eval $(starship init ion)
```
#### Elvish
::: تحذير
Only elvish v0.18 or higher is supported.
:::
أضف ما يلي إلى نهاية `~/.elvish/rc.elv`:
```sh
# ~/.elvish/rc.elv
eval (starship init elvish)
```
#### Tcsh
أضف ما يلي إلى نهاية `~/.tcshrc`:
```sh
# ~/.tcshrc
eval `starship init tcsh`
```
#### Nushell
::: تحذير
This will change in the future. Only Nushell v0.61+ is supported.
:::
Add the following to to the end of your Nushell env file (find it by running `$nu.env-path` in Nushell):
```sh
mkdir ~/.cache/starship
starship init nu | save ~/.cache/starship/init.nu
```
And add the following to the end of your Nushell configuration (find it by running `$nu.config-path`):
```sh
source ~/.cache/starship/init.nu
```
#### Xonsh
أضف ما يلي إلى نهاية `~/.xonshrc`:
```sh
# ~/.xonshrc
execx($(starship init xonsh))
```
#### Cmd
You need to use [Clink](https://chrisant996.github.io/clink/clink.html) (v1.2.30+) with Cmd. Add the following to a file `starship.lua` and place this file in Clink scripts directory:
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.
::: تحذير
The configurations in this section are subject to change in future releases of Starship.
:::
## Custom pre-prompt and pre-execution Commands in Cmd
Clink provides extremely flexible APIs to run pre-prompt and pre-exec commands in Cmd shell. It is fairly simple to use with Starship. Make the following changes to your `starship.lua` file as per your requirements:
- To run a custom function right before the prompt is drawn, define a new function called `starship_preprompt_user_func`. This function receives the current prompt as a string that you can utilize. For example, to draw a rocket before the prompt, you would do
```lua
functionstarship_preprompt_user_func(prompt)
print("🚀")
end
load(io.popen('starship init cmd'):read("*a"))()
```
- To run a custom function right before a command is executed, define a new function called `starship_precmd_user_func`. This function receives the current commandline as a string that you can utilize. For example, to print the command that's about to be executed, you would do
```lua
functionstarship_precmd_user_func(line)
print("Executing: "..line)
end
load(io.popen('starship init cmd'):read("*a"))()
```
## 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.
## Custom pre-prompt and pre-execution Commands in PowerShell
PowerShell does not have a formal preexec/precmd framework like most other shells. Because of this, it is difficult to provide fully customizable hooks in `powershell`. However, Starship does give you limited ability to insert your own functions into the prompt-rendering procedure:
Create a function named `Invoke-Starship-PreCommand`
```powershell
functionInvoke-Starship-PreCommand{
$host.ui.Write("🚀")
}
```
## Change Window Title
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`, `zsh`, `cmd` or `powershell`.
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"
```
For Cmd, you can change the window title using the `starship_preprompt_user_func` function.
Some shells support a right prompt which renders on the same line as the input. Starship can set the content of the right prompt using the `right_format` option. Any module that can be used in `format` is also supported in `right_format`. The `$all` variable will only contain modules not explicitly used in either `format` or `right_format`.
Note: The right prompt is a single line following the input location. To right align modules above the input line in a multi-line prompt, see the [`fill` module](/config/#fill).
`right_format` is currently supported for the following shells: elvish, fish, zsh, xonsh, cmd.
### مثال
```toml
# ~/.config/starship.toml
# A minimal left prompt
format="""$character"""
# move the rest of the prompt to the right
right_format="""$all"""
```
Produces a prompt like the following:
```
▶ starship on rprompt [!] is 📦 v0.57.0 via 🦀 v1.54.0 took 17s
```
## Continuation Prompt
Some shells support a continuation prompt along with the normal prompt. This prompt is rendered instead of the normal prompt when the user has entered an incomplete statement (such as a single left parenthesis or quote).
Starship can set the continuation prompt using the `continuation_prompt` option. The default prompt is `"[∙](bright-black) "`.
Note: `continuation_prompt` should be set to a literal string without any variables.
Note: Continuation prompts are only available in the following shells:
-`bash`
-`zsh`
-`PowerShell`
### مثال
```toml
# ~/.config/starship.toml
# A continuation prompt that displays two filled in arrows
continuation_prompt="▶▶"
```
## 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`
-`italic`
-`underline`
-`dimmed`
-`inverted`
-`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. `inverted` swaps the background and foreground colors. 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`:
```sh
curl -sS https://starship.rs/install.sh | sh -s -- --platform unknown-linux-musl
```
## Why do I see `Executing command "..." timed out.` warnings?
Starship executes different commands to get information to display in the prompt, for example the version of a program or the current git status. To make sure starship doesn't hang while trying to execute these commands we set a time limit, if a command takes longer than this limit starship will stop the execution of the command and output the above warning, this is expected behaviour. This time limit is configurable using the [`command_timeout`key](/config/#prompt) so if you want you can increase the time limit. You can also follow the debugging steps below to see which command is being slow and see if you can optimise it. Finally you can set the `STARSHIP_LOG` env var to `error` to hide these warnings.
## 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.
## Starship is doing something unexpected, how can I debug it?
You can enable the debug logs by using the `STARSHIP_LOG` env var. These logs can be very verbose so it is often useful to use the `module` command if you are trying to debug a particular module, for example, if you are trying to debug the `rust` module you could run the following command to get the trace logs and output from the module.
```sh
env STARSHIP_LOG=trace starship module rust
```
If starship is being slow you can try using the `timings` command to see if there is a particular module or command that to blame.
```sh
env STARSHIP_LOG=trace starship timings
```
This will output the trace log and a breakdown of all modules that either took more than 1ms to execute or produced some output.
Finally if you find a bug you can use the `bug-report` command to create a Github issue.
```sh
starship bug-report
```
## 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 install script, the following command will delete the binary:
- تثبيت [Nerd Font](https://www.nerdfonts.com/) وتمكينه في موجه الأوامر الخاصة بك (على سبيل المثال، جرب [Fira Code Nerd Font](https://www.nerdfonts.com/font-downloads)).
### Step 1. Install Starship
Select your operating system from the list below to view installation instructions:
<details>
<summary>Android</summary>
Install Starship using any of the following package managers:
Configure your shell to initialize starship. Select yours from the list below:
<details>
<summary>Bash</summary>
أضف ما يلي إلى نهاية `~/.bashrc`:
```sh
eval"$(starship init bash)"
```
</details>
<details>
<summary>Cmd</summary>
You need to use [Clink](https://chrisant996.github.io/clink/clink.html) (v1.2.30+) with Cmd. Create a file at this path `%LocalAppData%\clink\starship.lua` with the following contents:
```lua
load(io.popen('starship init cmd'):read("*a"))()
```
</details>
<details>
<summary>Elvish</summary>
أضف ما يلي إلى نهاية `~/.elvish/rc.elv`:
```sh
eval(starship init elvish)
```
Note: Only Elvish v0.18+ is supported
</details>
<details>
<summary>Fish</summary>
أضف ما يلي إلى نهاية `~/.config/fish/config.fish`:
```fish
starship init fish|source
```
</details>
<details>
<summary>Ion</summary>
أضف ما يلي إلى نهاية `~/.config/ion/initrc`:
```sh
eval$(starship init ion)
```
</details>
<details>
<summary>Nushell</summary>
Add the following to the end of your Nushell env file (find it by running `$nu.env-path` in Nushell):
```sh
mkdir ~/.cache/starship
starship init nu | save ~/.cache/starship/init.nu
```
And add the following to the end of your Nushell configuration (find it by running `$nu.config-path`):
```sh
source ~/.cache/starship/init.nu
```
Note: Only Nushell v0.61+ is supported
</details>
<details>
<summary>PowerShell</summary>
Add the following to the end of your PowerShell configuration (find it by running `$PROFILE`):
```powershell
Invoke-Expression(&starshipinitpowershell)
```
</details>
<details>
<summary>Tcsh</summary>
أضف ما يلي إلى نهاية `~/.tcshrc`:
```sh
eval`starship init tcsh`
```
</details>
<details>
<summary>Xonsh</summary>
أضف ما يلي إلى نهاية `~/.xonshrc`:
```python
execx($(starshipinitxonsh))
```
</details>
<details>
<summary>Zsh</summary>
أضف ما يلي إلى نهاية `~/.zshrc`:
```sh
eval"$(starship init zsh)"
```
</details>
### Step 3. Configure Starship
Start a new shell instance, and you should see your beautiful new shell prompt. If you're happy with the defaults, enjoy!
If you're looking to further customize Starship:
- **[Configuration](https://starship.rs/config/)** – learn how to configure Starship to tweak your prompt to your liking
- **[Presets](https://starship.rs/presets/)** – get inspired by the pre-built configuration of others
## 🤝 المساهمة
نبحث دائماً عن مساهمين من **جميع المستويات**! إذا كنت تتطلع إلى تسهيل طريقك إلى المشروع، جرب [إنشاء اول مشكلة](https://github.com/starship/starship/labels/🌱%20good%20first%20issue).
إذا كنت تتحدث بطلاقة بلغة غير إنجليزية، فإننا نقدر أي مساعدة للحفاظ على ترجمة المستندات وتحديثها بلغات أخرى. إذا كنت ترغب في المساعدة، يمكن المساهمة بالترجمة على [Starship Crowdin](https://translate.starship.rs/).
إذا كنت مهتما بالمساهمة في starship، يرجى إلقاء نظرة على [دليل المساهمة](https://github.com/starship/starship/blob/master/CONTRIBUTING.md) لدينا. أيضا، لا تتردد في أن تنضم لنا في [Discord](https://discord.gg/8Jzqu3T) وقُل مرحبا. 👋
## 💭 مستوحاة من قبل
يرجى التحقق من هذه الأعمال السابقة التي ساعدت على إنشاء starship. 🙏
- **[denysdovhan/spaceship-prompt](https://github.com/denysdovhan/spaceship-prompt)** – A ZSH prompt for astronauts.
- **[denysdovhan/robbyrussell-node](https://github.com/denysdovhan/robbyrussell-node)** – Cross-shell robbyrussell theme written in JavaScript.
- **[reujab/silver](https://github.com/reujab/silver)** – A cross-shell customizable powerline-like prompt with icons.
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)
### المتطلبات الأساسية
Head over to the [Chocolatey installation page](https://chocolatey.org/install) and follow the instructions to install Chocolatey.
### Installation
```powershell
chocoinstallstarship
```
## [termux](https://termux.com)
### المتطلبات الأساسية
```sh
pkg install getconf
```
### Installation
```sh
curl -sS https://starship.rs/install.sh | sh -s -- --bin-dir /data/data/com.termux/files/usr/bin
```
## [Funtoo Linux](https://www.funtoo.org/Welcome)
### Installation
On Funtoo Linux, starship can be installed from [core-kit](https://github.com/funtoo/core-kit/tree/1.4-release/app-shells/starship) via Portage:
```sh
emerge app-shells/starship
```
## [Nix](https://nixos.wiki/wiki/Nix)
### Getting the Binary
#### Imperatively
```sh
nix-env -iA nixos.starship
```
#### Declarative, single user, via [home-manager](https://github.com/nix-community/home-manager)
Enable the `programs.starship` module in your `home.nix` file, and add your settings
```nix
{
programs.starship={
enable=true;
# Configuration written to ~/.config/starship.toml
settings={
# add_newline = false;
# character = {
# success_symbol = "[➜](bold green)";
# error_symbol = "[➜](bold red)";
# };
# package.disabled = true;
};
};
}
```
then run
```sh
home-manager switch
```
#### Declarative, system-wide, with NixOS
Add `pkgs.starship` to `environment.systemPackages` in your `configuration.nix`, then run
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! 😊
To get details on how to use a preset, simply click on the image.
## [Nerd Font Symbols](./nerd-font.md)
This preset changes the symbols for each module to use Nerd Font symbols.
[](./nerd-font)
## [Bracketed Segments](./bracketed-segments.md)
This preset changes the format of all the built-in modules to show their segment in brackets instead of using the default Starship wording ("via", "on", etc.).
[](./bracketed-segments)
## [Plain Text Symbols](./plain-text.md)
This preset changes the symbols for each module into plain text. Great if you don't have access to Unicode.
[](./plain-text)
## [No Runtime Versions](./no-runtimes.md)
This preset hides the version of language runtimes. If you work in containers or virtualized environments, this one is for you!
[](./no-runtimes)
## [Pure Prompt](./pure-preset.md)
This preset emulates the look and behavior of [Pure](https://github.com/sindresorhus/pure).
[](./pure-preset)
## [Pastel Powerline](./pastel-powerline.md)
This preset is inspired by [M365Princess](https://github.com/JanDeDobbeleer/oh-my-posh/blob/main/themes/M365Princess.omp.json). It also shows how path substitution works in starship.
[](./pastel-powerline)
[Return to Presets](./README.md#bracketed-segments)
# Bracketed Segments Preset
This preset changes the format of all the built-in modules to show their segment in brackets instead of using the default Starship wording ("via", "on", etc.).
### Configuration
[Click to download TOML](/presets/toml/bracketed-segments.toml)
This preset is inspired by [M365Princess](https://github.com/JanDeDobbeleer/oh-my-posh/blob/main/themes/M365Princess.omp.json). It also shows how path substitution works in starship.
### المتطلبات الأساسية
- A [Nerd Font](https://www.nerdfonts.com/) installed and enabled in your terminal (the example uses Caskaydia Cove Nerd Font)
### Configuration
[Click to download TOML](/presets/toml/pastel-powerline.toml)
This will change in the future. Only Nushell v0.61+ is supported.
:::
Add the following to to the end of your Nushell env file (find it by running `$nu.env-path` in Nushell):
```sh
mkdir ~/.cache/starship
starship init nu | save ~/.cache/starship/init.nu
```
And add the following to the end of your Nushell configuration (find it by running `$nu.config-path`):
```sh
source ~/.cache/starship/init.nu
```
#### Xonsh
ئەمەی دێت زیادبکە بۆ کۆتایی پەڕگەی `~/.xonshrc`:
```sh
# ~/.xonshrc
execx($(starship init xonsh))
```
#### Cmd
You need to use [Clink](https://chrisant996.github.io/clink/clink.html) (v1.2.30+) with Cmd. Add the following to a file `starship.lua` and place this file in Clink scripts directory:
## Custom pre-prompt and pre-execution Commands in Cmd
Clink provides extremely flexible APIs to run pre-prompt and pre-exec commands in Cmd shell. It is fairly simple to use with Starship. Make the following changes to your `starship.lua` file as per your requirements:
- To run a custom function right before the prompt is drawn, define a new function called `starship_preprompt_user_func`. This function receives the current prompt as a string that you can utilize. For example, to draw a rocket before the prompt, you would do
```lua
functionstarship_preprompt_user_func(prompt)
print("🚀")
end
load(io.popen('starship init cmd'):read("*a"))()
```
- To run a custom function right before a command is executed, define a new function called `starship_precmd_user_func`. This function receives the current commandline as a string that you can utilize. For example, to print the command that's about to be executed, you would do
```lua
functionstarship_precmd_user_func(line)
print("Executing: "..line)
end
load(io.popen('starship init cmd'):read("*a"))()
```
## فرمانە کڕیاڕخوازەکانی pre-prompt و pre-execution لە Bashـدا
بەپێچەوانەی شێلەکانی دیکە Bash هیچ چوارچێوەیەکی فەرمی preexec/precmdـی نییە. لەبەر ئەوە، دابین کردنی قولابە تەواو کڕیارخوازکراوەکان ئاسان نییە لە `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.
## Custom pre-prompt and pre-execution Commands in PowerShell
PowerShell does not have a formal preexec/precmd framework like most other shells. Because of this, it is difficult to provide fully customizable hooks in `powershell`. However, Starship does give you limited ability to insert your own functions into the prompt-rendering procedure:
Create a function named `Invoke-Starship-PreCommand`
```powershell
functionInvoke-Starship-PreCommand{
$host.ui.Write("🚀")
}
```
## Change Window Title
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`, `zsh`, `cmd` or `powershell`.
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"
```
For Cmd, you can change the window title using the `starship_preprompt_user_func` function.
Some shells support a right prompt which renders on the same line as the input. Starship can set the content of the right prompt using the `right_format` option. Any module that can be used in `format` is also supported in `right_format`. The `$all` variable will only contain modules not explicitly used in either `format` or `right_format`.
Note: The right prompt is a single line following the input location. To right align modules above the input line in a multi-line prompt, see the [`fill` module](/config/#fill).
`right_format` is currently supported for the following shells: elvish, fish, zsh, xonsh, cmd.
### نموونە
```toml
# ~/.config/starship.toml
# A minimal left prompt
format="""$character"""
# move the rest of the prompt to the right
right_format="""$all"""
```
Produces a prompt like the following:
```
▶ starship on rprompt [!] is 📦 v0.57.0 via 🦀 v1.54.0 took 17s
```
## Continuation Prompt
Some shells support a continuation prompt along with the normal prompt. This prompt is rendered instead of the normal prompt when the user has entered an incomplete statement (such as a single left parenthesis or quote).
Starship can set the continuation prompt using the `continuation_prompt` option. The default prompt is `"[∙](bright-black) "`.
Note: `continuation_prompt` should be set to a literal string without any variables.
Note: Continuation prompts are only available in the following shells:
-`bash`
-`zsh`
-`PowerShell`
### نموونە
```toml
# ~/.config/starship.toml
# A continuation prompt that displays two filled in arrows
continuation_prompt="▶▶"
```
## 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:
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`:
```sh
curl -sS https://starship.rs/install.sh | sh -s -- --platform unknown-linux-musl
```
## Why do I see `Executing command "..." timed out.` warnings?
Starship executes different commands to get information to display in the prompt, for example the version of a program or the current git status. To make sure starship doesn't hang while trying to execute these commands we set a time limit, if a command takes longer than this limit starship will stop the execution of the command and output the above warning, this is expected behaviour. This time limit is configurable using the [`command_timeout`key](/config/#prompt) so if you want you can increase the time limit. You can also follow the debugging steps below to see which command is being slow and see if you can optimise it. Finally you can set the `STARSHIP_LOG` env var to `error` to hide these warnings.
## 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.
## Starship is doing something unexpected, how can I debug it?
You can enable the debug logs by using the `STARSHIP_LOG` env var. These logs can be very verbose so it is often useful to use the `module` command if you are trying to debug a particular module, for example, if you are trying to debug the `rust` module you could run the following command to get the trace logs and output from the module.
```sh
env STARSHIP_LOG=trace starship module rust
```
If starship is being slow you can try using the `timings` command to see if there is a particular module or command that to blame.
```sh
env STARSHIP_LOG=trace starship timings
```
This will output the trace log and a breakdown of all modules that either took more than 1ms to execute or produced some output.
Finally if you find a bug you can use the `bug-report` command to create a Github issue.
```sh
starship bug-report
```
## 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 install script, the following command will delete the binary:
Configure your shell to initialize starship. Select yours from the list below:
<details>
<summary>Bash</summary>
ئەمەی خوارەوە زیادبکە لە کۆتایی `~/.bashrc`:
```sh
eval"$(starship init bash)"
```
</details>
<details>
<summary>Cmd</summary>
You need to use [Clink](https://chrisant996.github.io/clink/clink.html) (v1.2.30+) with Cmd. Create a file at this path `%LocalAppData%\clink\starship.lua` with the following contents:
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)
### پێشمەرجەکان
Head over to the [Chocolatey installation page](https://chocolatey.org/install) and follow the instructions to install Chocolatey.
### Installation
```powershell
chocoinstallstarship
```
## [termux](https://termux.com)
### پێشمەرجەکان
```sh
pkg install getconf
```
### Installation
```sh
curl -sS https://starship.rs/install.sh | sh -s -- --bin-dir /data/data/com.termux/files/usr/bin
```
## [Funtoo Linux](https://www.funtoo.org/Welcome)
### Installation
On Funtoo Linux, starship can be installed from [core-kit](https://github.com/funtoo/core-kit/tree/1.4-release/app-shells/starship) via Portage:
```sh
emerge app-shells/starship
```
## [Nix](https://nixos.wiki/wiki/Nix)
### Getting the Binary
#### Imperatively
```sh
nix-env -iA nixos.starship
```
#### Declarative, single user, via [home-manager](https://github.com/nix-community/home-manager)
Enable the `programs.starship` module in your `home.nix` file, and add your settings
```nix
{
programs.starship={
enable=true;
# Configuration written to ~/.config/starship.toml
settings={
# add_newline = false;
# character = {
# success_symbol = "[➜](bold green)";
# error_symbol = "[➜](bold red)";
# };
# package.disabled = true;
};
};
}
```
then run
```sh
home-manager switch
```
#### Declarative, system-wide, with NixOS
Add `pkgs.starship` to `environment.systemPackages` in your `configuration.nix`, then run
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:
This preset changes the format of all the built-in modules to show their segment in brackets instead of using the default Starship wording ("via", "on", etc.).
[](./bracketed-segments)
## [هێما نووسینەکییە ئاساییەکان](./plain-text.md)
This preset changes the symbols for each module into plain text. Great if you don't have access to Unicode.
[](./plain-text)
[](./no-runtimes)
## [Pure Prompt](./pure-preset.md)
ئەم پێش ڕێکخستنە لاسایی شێواز و ڕەفتاری [Pure](https://github.com/sindresorhus/pure) دەکاتەوە.
[](./pure-preset)
## [Pastel Powerline](./pastel-powerline.md)
This preset is inspired by [M365Princess](https://github.com/JanDeDobbeleer/oh-my-posh/blob/main/themes/M365Princess.omp.json). It also shows how path substitution works in starship.
[](./pastel-powerline)
[Return to Presets](./README.md#bracketed-segments)
# Bracketed Segments Preset
This preset changes the format of all the built-in modules to show their segment in brackets instead of using the default Starship wording ("via", "on", etc.).
This preset is inspired by [M365Princess](https://github.com/JanDeDobbeleer/oh-my-posh/blob/main/themes/M365Princess.omp.json). It also shows how path substitution works in starship.
### پێشمەرجەکان
- A [Nerd Font](https://www.nerdfonts.com/) installed and enabled in your terminal (the example uses Caskaydia Cove Nerd Font)
### ڕێکخستن
[Click to download TOML](/presets/toml/pastel-powerline.toml)
tagline: Minimale, super schnelle und unendlich anpassbare Prompt für jede Shell!
actionText: Loslegen →
actionLink: /guide/
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 deine 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! Sie zeigt die Information, die man benötigt an, während sie schnell und minimal bleibt. Quick installation available for Bash, Fish, ZSH, Ion, Tcsh, Elvish, Nu, Xonsh, Cmd, and PowerShell.
---
<div class="features">
<div class="feature">
<h2>Kompatibel</h2>
<p>Läuft mit den beliebtesten Shells auf den beliebtesten Betriebssystemen. Überall einsetzbar!</p>
</div>
<div class="feature">
<h2>Antrieben von Rust</h2>
<p>Bringt die branchenweit beste Geschwindigkeit und Sicherheit von Rust mit, um Deine Eingaben so schnell und zuverlässig wie nur möglich zu machen.</p>
</div>
<div class="feature">
<h2>Individualisierbar</h2>
<p>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.</p>
- Eine [Nerd Font](https://www.nerdfonts.com/) installiert und aktiviert in Ihrem Terminal.
### Schnellinstallation
1. Installiere die Binärversion von **starship**:
**[Lade die vorkompilierte Binärversion herunter](https://github.com/starship/starship/releases)**, wenn du keine der unten gelisteten Plattformen verwendest.
#### Neueste Version installieren
#### Homebrew
Mit Shell:
```sh
$ brew install starship
curl -sS https://starship.rs/install.sh | sh
```
Um Starship selbst zu aktualisieren, lasse das Skript oben nochmal laufen. Es wird die vorhandene Version ersetzen, ohne die Konfiguration von Starship zu berühren.
#### Rust (v1.38 oder neuer)
#### Installation mithilfe eines Paket-Managers
Mit [Homebrew](https://brew.sh/):
```sh
$ cargo install starship
brew install starship
```
Mit [scoop](https://scoop.sh):
#### Arch Linux (AUR)
Starship ist via AUR unter dem Namen `starship` verfügbar. Installiere es mittels `yay` oder einem AUR-Helfer deiner Wahl.
```sh
$ yay -S starship
```powershell
scoop install starship
```
#### Nix (instabil)
```sh
$ nix-env --install starship
```
#### Termux
```sh
$ pkg install starship
```
1. Füge das init-Skript zur Konfigurationsdatei deiner Shell hinzu:
Trage folgendes in das Powershell-Profil ($Profile) ein. Standardmäßig gespeichert unter:`~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` auf Windows, oder `~/.config/powershell/Microsoft.PowerShell_profile.ps1` auf -Nix:
Füge das folgende zum Ende von `Microsoft.PowerShell_profile.ps1` hinzu. Sie können den Speicherort dieser Datei überprüfen, indem Sie die `$PROFILE` Variable in PowerShell abfragen. Normalerweise ist der Pfad`~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` oder `~/.config/powershell/Microsoft.PowerShell_profile.ps1` auf -Nix.
```sh
# notepad $PROFILE
# ~\Documents\PowerShell\Profile.ps1
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.18 or higher is supported.
:::
Trage folgendes am Ende von `~/.config/fish/rc.elv` ein:
```sh
# ~/.elvish/rc.elv
eval (starship init elvish)
```
#### Tcsh
Trage folgendes am Ende von `~/.bashrc` ein:
```sh
# ~/.tcshrc
eval `starship init tcsh`
```
#### Nushell
::: warning
This will change in the future. Only Nushell v0.61+ is supported.
:::
Add the following to to the end of your Nushell env file (find it by running `$nu.env-path` in Nushell):
```sh
mkdir ~/.cache/starship
starship init nu | save ~/.cache/starship/init.nu
```
And add the following to the end of your Nushell configuration (find it by running `$nu.config-path`):
```sh
source ~/.cache/starship/init.nu
```
#### Xonsh
Füge folgendes an das Ende von `~/.xonshrc` hinzu:
```sh
# ~/.xonshrc
execx($(starship init xonsh))
```
#### ⌘ Cmd
You need to use [Clink](https://chrisant996.github.io/clink/clink.html) (v1.2.30+) with Cmd. Add the following to a file `starship.lua` and place this file in Clink scripts directory:
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
::: warning
Die hier beschriebenen Konfigurationen werden sich mit kommenden Updates von Starship verändern.
:::
## Custom pre-prompt and pre-execution Commands in Cmd
Clink provides extremely flexible APIs to run pre-prompt and pre-exec commands in Cmd shell. It is fairly simple to use with Starship. Make the following changes to your `starship.lua` file as per your requirements:
- To run a custom function right before the prompt is drawn, define a new function called `starship_preprompt_user_func`. This function receives the current prompt as a string that you can utilize. For example, to draw a rocket before the prompt, you would do
```lua
function starship_preprompt_user_func(prompt)
print("🚀")
end
load(io.popen('starship init cmd'):read("*a"))()
```
- To run a custom function right before a command is executed, define a new function called `starship_precmd_user_func`. This function receives the current commandline as a string that you can utilize. For example, to print the command that's about to be executed, you would do
```lua
function starship_precmd_user_func(line)
print("Executing: "..line)
end
load(io.popen('starship init cmd'):read("*a"))()
```
## 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:
@@ -21,19 +45,33 @@ function blastoff(){
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.
- 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.
## Custom pre-prompt and pre-execution Commands in PowerShell
PowerShell does not have a formal preexec/precmd framework like most other shells. Because of this, it is difficult to provide fully customizable hooks in `powershell`. Starship bietet daher die begrenzte Möglichkeit, eigene Funktionen in das prompt rendering Verfahren einzufügen:
Create a function named `Invoke-Starship-PreCommand`
```powershell
function Invoke-Starship-PreCommand {
$host.ui.Write("🚀")
}
```
## Fenstertitel anpassen
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.
Some shell prompts will automatically change the window title for you (e.g. to reflect your working directory). Fish ist standardmäßig so konfiguriert. Starship does not do this, but it's fairly straightforward to add this functionality to`bash`,`zsh`, `cmd` or `powershell`.
Zuerst wird eine Funktion definiert um den Fenstertitel zu ändern ( für bash und zsh ist die Funktion identisch):
@@ -57,28 +95,109 @@ Füge dies in `Zsh` zum `precmd_functions`-Array hinzu:
precmd_functions+=(set_win_title)
```
Um die Funktion dauerhaft zu machen, schreiben Sie diese in die Shell-Konfigurationsdatei: (`~/.bashrc` oder `~/.zsrhc`).
If you like the result, add these lines to your shell configuration file (`~/.bashrc` or `~/.zshrc`) to make it permanent.
Zum Beispiel, wenn sie ihr aktuelles Verzeichnis als Terminal Title anzeigen wollen, fügen Sie folgenden Code-Schnipsel zu ihrer `~/.bashrc` oder `~/.zshrc` hinzu:
```bash
function set_win_title(){
echo -ne "\033]0; $(basename "$PWD") \007"
}
starship_precmd_user_func="set_win_title"
```
For Cmd, you can change the window title using the `starship_preprompt_user_func` function.
Some shells support a right prompt which renders on the same line as the input. Starship can set the content of the right prompt using the `right_format` option. Any module that can be used in `format` is also supported in `right_format`. The `$all` variable will only contain modules not explicitly used in either `format` or `right_format`.
Note: The right prompt is a single line following the input location. To right align modules above the input line in a multi-line prompt, see the [`fill` module](/config/#fill).
`right_format` is currently supported for the following shells: elvish, fish, zsh, xonsh, cmd.
### Beispiel
```toml
# ~/.config/starship.toml
# A minimal left prompt
format = """$character"""
# move the rest of the prompt to the right
right_format = """$all"""
```
Produces a prompt like the following:
```
▶ starship on rprompt [!] is 📦 v0.57.0 via 🦀 v1.54.0 took 17s
```
## Fortsetzungsprompt
Einige Shells unterstützen einen speziellen Fortsetzungsprompt zusätzlich zum normalen Prompt. Dieser Prompt wird anstelle des normalen Prompts ausgegeben, wenn der Benutzer ein unvollständiges Kommando eingegeben hat (etwa wie eine einzelne linke Klammer oder ein einzelnes Anführungszeichen).
Starship kann das Aussehen des Fortsetzungs-Prompts mit der `continuation_prompt` Option einstellen. The default prompt is `"[∙](bright-black) "`.
Hinweis: Die `continuation_prompt` Anweisung sollte auf einen literalen String ohne Variablen gesetzt werden.
Hinweis: Fortsetzungs-Prompts sind nur für folgende Shells verfügbar:
- `bash`
- `zsh`
- `PowerShell`
### Beispiel
```toml
# ~/.config/starship.toml
# Ein Fortsetzungs-Prompt der 2 ausgefüllte Pfeile darstellt
continuation_prompt = "▶▶"
```
## 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). Jedes Wort kann eines der folgenden sein:
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`
- `bold`
- `italic`
- `underline`
- `dimmed`
- `invertiert`
- `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. Die Reihenfolge der Wörter in der Zeichenkette spielt keine Rolle.
wobei`<color>`eine Farbspezifikation ist (siehe unten). `fg:<color>`und `<color>`tun derzeit dasselbe, das kann sich in Zukunft aber ändern. `inverted` tauscht Hinter- und Vordergrundfarben. Die Reihenfolge der Wörter in der Liste spielt keine Rolle.
The `none`token overrides all other tokens in a string, so that e.g. `fg:red none fg:blue` will still create a string with no styling. It may become an error to use `none` in conjunction with other tokens in the future.
`none`überschreibt alle anderen Tokens in einem String wenn es nicht ein Teil einer `bg:` Zeichenkette ist, so dass z.B. über die Zeichenkette `fg:red none fg:blue` kein Styling mehr anzeigt wird. `bg:none` setzt den Hintergrund auf die Standardfarbe, so `fg:red bg:none` entspricht `rot` oder `fg:red` und `bg:green fg:red bg:none` entspricht auch `fg:red` oder `rot`. In der Zukunft könnte die Unterstützung von `none` in Verbindung mit anderen Tokens fallen gelassen werden.
A color specifier can be one of the following:
Eine Farbspezifikation kann wie folgt aussehen:
- 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`).
- Eine `#` gefolgt von einer sechsstelligen Hexadezimalnummer. This specifies an [RGB color hex code](https://www.w3schools.com/colors/colors_hexadecimal.asp).
- Eine Zahl zwischen 0-255. This specifies an [8-bit ANSI Color Code](https://i.stack.imgur.com/KTSQa.png).
- 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`).
- 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).
If multiple colors are specified for foreground/background, the last one in the string will take priority.
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
## Die Dokumentation sagt, dass die Starship interkompatibel ist. Warum wird meine bevorzugte Shell nicht unterstützt?
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`
Die [Bash Implementation](https://github.com/starship/starship/blob/master/src/init/starship.bash) ist etwas komplexer, um erweiterte Funktionen wie das [Befehlsdauer-Modul](https://starship.rs/config/#command-duration) zu ermöglichen und um sicherzustellen, dass Starship mit vorinstallierten Bash Konfigurationen kompatibel ist.
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`:
```sh
curl -sS https://starship.rs/install.sh | sh -s -- --platform unknown-linux-musl
```
## Why do I see `Executing command "..." timed out.` warnings?
Starship executes different commands to get information to display in the prompt, for example the version of a program or the current git status. To make sure starship doesn't hang while trying to execute these commands we set a time limit, if a command takes longer than this limit starship will stop the execution of the command and output the above warning, this is expected behaviour. This time limit is configurable using the [`command_timeout`key](/config/#prompt) so if you want you can increase the time limit. You can also follow the debugging steps below to see which command is being slow and see if you can optimise it. Finally you can set the `STARSHIP_LOG` env var to `error` to hide these warnings.
## 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.
## Starship is doing something unexpected, how can I debug it?
You can enable the debug logs by using the `STARSHIP_LOG` env var. These logs can be very verbose so it is often useful to use the `module` command if you are trying to debug a particular module, for example, if you are trying to debug the `rust` module you could run the following command to get the trace logs and output from the module.
```sh
env STARSHIP_LOG=trace starship module rust
```
If starship is being slow you can try using the `timings` command to see if there is a particular module or command that to blame.
```sh
env STARSHIP_LOG=trace starship timings
```
This will output the trace log and a breakdown of all modules that either took more than 1ms to execute or produced some output.
Finally if you find a bug you can use the `bug-report` command to create a Github issue.
```sh
starship bug-report
```
## 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. Sie müssen sicherstellen, dass:
- Your locale is set to a UTF-8 value, like `de_DE.UTF-8` or `ja_JP.UTF-8`. Wenn `LC_ALL` kein UTF-8-Wert ist, [müssen Sie ihn ändern](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/).
Um Ihr System zu testen, führen Sie folgende Befehle in einem Terminal aus:
```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. Benutzer auf dem Discord können vielleicht helfen. 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)
## Wie deinstalliere ich Starship?
Starship ist genauso einfach zu deinstallieren wie zu installieren.
1. Remove any lines in your shell config (e.g. `~/.bashrc`) used to initialize Starship.
1. Löschen Sie die Starship-Binary.
If Starship was installed using a package manager, please refer to their docs for uninstallation instructions.
Wenn Starship mit Hilfe des Installationsscripts installiert wurde, entfernt der folgende Befehl Starship:
<p align="center"> Starship ist der leichtgewichtige, blitzschnelle und extrem anpassbare Prompt für jede Shell!<br /> Der Prompt zeigt dir alle Informationen die du für deine Arbeit brauchst ohne dich dabei zu stören. <p>
**Minimale, super schnelle und unendlich anpassbare Prompt für jede Shell!**
- **Schnell:** sie ist schnell –_sehr, sehr_ schnell! 🚀
- **Konfigurierbar:** konfiguriere jedes Detail der Prompt.
- **Universal:** funktioniert mit jeder Shell, auf jedem Betriebssystem.
- **Intelligent:** zeigt relevante Informationen auf einen Blick.
- **Funktionsreich:** unterstützt alle deine Lieblingswerkzeuge.
- **Einfach:** schnell zu installieren – Betriebsbereit in nur wenigen Minuten.
<p align="center">
<br>
<img alt="Starship mit iTem2 und dem Theme „Snazzy“" src="https://raw.githubusercontent.com/starship/starship/master/media/demo.gif" width="80%">
<br>
<br>
<a href="https://starship.rs/config/"><strong>Schau dir die Starship-Dokumentation an ▶</strong></a>
</p>
## 🍬 Features
- Anzeigetext wird rot wenn der letzte Befehl mit einem Exit-code größer null terminiert
- Benutzername, wenn dieser nicht dem angemeldeten Benutzer entspricht
- Derzeitige Java-Version (`☕`)
- Derzeitige Node.js-Version (`⬢`)
- Derzeitige Rust-Version (`🦀`)
- Derzeitige Ruby-Version (`💎`)
- Derzeitige Python-Version (`🐍`)
- Derzeitige Go-Version (`🐹`)
- Erkennung von Nix-Shell-Umgebungen
- Ausgabe von Umgebungsvariablen
- Version des Paketmanagers im derzeitigen Pfad (`📦`)
- npm (Node.js)
- cargo (Rust)
- poetry (Python)
- Batteriestand und -status
- Aktueller Git-Branch und ausführlicher Repository-Status:
- `=` — konkurrierende Änderungen
- `⇡` — vor remote branch
- `⇣` — hinter remote branch
- `⇕` — abweichende Änderungen
- `?` — ungespeicherte Änderungen
- `$` — gestashte Änderungen
- `!` — veränderte Dateien
- `+` — hinzugefügte Dateien
- `»` — umbenannte Dateien
- `✘` — gelöschte Dateien
- Laufzeit des zuletzt ausgeführten Befehls, wenn sie länger als der gesetzte Schwellenwert ist
- Anzeige für Hintergrundsprozesse (`✦`)
- Aktueller Kubernetes Cluster und Namespace (`☸`)
- Aktuelles AWS Profil (`☁️`)
<a name="🚀-installation"></a>
## 🚀 Installation
### Voraussetzungen
- Eine [Powerline-Schriftart](https://github.com/powerline/fonts) installiert und in deinem Terminal aktiviert (z.B. [Fira Code](https://github.com/tonsky/FiraCode)).
- 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
### Schritt 1. Installiere Starship
1. Installiere die Binärversion von **starship**:
Wähle dein Betriebssystem aus der Liste für detaillierte Installationsanweisungen:
**[Lade die vorkompilierte Binärversion herunter](https://github.com/starship/starship/releases)**, wenn du keine der unten gelisteten Plattformen verwendest.
<details>
<summary>Android</summary>
Install Starship using any of the following package managers:
### Schritt 2. Richte deine Shell für die Nutzung von Starship ein
eval "$(starship init bash)"
```
Konfigurieren deine Shell um Starship zu initialisieren. Wähle dafür deine Shell aus der Liste aus:
<details>
<summary>Bash</summary>
#### Fish
Füge dies ans Ende von `~/.bashrc`:
Trage folgendes am Ende der `~/.config/fish/config.fish` ein:
```sh
eval "$(starship init bash)"
```
```sh
# ~/.config/fish/config.fish
</details>
starship init fish | source
```
<details>
<summary>⌘ Cmd</summary>
You need to use [Clink](https://chrisant996.github.io/clink/clink.html) (v1.2.30+) with Cmd. Create a file at this path `%LocalAppData%\clink\starship.lua` with the following contents:
#### Zsh
```lua
load(io.popen('starship init cmd'):read("*a"))()
```
Trage folgendes am Ende der `~/.zshrc` ein:
</details>
```sh
# ~/.zshrc
<details>
<summary>Elvish</summary>
eval "$(starship init zsh)"
```
Trage folgendes am Ende von `~/.config/fish/rc.elv` ein:
```sh
eval (starship init elvish)
```
#### Powershell
Note: Only Elvish v0.18+ is supported
Trage folgendes am Ende der `~\Documents\PowerShell\Microsoft.PowerShell_profile.ps1` (oder `~/.config/powershell/Microsoft.PowerShell_profile.ps1` auf -Nix) ein:
</details>
```sh
# ~\Documents\PowerShell\Profile.ps1
Invoke-Expression (&starship init powershell)
```
<details>
<summary>Fish</summary>
## 🔧 Konfiguration
Trage folgendes am Ende der `~/.config/fish/config.fish` ein:
Weitere Informationen zur Konfiguration von Starship findest du in unserer [Dokumentation](https://starship.rs/config/).
```fish
starship init fish | source
```
</details>
<details>
<summary>Ion</summary>
Trage folgendes am Ende der `~/.config/ion/initrc` ein:
```sh
eval $(starship init ion)
```
</details>
<details>
<summary>Nushell</summary>
Add the following to the end of your Nushell env file (find it by running `$nu.env-path` in Nushell):
```sh
mkdir ~/.cache/starship
starship init nu | save ~/.cache/starship/init.nu
```
And add the following to the end of your Nushell configuration (find it by running `$nu.config-path`):
```sh
source ~/.cache/starship/init.nu
```
Note: Only Nushell v0.61+ is supported
</details>
<details>
<summary>PowerShell</summary>
Add the following to the end of your PowerShell configuration (find it by running `$PROFILE`):
```powershell
Invoke-Expression (&starship init powershell)
```
</details>
<details>
<summary>Tcsh</summary>
Trage folgendes am Ende von `~/.bashrc` ein:
```sh
eval `starship init tcsh`
```
</details>
<details>
<summary>Xonsh</summary>
Füge folgendes an das Ende von `~/.xonshrc` hinzu:
```python
execx($(starship init xonsh))
```
</details>
<details>
<summary>Zsh</summary>
Füge dies ans Ende von `~/.zshrc`:
```sh
eval "$(starship init zsh)"
```
</details>
### Schritt 3. Starship konfigurieren
Starte eine neue Shell, um deinen neuen und schönen Prompt zu sehen. Wenn du mit den Defaults zufrieden bist, bist du bereits fertig!
Falls du Starship weiter anpassen möchtest:
- **[Konfiguration](https://starship.rs/config/)** - Lerne, wie du Starship deinen Bedürfnissen nach anpassen kannst
- **[Voreinstellungen](https://starship.rs/presets/)** - lasse dich von vorgefertigter Konfigurationen anderer Benutzenden inspirieren
## 🤝 Mitwirken
Wir sind immer auf der Suche nach Helfern**jeder Erfahrungsstufe**! Probleme mit dem Label [„Good first issues“](https://github.com/starship/starship/labels/🌱%20good%20first%20issue) sind der beste Weg, um dich mit dem Projekt vertraut zu machen.
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).
### Hohe Priorität
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/).
- 👩💼 **Produktmanager**
- Wir haben ein GitHub Projekt und viele unorganisierte/-priorisierte Features sowohl in Entwicklung als auch in Planung. Starship braucht jemanden, der die weitere Richtung vorgibt!
- 👩🎨 **Designer**
- Erstellst du gerne schillernde Webseiten? Großartig! Wir wollen eine astreine Homepage, die Starship in all ihrer Glorie preißt. Starships Markendesign zu unterstützen ist ein guter Ort um neue Ideen auszuprobieren!
- 👩💻 **Rust-Entwickler**
- Es gibt _so einige_ einfache Gelegenheiten für idiomatischen Rust code, das Designen effektiver Rust Architektur, Performanzoptimierung, plattformübergreifende Build-Optimierungen und vieles mehr! Ich ([@matchai](https://github.com/matchai)) bin neu in Rust. Zeig uns den richtigen Weg!
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. 👋
### Mitwirkende
Danke an diese wunderbaren Leute ([emoji-Schlüssel](https://allcontributors.org/docs/en/emoji-key)):
<!-- ALL-CONTRIBUTORS-LIST:START - Do not remove or modify this section -->
Dieses Projekt folgt der [all-contributors](https://github.com/all-contributors/all-contributors)-Spezifikation. Beiträge jeglicher Art sind herzlich willkommen!
Falls du an Starship mitwirken willst, wirf bitte einen Blick auf den [Contributing Guide](https://github.com/starship/starship/blob/master/CONTRIBUTING.md). Schau auch gerne auf unserem [Discord server](https://discord.gg/8Jzqu3T) vorbei. 👋
## 💭 Inspiriert durch
Bitte schaue dir diese früheren Projekte an, die dazu beigetragen haben, Starship zu kreieren. 🙏
Checkt bitte diese älteren Projekte, die das Entstehen von Starhip inspiriert haben. 🙏
- **[denysdovhan/spaceship-prompt](https://github.com/denysdovhan/spaceship-prompt)** - Ein ZSH-Prompt für Astronauten.
- **[denysdovhan/spaceship-prompt](https://github.com/denysdovhan/spaceship-prompt)** – A ZSH prompt for astronauts.
- **[denysdovhan/robbyrussell-node](https://github.com/denysdovhan/robbyrussell-node)** - Ein Shell-übergreifendes und in JavaScript geschriebenes robbyrussell-Theme.
- **[denysdovhan/robbyrussell-node](https://github.com/denysdovhan/robbyrussell-node)** – Cross-shell robbyrussell theme written in JavaScript.
- **[reujab/silver](https://github.com/reujab/silver)** - Shell-übergreifendes, anpassbares und Powerline-ähnliches Prompt mit Symbolen.
- **[reujab/silver](https://github.com/reujab/silver)** – A cross-shell customizable powerline-like prompt with icons.
Um Starship zu installieren, musst du zwei Dinge tun:
1. Holen Sie sich das **starship** Binary auf Ihren Computer
1. Sagen Sie ihrer Shell, dass sie das Starship-Binary als Prompt benutzt, indem sie die Initialisierungs-Skripte ändern
Die Anweisungen auf [der Hauptseite](/guide/#🚀-installation) werden für die meisten Benutzer gut funktionieren. Für einige speziellere Plattformen werden jedoch andere Anweisungen benötigt.
Es gibt so viele Plattformen, dass sie nicht in das Haupt-README passen, also hier einige Installationsanweisungen für andere Plattformen von der Community. Ist Ihre nicht hier? Bitte fügen Sie es hier hinzu, wenn Sie es herausfinden!
## [Chocolatey](https://chocolatey.org)
### Voraussetzungen
Gehen Sie zur [Chocolatey's Installations-Seite](https://chocolatey.org/install) und folge den Anweisungen um Chocolatey zu installieren.
### Installation
```powershell
choco install starship
```
## [termux](https://termux.com)
### Voraussetzungen
```sh
pkg install getconf
```
### Installation
```sh
curl -sS https://starship.rs/install.sh | sh -s -- --bin-dir /data/data/com.termux/files/usr/bin
```
## [Funtoo Linux](https://www.funtoo.org/Welcome)
### Installation
On Funtoo Linux, starship can be installed from [core-kit](https://github.com/funtoo/core-kit/tree/1.4-release/app-shells/starship) via Portage:
```sh
emerge app-shells/starship
```
## [Nix](https://nixos.wiki/wiki/Nix)
### Das Binary holen
#### Imperativ
```sh
nix-env -iA nixos.starship
```
#### Deklarativ, Einzel-Benutzer, über [home-manager](https://github.com/nix-community/home-manager)
Aktivieren Sie das Modul `programs.starship` in Ihrer `home.nix`-Datei und fügen Sie Ihre Einstellungen hinzu
```nix
{
programs.starship = {
enable = true;
# Configuration written to ~/.config/starship.toml
settings = {
# add_newline = false;
# character = {
# success_symbol = "[➜](bold green)";
# error_symbol = "[➜](bold red)";
# };
# package.disabled = true;
};
};
}
```
und führen Sie dann folgendes aus
```sh
home-manager switch
```
#### Deklarativ, systemweit, mit NixOS
Fügen Sie `pkgs.starship` zu `environment.systemPackages` in Ihrer `configuration.nix` hinzu, und führen Sie folgendes aus
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! 😊
To get details on how to use a preset, simply click on the image.
## [Nerd Font Symbole](./nerd-font.md)
This preset changes the symbols for each module to use Nerd Font symbols.
[](./nerd-font)
## [Bracketed Segments](./bracketed-segments.md)
This preset changes the format of all the built-in modules to show their segment in brackets instead of using the default Starship wording ("via", "on", etc.).
[](./bracketed-segments)
## [Plain Text Symbols](./plain-text.md)
This preset changes the symbols for each module into plain text. Great if you don't have access to Unicode.
[](./plain-text)
## [No Runtime Versions](./no-runtimes.md)
This preset hides the version of language runtimes. If you work in containers or virtualized environments, this one is for you!
[](./no-runtimes)
## [Pure Prompt](./pure-preset.md)
This preset emulates the look and behavior of [Pure](https://github.com/sindresorhus/pure).
[](./pure-preset)
## [Pastel Powerline](./pastel-powerline.md)
This preset is inspired by [M365Princess](https://github.com/JanDeDobbeleer/oh-my-posh/blob/main/themes/M365Princess.omp.json). It also shows how path substitution works in starship.
[](./pastel-powerline)
[Return to Presets](./README.md#bracketed-segments)
# Bracketed Segments Preset
This preset changes the format of all the built-in modules to show their segment in brackets instead of using the default Starship wording ("via", "on", etc.).
### Konfiguration
[Click to download TOML](/presets/toml/bracketed-segments.toml)
This preset is inspired by [M365Princess](https://github.com/JanDeDobbeleer/oh-my-posh/blob/main/themes/M365Princess.omp.json). It also shows how path substitution works in starship.
### Voraussetzungen
- A [Nerd Font](https://www.nerdfonts.com/) installed and enabled in your terminal (the example uses Caskaydia Cove Nerd Font)
### Konfiguration
[Click to download TOML](/presets/toml/pastel-powerline.toml)
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, Tcsh, Elvish, Nu, Xonsh, Cmd, y PowerShell.'
- Una [Nerd Font](https://www.nerdfonts.com/) instalada y habilitada en tu terminal.
### Instalación rápida
1. Instala el binario de **Starship**:
#### Instalar la última versión
Con el intérprete de comandos:
```sh
curl -sS https://starship.rs/install.sh | sh
```
Para actualizar Starship, vuelve a ejecutar el guión anterior. Reemplazará la versión actual sin tocar la configuración de Starship.
#### Instalar vía un gestor de paquetes
Con [Homebew](https://brew.sh/):
```sh
brew install starship
```
Con [Scoop](https://scoop.sh):
```powershell
scoop install starship
```
1. Añade el guión de inicio al archivo de configuración de tu intérprete de comandos:
#### Bash
Añade la siguiente línea 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
::: warning
Sólo se admite elvish v0.18 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`
```
#### Nushell
::: warning
Esto cambiará en el futuro. Sólo se admite Nushell v0.61+.
:::
Añade lo siguiente al final de tu archivo Nushell env (encuéntralo ejecutando `$nu.env-path` en Nushell):
```sh
mkdir ~/.cache/starship
starship init nu | save ~/.cache/starship/init.nu
```
Añade lo siguiente al final de tu configuración de Nushell (encuéntrala ejecutando `$nu.config-path`):
```sh
source ~/.cache/starship/init.nu
```
#### Xonsh
Añade lo siguiente al final de `~/.xonshrc`:
```sh
# ~/.xonshrc
execx($(starship init xonsh))
```
#### Cmd
Necesitas usar [Clink](https://chrisant996.github.io/clink/clink.html) (v1.2.30+) con Cmd. Añade lo siguiente a un archivo `starship.lua` y coloca este archivo en el directorio de scripts de Clink:
```lua
-- starship.lua
load(io.popen('starship init cmd'):read("*a"))()
```
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
