121–130 of 195 posts
Most of the responses here so far that do not include some sort of a guide are not the responses you're looking for (imho). Mind your pipes and quotes. Guard your variables with braces. Do not export everything, test for and (try to) handle return codes and conditions and keep it simple (emphasis simple) but most of all just write it. BASH (or Bourne) is ubiquitous when dealing with systems (vs programs). You don't n…
https://www.google.com/search?q=whizbangwoohoo
Bash is essentially a DSL for these. A lot of the weirdness you see in the language is due to these abstractions leaking through. For example:
* Quoting is building execve's argv parameter. It's hard to quote correctly if you don't know what exactly you're working towards.
* Redirections are opening and copying file descriptors. It explains their scope, order and nesting behavior.
* Variables are modifying and passing the environment, and their weird scope is due to forks imposed by the process model.
Once you know how you can do whatever you want in C through the basic syscalls, Bash is an extremely efficient and far less surprising shortcut to do it.
For scripting, I recommend the rc shell from plan9, which is the one I use for my shell scripts. It is only when I want to share a script with other people that I consider using /bin/sh, and even then more often than not I've gone for rc. I invite you to read about it: http://doc.cat-v.org/plan_9/4th_edition/papers/rc . I find the control structures simpler and more elegant, and overall its design feels more consiste…
As silly as it sounds, when I was a new Unix SysAdmin, I read the entirety of "man 1 bash", which includes all bash builtins. I found that it improved by bash-foo 100x simply by knowing about so many of the utilities. I also took some cliff notes for things that seemed generally useful. I did it for an hour or so a night for a week or so. That being said, a few of my personal favorites to memorize: * Parameter expans…
keith@illy:~$ man bash | col -b | wc
5738 46385 323374
If your use case is pragmatic in nature, I would recommend my post on the topic: http://alexpetralia.com/posts/2017/6/26/learning-linux-bash-...
What Kai Thinks Every Developer Should Know About the Shell
That worked for me. You could also read the man pages, but step #1 is crucial regardless.
Bookmark the following url and come back to it as often as you need: http://tldp.org/LDP/abs/html/ Also this one to learn some cool tricks: http://www.commandlinefu.com/commands/browse
That and shellcheck(+syntastic if you use vim) ramps up the skill level quite fast.
As silly as it sounds, when I was a new Unix SysAdmin, I read the entirety of "man 1 bash", which includes all bash builtins. I found that it improved by bash-foo 100x simply by knowing about so many of the utilities. I also took some cliff notes for things that seemed generally useful. I did it for an hour or so a night for a week or so. That being said, a few of my personal favorites to memorize: * Parameter expans…
Earlier quoted context omitted.
1000 times this. You're going to get a lot of snark from people saying things like "don't", or "learn python instead". This epitomizes "a little knowledge is a dangerous thing". Bash has many cringeworthy aspects, but we have to deal with the world as it is, not the world as we would like it to be, and the reality is that bash is the default shell on 99.9% of unix boxes you encounter — even if you use an alt shell on…
Bash is unbeatable as a functional concept for chaining command-line tools together. Once you start getting functions or even a lot of if/while constructs, it's usually time to switch to Python/Perl.