This is why I use xonsh (http://xon.sh). It lets me use Python as a shell, and I don't have to remember too much awkward syntax.
Things I Wish I'd Known About Bash
71–80 of 272 posts
Re: Things I Wish I'd Known About Bash
#72This is the most helpful bash diagram ever... why didn't I search for this before! https://zwischenzugs.files.wordpress.com/2018/01/shell-start...
As given in the article, it's also the most annoying bash diagram ever...it needs an explanation of what the 7 different colors of arrows mean. All that was given is:
> It shows which scripts bash decides to run from the top, based on decisions made about the context bash is running in (which decides the colour to follow).
> So if you are in a local (non-remote), non-login, interactive shell (eg when you run bash itself from the command line), you are on the ‘green’ line [...]
With a bit of Googling I believe I found the origin of that diagram:
https://blog.flowblok.id.au/2013-02/shell-startup-scripts.ht...
The author there explains how the colors work:
> Fortunately, I’ve read the man pages for you, and drawn a pretty diagram. To read it, pick your shell, whether it's a login shell, whether it's interactive, and follow the same colour through the diagram. When the arrows split out to multiple files, it means that the shell will try to read each one in turn (working left to right), and will use the first one it can read
Re: Things I Wish I'd Known About Bash
#73Bash has a huge number of little shortcuts that are difficult to learn. When one encounters a sequence of symbols like $(...), it is difficult to Google for its meaning. The reason shells nevertheless have these shortcuts is of course because they are shells: from the commandline it can be very convenient to use shortcuts. But, in my opinion, that's where it should stop: one shouldn't use a shell language for scripti…
It's not just from the command line that these shortcuts are useful. Once you have a decent baseline on shell scripting fundamentals, the constructs are often highly optimized towards efficient and readable scripts.
Not having to put every command in quotes, for example, is a huge advantage all by itself, especially if any argument lists have quoted arguments.
The $(...) construct is pretty fundamental to bash scripting and should be covered in any decent tutorial.
Re: Things I Wish I'd Known About Bash
#74Earlier quoted context omitted.
Not all systems have POSIX, perl, python, javascript, C++, rust, go, etc., so should we write all our programs and scripts in sh?
The relevant point is that all systems running bash should also be POSIX compliant. So, taking some care to avoid bash-only constructs in a shell script can reap substantial gains in portability at fairly minor cost.
Why I should care about all systems? If targeted systems have bash4.x and GNU tools, why I should write scripts in sh?
If you care about all systems, ANSI C is better choice, IMHO.
Re: Things I Wish I'd Known About Bash
#75Earlier quoted context omitted.
The real 'Learn bash the hard way' is to read the man page top to bottom every 6 months. Ye gods, I've read it so many times… Also: lol at HN downvoting advice to read a tool's docs. Bash is terrible for a lot of reasons, but not because of its lack of informative documentation.
From the HN guidelines: Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
I've read the guidelines; you can just downvote instead.
Re: Things I Wish I'd Known About Bash
#76shellcheck ( https://www.shellcheck.net ) is an absolute godsend when writing Bash/POSIX sh scripts. It catches so many errors that I think it's a must have in every programmer's toolbox. It even catches bash-isms when you are targeting POSIX sh. It saved me many many hours of grief trying to debug shell scripts I wrote and changed the way I write them for the better.
This is also my number one thing I wish I'd known about Bash. It saves on so many trivial bugs.
The documentation is especially great, for ever problem it detects you get an unique reference which you can lookup on the wiki eg: https://github.com/koalaman/shellcheck/wiki/SC2086 It then not only describes the problem but also shows different ways of solving it with some great examples and reasoning. I think I learned more Bash from Shellcheck than anywhere else.
Re: Things I Wish I'd Known About Bash
#77Earlier quoted context omitted.
Are you writing your scripts in sh instead of bash, perl, python, JavaScript?
I prefer sh over bash for most of my scripts, but I will sometimes use Python instead.
So you use python instead of sh, but you argue that we should use sh instead of bash, perl, or python. I'm not convinced.
IMHO, we should use proper tool for the job instead of making artificial limitations. Bash is proper tool in lot of cases, unless old proprietary OS or very limited embedded OS are targeted.
Re: Things I Wish I'd Known About Bash
#78The author mentions the substitution !:1-$ to insert all the arguments from the last command (like !$ substitutes the last argument and !! the full command). Note that !* does exactly the same thing, which is a bit easier to type/remember.
Re: Things I Wish I'd Known About Bash
#79I wrote a book on Bash too. The most important thing for anyone to know about Bash is that it's intended as a command language, not a general purpose scripting language. If it's longer than 10 lines, or if it uses two or more variables, you should probably have written it in something other than Bash.
Would you consider non-trivial install scripts as an exception to this general rule? I mean, you wouldn't write some install script in ruby or python, right?
I don't know why not?
At the least, rather than Bash, you might consider Perl as a default, lowest common denominator for scripts that need to run anywhere.
- It's nearly as ubiquitous as bash.
- It has approximately the same kinds of file/path operations built in.
- It has reasonably good support for strings/regexes/etc. all built-in, so you don't have to call out to tools like sed/awk/grep all the time and hope that they are available and compatible across your target platforms.
- It provides reasonably good arrays and hashes, which are horribly horrible in bash.[1]
- You can use syscalls very easily if you really need to, but usually you don't.
[1] Of course, no language can save you from the file system disaster (https://www.dwheeler.com/essays/fixing-unix-linux-filenames....), but being able to know that "foo bar" is a string instead of two array elements is a good start.
Mostly this all applies to Ruby or Python too, modulo perhaps the degree of ubiquity.
Re: Things I Wish I'd Known About Bash
#80I really wonder why the author didn't just leave off the first two, and call it "Eight Things I...". Starting off with "backslash escapes can be confusing" and "/* doesn't just match things consisting of 0 or more slashes!" makes no sense if you're later going to skip over !! because it's "obvious".