Live data from Hacker News

Show HN: History suggest box for your shell

github.com

21–29 of 29 posts

Re: Show HN: History suggest box for your shell

#21
post #12

How is this different than reverse-i-search?

None. But seems like the trend of the last 10 years is to rewrite every single already existing Unix tool in Rust or node.js. Throwing out code is more fun than reading man pages I guess. This saddens me. It looks like the average dev in 2020 believes he needs to pollute his working environment with thousands of seemingly useless tools to be productive. fzf, silver searcher, ripgrep, etc. I will be downvoted to hell,…

I can easily give examples of using `fzf` or `ripgrep` to perform the same action in many less keystrokes than the built-in utilities would require, e.g., traversing a deep directory hierarchy using `fzf` to fuzzy search for the right directory to `cd` to, or performing a text search of only `git` included files over many repos.

Given these tasks are accomplishable in many less keystrokes using `rg` and `fzf` than the built-in utilities, how would you make the argument that you're able to accomplish these command line tasks faster using only "bash, vim, and coreutils"?

Re: Show HN: History suggest box for your shell

#22
post #12

How is this different than reverse-i-search?

None. But seems like the trend of the last 10 years is to rewrite every single already existing Unix tool in Rust or node.js. Throwing out code is more fun than reading man pages I guess. This saddens me. It looks like the average dev in 2020 believes he needs to pollute his working environment with thousands of seemingly useless tools to be productive. fzf, silver searcher, ripgrep, etc. I will be downvoted to hell,…

You’ve just picked an arbitrary point in the development of these tools that you’re happy with and are suggesting that any progress beyond that point is wasted. I’m sure there were folks around when bash development started saying that they were super productive in Bourne shell so why start a rewrite from scratch. Is vim the terminal point of editor development, forever? Why wasn’t it when nvi replaced Joy’s original vi? Why aren’t we still using ex?

All of the tools you mentioned started as rewrites of existing tools and only became better over time as they added features. That process hasn’t stopped.

Re: Show HN: History suggest box for your shell

#25
post #12

How is this different than reverse-i-search?

None. But seems like the trend of the last 10 years is to rewrite every single already existing Unix tool in Rust or node.js. Throwing out code is more fun than reading man pages I guess. This saddens me. It looks like the average dev in 2020 believes he needs to pollute his working environment with thousands of seemingly useless tools to be productive. fzf, silver searcher, ripgrep, etc. I will be downvoted to hell,…

Silver searcher and ripgrep can ignore git-ignored files very easily. Don’t know how to do that with grep.

Fzf gives you a list of hits that you can go through to select the one you want. Ctrl-r in bash just shows you the current hit.

Those are real advantages.

Re: Show HN: History suggest box for your shell

#26
post #12

Earlier quoted context omitted.

None. But seems like the trend of the last 10 years is to rewrite every single already existing Unix tool in Rust or node.js. Throwing out code is more fun than reading man pages I guess. This saddens me. It looks like the average dev in 2020 believes he needs to pollute his working environment with thousands of seemingly useless tools to be productive. fzf, silver searcher, ripgrep, etc. I will be downvoted to hell,…

You’ve just picked an arbitrary point in the development of these tools that you’re happy with and are suggesting that any progress beyond that point is wasted. I’m sure there were folks around when bash development started saying that they were super productive in Bourne shell so why start a rewrite from scratch. Is vim the terminal point of editor development, forever? Why wasn’t it when nvi replaced Joy’s original…

Well put. I got very good at typing:

    find . -type f -exec egrep -il "whatever" {} \;
and now I instead type:

    rg whatever
and, somehow, I feel like that's an improvement.

And it automatically ignores the directories like .git, build, node_modules, etc., whatever is in .gitignore, without having to add a bunch of "-prune" clauses.

Re: Show HN: History suggest box for your shell

#27

In case you didn't know, bash has a basic version of this already embedded. You can search your bash history from the command line with Control+R (not Cmd+R even for Macs).

Totally, but the dropdown the rest of the height of the terminal is the feature I'm appreciating here.

Re: Show HN: History suggest box for your shell

#28
post #8

This is pretty cool. I'm always mashing the up arrow, so I installed this in anticipation of making my life easier :) I didn't have `cargo` or any other rust language support installed. However, that seems pretty straight forward: https://www.rust-lang.org/tools/install You may want to throw that into the README. Anyhow, I'm running this on WSL2/Ubuntu 20.04 using zsh + ohmyzsh. It installs cleanly, and I just added…

If you want to keep your zshrc "clean" you can add any number of individual scripts to `~/.oh-my-zsh/custom` and they will be executed for every new shell.

Oh that's good to know. For someone my age, I have embarrassingly little knowledge of shell customization. I just looked in .zshrc and there was a comment to the effect of "Add your aliases below, e.g. ALIAS blah=foo" and so I listened to it!

Re: Show HN: History suggest box for your shell

#29
post #8

Earlier quoted context omitted.

If you want to keep your zshrc "clean" you can add any number of individual scripts to `~/.oh-my-zsh/custom` and they will be executed for every new shell.

Oh that's good to know. For someone my age, I have embarrassingly little knowledge of shell customization. I just looked in .zshrc and there was a comment to the effect of "Add your aliases below, e.g. ALIAS blah=foo" and so I listened to it!

There is nothing inherently wrong with putting them into .zshrc!

The reasons I keep them separate is because:

a) I can simply backup the `custom` directory and restore onto a "vanilla" oh-my-zsh installation b) I can use descriptive file names which would otherwise have to be comments

Also, some software likes to append stuff (like adding directories to PATH) to .zshrc upon installation so it gets kind of messy over time.

I guess the comment is from the plain zsh installation and oh-my-zsh just didn't remove it.

Post reply on HN