Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mastering Bash and Terminal

blockloop.io

Post reply on HN
Print view View original

161–170 of 186 posts

Re: Mastering Bash and Terminal

#161

Post by ufo »

eknkc wrote: post #128
TheAceOfHearts wrote: post #107

I've tried bash, zsh, and fish. After trying all three, I'm staying with fish. bash and zsh don't have sensible defaults, and configuring them is tedious. fish works great out of the box, and it's really fast. When I picked up zsh I used oh-my-zsh and later prezto, but it was slow and figuring out what everything all the framework did was complicated. With fish I have a setup.fish script that defines all my universal…

I use fish too but I'm thinking about switching back to zsh. Mostly due to incompatible software here and there (like nvm) and lack of completions for a lot of cli tools.

The Bass wrapper script can help with some of the incompatibilities:

https://github.com/edc/bass

Re: Mastering Bash and Terminal

#162

Post by antaflos »

whack wrote: 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…

A good starting point for versioning dotfiles is https://dotfiles.github.io/. I like to use Dotbot [1] for managing and installing my dotfiles, but there are plenty of other options listed.

[1] https://github.com/anishathalye/dotbot/

Re: Mastering Bash and Terminal

#163

Post by MarcScott »

Scea91 wrote: post #160

One thing I am struggling with is that when I use several terminal windows then the history is not recorded immediately and history from one window is not available in other windows. Some time ago I was looking up how to solve this but didn't find a solution that would work for me.

This bugs me as well. I use a tiling windows manager, so terminal windows are completely disposable to me, and I'll open and close them at will, often having double digit terminals open across 10 desktops.

My bash history does not reflect my use of multiple terminals.

Re: Mastering Bash and Terminal

#164

Post by claytonaalves »

greenspot wrote: post #141

Great post & thread, a tl;dr: Ctrl-r search history - then Ctrl-r again to show next match - then Tab to show all options Ctrl-p previous command or arrow up Ctrl-n next command or arrow down export HISTCONTROL=ignoreboth:erasedups Add to .bashrc to avoid duplicate entries Ctrl-a to beginning of line Ctrl-e to end of line Alt-b one word back Alt-f one word forward Ctrl-k delete to end of line Ctrl-u delete to beginni…

Ctrl+l clears screen. This is very useful even if you are inside a REPL like python, ruby, mysql, etc...

Re: Mastering Bash and Terminal

#165

Post by pmoriarty »

bigbugbag wrote: post #143
greenspot wrote: post #141

Great post & thread, a tl;dr: Ctrl-r search history - then Ctrl-r again to show next match - then Tab to show all options Ctrl-p previous command or arrow up Ctrl-n next command or arrow down export HISTCONTROL=ignoreboth:erasedups Add to .bashrc to avoid duplicate entries Ctrl-a to beginning of line Ctrl-e to end of line Alt-b one word back Alt-f one word forward Ctrl-k delete to end of line Ctrl-u delete to beginni…

Here are some notes I took about ZSH that may be helpful to someone * zsh bang previous commands: !! Previous command !-1 Previous command !-2 Second previous command Getting individual arguments: !$ Last arg !* All args !$:h Last argument, strip one level !!:1 First arg Modifying commandlines !ls:$:h Head !ls:$:t Tail !ls:$:r Rm Suffix !ls:$:s/user/dude/ Substitute user by dude * Filename Modifiers :h head (dirname)…

For all but the simplest renaming tasks, I use "qmv" (from the renameutils[1] package). It loads up the target filenames/paths in a buffer in your $EDITOR, and then you can use the full power of your editor to rename. When you save the buffer, qmv does a sanity check and then does the actual renaming.

Here's a simple example: [2], but it can get arbitrarily complex -- in a much more visual and interactive way than what a shell alone would be capable of.

[1] - http://manpages.ubuntu.com/manpages/wily/en/man1/qmv.1.html

[2] - http://unix.stackexchange.com/questions/1136/batch-renaming-...

Re: Mastering Bash and Terminal

#166

Post by pmoriarty »

dotancohen wrote: post #104
oblio wrote: post #20

Earlier quoted context omitted.

