Live data from Hacker News

Command line tools for productive programmers

earthly.dev

31–40 of 143 posts

Re: Command line tools for productive programmers

#31
post #26
post #19

Brains recently got underrated. The way mcfly works is cool, but it offloads your habits to some “neural network” that you can’t control. There is not many methods slower than looking at unpredictable line-by-line output and almost nothing more anxious than a possibility of false choice done without thinking. This tool basically replaces a deterministic mismatch with a non-deterministic one. Your brain is good at pre…

> history-search-{for,back}ward in their .inputrc for up-down keys Once I found this, I rarely use Ctrl+R since most of the time I'm searching based on starting command name. If I'm using something a lot of times, it gets added as alias/function. I also maintain a file with commands that I think may be useful later, easier to search that compared to online search.

a file with commands

Yes! I have OBTF with all “devops/etc” stuff that is hard to remember once a quarter, with headers and explanations, and everything in select-paste ready format.

Re: Command line tools for productive programmers

#32
post #20

Earlier quoted context omitted.

Does it contain emacs? That would be nice.

What would be nice about that?

You could edit files that you just found and renamed. And when you edit files, then there is RCS integration and… linting, spellcheck, printing, you name it. It’s just a unix way. Is broot ISO/IEC 9945:2009 compliant?

/s

Re: Command line tools for productive programmers

#33

I think productive programmers would get way further by learning powerful scripting and one liners than picking different pre existing binaries. Its a little oldschool but pipe is the most powerful concept on the command line and it’s wildly productive

Yes, I've found that the most significant improvements for me came with bash aliases, a few little scripts, and nnn for anything that has to do with folder navigation or file browsing. Its search-based navigation speed is unmatched.

Another big upgrade was dmenu. Just slap it in some bash script and now it's interactive. Combined with xbindkeys you can even bind those menus to keys, and it'll work on any Xorg-based desktop.

Re: Command line tools for productive programmers

#34
post #20

Earlier quoted context omitted.

Use broot as tree is not necessary of course `tree | less` works for that but as hinted in the article broot contains a lot more features. Fuzzy finding, preview, multiwindow copy/paste, renaming, directory navigation etc

Does it contain emacs? That would be nice.

There's a broot alternative called lf that opens files in $EDITOR

https://github.com/gokcehan/lf

Re: Command line tools for productive programmers

#35
post #27
post #25

The one cli tool that saves me the most time is "gh", and its predecessor "hub". Not having to interact with a website to submit a PR, issue, or just fork a repo, is a blessing. I wish more sites would ship a cannonicla tool to use their APIs...

Re: forking a repo. How do you type name into the terminal?

I am not sure I understand your question. Can you rephrase?

Forking with gh is pretty simple:

Clone the repo, cd to it, "gh repo fork"

Re: Command line tools for productive programmers

#36
I can't sing the praises enough of entr. Just check out its man page: http://eradman.com/entrproject/

entr lets you watch files and re-run a command any time they change. Whenever I'm working on a script, or go tests, or whatever test-like thing I'm doing that's not in its own bloated test harness, I reach for entr. Great software, does what it's supposed to every time.

Re: Command line tools for productive programmers

#37
post #19

Brains recently got underrated. The way mcfly works is cool, but it offloads your habits to some “neural network” that you can’t control. There is not many methods slower than looking at unpredictable line-by-line output and almost nothing more anxious than a possibility of false choice done without thinking. This tool basically replaces a deterministic mismatch with a non-deterministic one. Your brain is good at pre…

I get a lot of milage out of

    alias h="history | fzy"
    alias f="fd | fzy"

Re: Command line tools for productive programmers

#38
post #8

For his usecase of funky i use ~/.bash_aliases, that way i can easily share them between machines. Eg to quickly add a new one: alias als="nvim $HOME/.bash_aliases && source $HOME/.bash_aliases" Be careful with quoting though, got myself into a situation where every new terminal asked for the root password. Shellcheck found the reason quickly. (edit) Another benefit is that those aliases abstract over differences of…

Instead of creating aliases for .., I use this: function ..() { for i in $(seq 1 $1); do cd ..; done } which enables .. # up 1 dir .. 2 # up 2 dirs .. 42 # up 42 dirs Here are some more: https://pilabor.com/blog/2021/03/unix-shell-tricks/

Clever. Never seen that idea before.

Re: Command line tools for productive programmers

#39
post #20

Earlier quoted context omitted.

Use broot as tree is not necessary of course `tree | less` works for that but as hinted in the article broot contains a lot more features. Fuzzy finding, preview, multiwindow copy/paste, renaming, directory navigation etc

Does it contain emacs? That would be nice.

What's wrong with dired mode? Ok, you'll get each directory in its own buffer. But, thinking of that, it shouldn't be to hard to make dired mode recurse into subdirectories inside the same buffer. (And fold/unfold like orgmode does. ;-)

Re: Command line tools for productive programmers

#40
Some interesting tips on this list (and in the comments). It’s definitely worth taking a step back every now and again and investing a little in picking up some newer tools for better workflows.

I recently switched to the latest neovim and redid my config from scratch using more modern plugins. Took a while to understand the ecosystem and figure out how to get things working together nicely. But now, between telescope, ripgrep, trouble and better overall LSP etc, I’ve gone from fast to faster.

The balance of payoff probably still isn’t there yet, but it’s made me want to code more.

Post reply on HN