Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disabling pink error code #543

Closed
atsaloli opened this issue Mar 16, 2018 · 8 comments
Closed

Disabling pink error code #543

atsaloli opened this issue Mar 16, 2018 · 8 comments
Milestone

Comments

@atsaloli
Copy link

Shell: bash
Operating system: RHEL 6
Liquid Prompt version (tag, commit): 9c80396 (2017-04-04)

Is there any way to disable the pink reporting of the exit status code of the last command when non-zero?

I looked in the config file and in the liquid.ps1 file but I didn't see anything... did I miss it, or where is it?

Thanks! Love the product. =)

@Rycieos
Copy link
Collaborator

Rycieos commented Mar 16, 2018

You would have to use a theme to change default colors. If you copy the default theme file, the line you are looking for is the LP_COLOR_ERR.

@augmentedfourth
Copy link
Contributor

@atsaloli If you want to get rid of the whole thing, you can comment out lines 1702-1707 in the main liquidprompt script. Even better, put a conditional around those lines and add a config parameter to turn it on/off, then send in a pull request. 😉

@atsaloli
Copy link
Author

Thanks, @augmentedfourth! It's a small world! =)

And thanks @Rycieos! =)

@nojhan
Copy link
Collaborator

nojhan commented Aug 18, 2018

For the records: there is no more need to comment out things in the main file, just set LP_ENABLE_ERR=0 in your config.

@augmentedfourth
Copy link
Contributor

@nojhan Was that added in another pull request? #544 was closed without merging due to @Rycieos stating that we shouldn't be adding new parameters like LP_ENABLE_ERR. The official solution was to take ${LP_ERR} out of the theme file rather than add the new .liquidpromptrc option.

@nojhan
Copy link
Collaborator

nojhan commented Aug 19, 2018

I was unaware of this discussion, I added the feature without a PR (I'm not even sure I can do a PR toward my own repo?). To avoid such mistake, this kind of thought should definitely be written down as comment in the code, we cannot expect contributors to read all closed PRs.
Additionally, if the config flags number is a problem, maybe it would be better to remove them entirely in favour of a cleaner LP_PS1_FILE system?

@Rycieos
Copy link
Collaborator

Rycieos commented Aug 20, 2018

@nojhan you can do a PR against your own repo; the benefit being other contributors can read and give suggestions before merging.

I agree that it would be better to have some sort of modular configuration system, where instead of checking configuration variables, each construction function was called only if it was wanted.

@Rycieos
Copy link
Collaborator

Rycieos commented Dec 9, 2020

This is fixed in v2.0.0-beta.1, which has a new config option: $LP_ENABLE_ERROR. See the link for documentation.

@Rycieos Rycieos closed this as completed Dec 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants