When depending on a Git repository (as you do with your colored dependency), it is a good practice to point to a particular commit or tag using the rev or tag parameter instead of the branch, as the branch’s HEAD can change but a commit or tag can only point to only one specific state of the repository.
When publishing a binary (executable) crate, it is a good practice to publish along the crate the Cargo.lock. You can find the reasoning on why you should publish this file in Cargo’s FAQ
I will try it later though! I always complained that some prompt frameworks are using scripting languages like Python or Ruby that have slow spin-up rate, so this project seems interesting and a cool way to customize my ugly and boring prompt.
You kind of cover this but the Cargo.lock would capture the commit that the git dependency was at when the lock file was generated. So if the Cargo.lock was checked in everyone would build against the same commit.
Try PS1='$(pista)'. What’s happening is that pista is getting called once, when you set PS1, and then never again. The single quotes force PS1 to literally contain the expansion, which then gets expanded (and thereby call pista) each time the prompt is printed
This seems really cool, and I’m excited to try it out. I’m interesting in sending a PR adding a NixOS package for it, but unfortunately it doesn’t have a license.
Is there a possibility of the project having an open-source license in the future? My guess this will be required for the package to be considered “free” within package manager standards.
i dont have a concrete benchmark, but pista would definitely be faster, its a compiled binary. a shell implementation would have to have atleast 2 external git calls, 1 dir call, and maybe some sed calls to parse output; to produce a similar prompt.
pista directly uses libgit2 to fetch git statuses, so the amount of parsing, string building etc. is reduced.
edit: a quick bench with time shows that pista takes 0.011s to render the prompt whereas a similar prompt written in shell takes 0.032s.
the time difference is negligible even though pista runs 3 times as fast. note that the shell implementation does not have customization, zsh compatibility, vitrual env support etc.
Why do you even need to incorporate external binaries to display your prompt in shell, calling it “simple”?
If you want to do a prompt for Bash, do it in Bash, or even a regular POSIX shell.
If you want to do a prompt in Rust, make a shell in Rust. Many people would seriously appreciate that and I’ll probably throw donations in such project like crazy, especially if it brings these famous Rust performance factors into the world of regular shells.
it looks like simple here is giving the wrong idea. by simple, i mean simple design. its a simple design compared to ‘powerline’ and ‘git status’ prompts that you find online.
compiling a 300 line program for your PS1 is certainly not simple, but i have to disagree with you on ‘If you want to do a prompt in Rust, make a shell in Rust’. a shell and its prompt have little to no relation, and its that lack of relation that makes bash beautiful!
I don’t think pedantics over who thinks what is simple or not are really that productive or useful, especially when someone’s showing off something they just made and are proud of. Simple is a subjective term, and subjectively I think this comment sucks.
Presumably I am being downvoted, but too early to see why. I assume “incorrect” or “troll.” In the case of “incorrect,” where correctness is subjective, I assume people mean that as disagree. :shrug:
This attitude is exactly what I think is wrong in this industry.
Yes, Some random person making a fat executable to reduce dynamic calls on their terminal prompt is what’s wrong with the industry. Carry on, white knight of software!
take a look at these popular ‘powerline’ prompts that throw tons of information at you. more often than not, you dont need to know how many files have changed in your current directory.
ill admit, building a 300 line program for your prompt is not simple at all!
I am glad you didn’t take offense with my comment, as it was not the intention. I am very much in favor of side projects and sharing work—thanks for sharing!
take a look at these popular ‘powerline’ prompts that throw tons of information at you.
I am aware of how crazy these things get. I do appreciate the attempt at reducing that complexity to a more manageable form.
as always, feel free to submit feedback, criticism or issues!
Just some nitpicking on dependencies:
coloreddependency), it is a good practice to point to a particular commit or tag using therevortagparameter instead of thebranch, as the branch’sHEADcan change but a commit or tag can only point to only one specific state of the repository.Cargo.lock. You can find the reasoning on why you should publish this file in Cargo’s FAQI will try it later though! I always complained that some prompt frameworks are using scripting languages like Python or Ruby that have slow spin-up rate, so this project seems interesting and a cool way to customize my ugly and boring prompt.
You kind of cover this but the Cargo.lock would capture the commit that the git dependency was at when the lock file was generated. So if the Cargo.lock was checked in everyone would build against the same commit.
I already implemented a similar tool some months ago rusty-prompt, maybe you can get some inspiration out of it.
sure! thanks for sharing!
My bashes (both the one that comes with Mac OS and the latest 5.0.7 from brew) seem to cache PS1 somehow, making pista break quite a lot.
Try
PS1='$(pista)'. What’s happening is that pista is getting called once, when you set PS1, and then never again. The single quotes force PS1 to literally contain the expansion, which then gets expanded (and thereby call pista) each time the prompt is printedOhhh, no :( Of course. I feel like I should step far away from the computer now.
looks like the installation instructions were faulty!
Oh, whew, thanks for that. Now I feel slightly less stupid :)
cant seem to replicate this, but it looks like a
PROMPT_COMMANDthing.@hostnameis nice to have if$SSH_CONNECTIONis set.i have plans to extend
pistainto a library, so you could build your own prompts withpista’s functions. maybe ill add a hostname function :^)This seems really cool, and I’m excited to try it out. I’m interesting in sending a PR adding a NixOS package for it, but unfortunately it doesn’t have a license.
Is there a possibility of the project having an open-source license in the future? My guess this will be required for the package to be considered “free” within package manager standards.
i didnt really expect this pet project to gain much traction. i will licence it under mit or gpl today!
Yay! Thank you so much <3
Looks cool, but just out of curiosity - what’s the performance of this versus a shell implementation?
i dont have a concrete benchmark, but pista would definitely be faster, its a compiled binary. a shell implementation would have to have atleast 2 external
gitcalls, 1dircall, and maybe somesedcalls to parse output; to produce a similar prompt.pistadirectly useslibgit2to fetch git statuses, so the amount of parsing, string building etc. is reduced.edit: a quick bench with
timeshows that pista takes 0.011s to render the prompt whereas a similar prompt written in shell takes 0.032s.the time difference is negligible even though pista runs 3 times as fast. note that the shell implementation does not have customization, zsh compatibility, vitrual env support etc.
Nice! Thats always been a sticking point for me with a Git prompt, to the point that I removed it. This looks worth trying a Git prompt again!
This looks neat, but installation failed :(
I assumed installing rust fresh would give me the latest version, but you also have to run
rustup updateafter installation.Why do you even need to incorporate external binaries to display your prompt in shell, calling it “simple”?
If you want to do a prompt for Bash, do it in Bash, or even a regular POSIX shell.
If you want to do a prompt in Rust, make a shell in Rust. Many people would seriously appreciate that and I’ll probably throw donations in such project like crazy, especially if it brings these famous Rust performance factors into the world of regular shells.
it looks like simple here is giving the wrong idea. by simple, i mean simple design. its a simple design compared to ‘powerline’ and ‘git status’ prompts that you find online.
compiling a 300 line program for your PS1 is certainly not simple, but i have to disagree with you on ‘If you want to do a prompt in Rust, make a shell in Rust’. a shell and its prompt have little to no relation, and its that lack of relation that makes bash beautiful!
See ion[0] the shell for Redox. it’s a shell in rust, for an OS written in rust.
0: https://gitlab.redox-os.org/redox-os/ion
[Comment removed by author]
I don’t think pedantics over who thinks what is simple or not are really that productive or useful, especially when someone’s showing off something they just made and are proud of. Simple is a subjective term, and subjectively I think this comment sucks.
[Comment removed by author]
Please do not use downvotes to disagree. There intentionally is not a “Disagree” reason.
Presumably I am being downvoted, but too early to see why. I assume “incorrect” or “troll.” In the case of “incorrect,” where correctness is subjective, I assume people mean that as disagree. :shrug:
Yes, Some random person making a fat executable to reduce dynamic calls on their terminal prompt is what’s wrong with the industry. Carry on, white knight of software!
Obviously not.
ah i feel you. by simple, i mean, simple design.
take a look at these popular ‘powerline’ prompts that throw tons of information at you. more often than not, you dont need to know how many files have changed in your current directory.
ill admit, building a 300 line program for your prompt is not simple at all!
I am glad you didn’t take offense with my comment, as it was not the intention. I am very much in favor of side projects and sharing work—thanks for sharing!
I am aware of how crazy these things get. I do appreciate the attempt at reducing that complexity to a more manageable form.