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.