zsh was quite popular when I first went spelunking in *NIX-land (2005). oh-my-zsh, which was a decent boost to zsh popularity, seems to have been around since 2009 ( http://ohmyz.sh/ ). zsh has always been held back by the "default browser"-syndrome: Linux and Mac OS both come with "good enough" default shells, so few people actually want to go through the effort of switching. Especially since there is a bit of a lea…

The problem with installing zch on my desktop is that I won't have it on the servers I SSH into. I need to know the proper spells and incantations that will work on a wide variety of distros and versions, many of which I don't personally maintain. Therefore, bash.

This was the argument that persuaded me to switch from zsh to bash decades ago. But after a while I realized that it really didn't matter whether you used zsh on your own machine. When you ssh in to another machine that has bash on it, it's going to be similar enough that you're not going to feel lost.

Bash and zsh only differ in some of their more advanced features, which I rarely use or miss on machines I ssh in to -- unless I spend most of my time on those remote machines, in which case I'll just install zsh there too. The main thing from zsh that I do miss on bash is advanced globbing, which is more convenient than the find command, but when I'm forced to use bash I'll just use find, and it's really no big deal.

So I encourage you not to let the fact that most machines have bash installed on them deter you from switching to zsh, if you're interested in zsh. I know I regret the years lost that I didn't use zsh myself.

Re: Mastering Bash and Terminal

#167

Post by u801e »

oftenwrong wrote: post #158
renlo wrote: post #97

Earlier quoted context omitted.

tmux is a good alternative to the whole paradigm of 'running shell commands within a text editor like vim'. Why run a shell command within vim when one can run the shell command in an actual shell? It seems to me that running a shell command in vim is using vim outside of its intended scope. It might be able to do it but it won't be able to do it well, which is where something like tmux comes in. I might be in the mi…

(pedantic note: When you run shell commands in vim, they are running in an actual shell.) vim can be thought of as a visual and interactive helper for your text-processing utilities. The "intended scope" of vim is text editing, and while you're editing you may want to run commands on the text in your buffer, or just parts of it, and have the results apply immediately without writing and reloading the file, or exiting…

It's interesting to read up on the relationship between ed, sed, ex, and vi. In fact, all 4 of those editors have similar ways of addressing line ranges (1 for the first line, $ for the last line, etc).

One interesting feature many people may not know about is that it's possible to address lines using a regular expression.

For instance, if you had the following text in a vim buffer:

    one
    two
    three
    four
    five
and you wanted to delete the lines between "two" and "four" inclusive, you could run the following command in vim:

    :/two/,/four/d
You could also do the same thing in sed

    sed '/two/,/four/d' filename

Re: Mastering Bash and Terminal

#168

Post by pmoriarty »

erikb wrote: post #113
oblio wrote: post #20

Earlier quoted context omitted.

zsh was quite popular when I first went spelunking in *NIX-land (2005). oh-my-zsh, which was a decent boost to zsh popularity, seems to have been around since 2009 ( http://ohmyz.sh/ ). zsh has always been held back by the "default browser"-syndrome: Linux and Mac OS both come with "good enough" default shells, so few people actually want to go through the effort of switching. Especially since there is a bit of a lea…

Also, when you use a lot of scripts that only work with bash (there are more than you'd expect, despite zsh saying it is bash compatible) then you have the choice of either rewriting these scripts or using bash. Most ppl will choose not to rewrite.

zsh never claimed it was compatible with bash. I'm not sure where you got that impression from. Maybe you're thinking of sh -- the bourne shell -- which zsh is in fact compatible with (as long as you limit your scripts to the bourne shell subset of zsh).

Re: Mastering Bash and Terminal

#169

Post by pmoriarty »

Karrot_Kream wrote: post #95
pmoriarty wrote: post #59

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…

While I understand this sentiment, I think it's a point that needs a bit more thought; it's not a black and white issue. On my personal machines, I often find places where I want to either clean up my desktop experience or automate some workflow, where I break some shell out. Most of the time, the overhead to drop into an actual programming language is quite heavy, and even though I try to comment my scripts and writ…

I'm about as anti-systemd as you can get, but I also cringe whenever I look at some of those massive, convoluted shell scripts in SysVinit. There is a middle path, with runit[1], which mostly uses short, simple shell scripts for its process initialization and supervision.

Brevity and simplicity are really the keys when it comes to shell scripts. I really don't have a problem with them if they're short and don't try to be too clever. Whenever I've let my shell scripts get long or complicated, I've always regretted it, and always wound up rewriting them in a "real" programming language anyway, and then realizing that I would have been better off rewriting them much earlier, as soon as they'd outgrown the short, simple stage.

There's no shortage of relatively light-weight "real" programming languages like Perl, Python, Ruby, Lua, and Go -- for even moderately sophisticated tasks, all of them would be better choices than shell scripting.

[1] - http://smarden.org/runit/

Post reply on HN