Live data from Hacker News

Mastering Bash and Terminal

blockloop.io

81–90 of 186 posts

Re: Mastering Bash and Terminal

#81
post #29

Personally, I found the following to be extremely easy and powerful. A no-brainer that should be a bash default really. if [ -t 1 ] then # search for commands that start off with the same characters already typed bind '"\e[A":history-search-backward' bind '"\e[B":history-search-forward' fi One of my friends also recommended version-controlling your config files and storing them on gitlab, which I'm only sad I didn't…

Yes! This is the first thing I do in a new Linux OS.

Also, the author does not mention hitting tab for autocomplete (or displaying the remaining options that match what has been typed so far).

Re: Mastering Bash and Terminal

#82
In the spirit of sharing: one of my favorite lines in my bashrc is the alias of `rm` to `rm -i`. This prompts for a confirmation. You might not need it but I deleted some important, not-yet-checked-in-git files in the past by accident.

If you want to delete everything and don't want to keep typing yes just do `yes | rm bla`.

Re: Mastering Bash and Terminal

#83
Rather than trying to remember all those commands for moving around in your command, I recommend turning on vim mode for the command line, and remapping ESC to "jk".

bindkey -v bindkey -M viins 'jk' vi-cmd-mode

Then you can edit your command line the same way you would edit a line in vim.

Re: Mastering Bash and Terminal

#84
post #68

I also assume you're using bash. I know there are some cool newcomers out there like zsh and fish While there is much useful in this post, I always find comments like this one odd. bash was released back in 1989, zsh was released one year later, in 1990. One year difference in age almost thirty years ago means that you can't really call zsh a newcomer. Maybe he's talking about adoption, though.

I was definitely talking about adoption ;-). See my comment https://news.ycombinator.com/item?id=13400707

Re: Mastering Bash and Terminal

#85

Rather than temporarily suspend vim to use the terminal you can get vim to suspend and resume itself with the exclamation mark command. This has the benefit of not wreaking havoc on your vim session and allowing you to read data into vim by prefixing with r. For example :!ls will execute ls and show you the result (press enter to return) :r!ls will read the result of ls in for you More usefully :r!sed -n5,10p that/ot…

You actually don't have to put ! In front of make. Vim has makefile integration. If all you're doing is typing make, you can do :make. For a custom build command, you can set the variable makeprg, and :make will execute that instead. On my phone so it's hard to type examples, this blog post gives more info:

https://jbernard.io/2011/09/30/vim-makeprg.html

Re: Mastering Bash and Terminal

#86
post #68

I also assume you're using bash. I know there are some cool newcomers out there like zsh and fish While there is much useful in this post, I always find comments like this one odd. bash was released back in 1989, zsh was released one year later, in 1990. One year difference in age almost thirty years ago means that you can't really call zsh a newcomer. Maybe he's talking about adoption, though.

bash is an extended clone of Bourne shell, though, and sh dates to 1977.

Re: Mastering Bash and Terminal

#87
post #72

Earlier quoted context omitted.

> :!make IMO, :make is (usually) better, because it adds errors to the quickfix list, and put your cursor on the first error location.

In all honesty, I've never actually done :!make (or :make) as I nearly always have it wrapped behind my own build scripts

You can set :make to execute your own build script instead of make, and you can also tell vim how to interpret the output. See e.g.:

https://vi.stackexchange.com/questions/6679/terminal-setup-w...

Re: Mastering Bash and Terminal

#88

bash (and shells in general) are so hacky (in a bad way) that I wouldn't want to waste my time mastering them. Whenever a shell script grows beyond 10 or 20 lines, I try to rewrite it in a "real" programming language. Fancy shell tricks are a code smell to me, and clarity and simplicity are of far greater importance. For me, as far as shells go it's usually enough to know the basics and be able to look stuff up when…

That might be a good reason to not write programs in shell, but it sounds like mastering the interactive features might still be worth the time.
Post reply on HN