Things I Wish I'd Known About Bash • Hacker News Board

Re: Things I Wish I'd Known About Bash

#61

Post by throwanem » Sat, Jan 06, 2018, 5:13 PM UTC

LukeShu wrote: post #60

throwanem wrote: post #55

Earlier quoted context omitted.

> they're basically using emacs controls But not well implemented! You're supposed to be able to edit your search string, and I've never found a way.

Huh? Backspace works the same for me in Bash C-r as it does in Emacs C-r.

It never does anywhere for me. Good to know it's supposed to, though; maybe I've got something mapped weird, or the versions of the shell I'm using are old enough to be unwelcoming in this way, or I don't know what, but knowing it's not by design means there's a fix to be found for it. Thanks!

Re: Things I Wish I'd Known About Bash

#62

Post by Goladus » Sat, Jan 06, 2018, 5:13 PM UTC

sethrin wrote: post #30

I 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.

I disagree. Here's how I decide:

Do I need to manipulate rich data structures like hash-maps or nested lists? That sort of thing tends to stretch the capabilities of Bash to its limits and I tend to set the bar fairly low here.

Is the program oriented around commands? If I'm gluing executable scripts and binaries, using bash is often superior to a scripting language. Argument passing is more natural and convenient and the built-in support for the standard i/o streams makes it easy for the different commands to pass data between them. The number of variables or lines of logic is usually less important than the number of different installed commands I need to combine. (Or the number of variations on a single command)

Do I need to modify the environment in a significant way? In a bash script it's trivial to source in an environment script, which can be done conditionally or even interactively. This is usually more tedious to do in scripting languages.

Re: Things I Wish I'd Known About Bash

#63

Post by LukeShu » Sat, Jan 06, 2018, 5:13 PM UTC

jwilk wrote: post #3

> if [ x$(grep not_there /dev/null) = 'x' ] This is still wrong if the command can output spaces or meta-characters. You should quote the left operand, and then you don't need to prepend x: if [ "$(grep not_there /dev/null)" = '' ]

The legacy of autoconf! People look at autoconf's output to learn shell, but autoconf output is full of bad practices, working around bugs in shells that noone's ever heard of.

Autoconf output is expected to run on buggy shells with broken empty-string comparison. Your scripts probably aren't.

Re: Things I Wish I'd Known About Bash

#64

Post by stephenr » Sat, Jan 06, 2018, 5:19 PM UTC

coldtea wrote: post #47

luckydude wrote: post #29

+1 for the parts that are portable to Bourne shell/ksh/zsh. -1000 for the parts that are specific to Bash. Stuff like that has been huge pain in my ass over the years. Some clever programmer uses some bash-ism and the build breaks on some ancient hardware that doesn't have bash. I realize my complaint sounds like Henry Spencer's Ten Commandments and perhaps it feels outdated but trust me, you don't want to wade into…

> Stuff like that has been huge pain in my ass over the years. Some clever programmer uses some bash-ism and the build breaks on some ancient hardware that doesn't have bash. Shouldn't the problem be the "ancient hardware that doesn't have bash" itself?

A brand new macbook pro will not have bash4.

Re: Things I Wish I'd Known About Bash

#65

Post by falsedan » Sat, Jan 06, 2018, 5:20 PM UTC

jwilk wrote: post #8

rename -n 's/(.*)/new$1$2/' * There's a chance this won't work on your system. There are two incompatible versions of rename in the wild: 1) Perl one: https://metacpan.org/pod/distribution/File-Rename/rename.PL 2) from util linux: http://man7.org/linux/man-pages/man1/rename.1.html Debian (and dertivaties) ship the former; other Linux distros likely the latter.

I think this is not specific to the shell you are using, so it happens in bash, fish, ksh, zsh, and so on.

Re: Things I Wish I'd Known About Bash

#66

Post by falsedan » Sat, Jan 06, 2018, 5:27 PM UTC

carapace wrote: post #44

Damn it this boils down to RTFM, specifically the bash man page.

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.

Re: Things I Wish I'd Known About Bash

#67

Post by jwilk » Sat, Jan 06, 2018, 5:28 PM UTC

falsedan wrote: post #66

carapace wrote: post #44

Damn it this boils down to RTFM, specifically the bash man page.

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.

Re: Things I Wish I'd Known About Bash

#68

Post by Goladus » Sat, Jan 06, 2018, 5:28 PM UTC

v_lisivka wrote: post #51

skj wrote: post #11

Earlier quoted context omitted.

Not all systems have bash.

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.

Re: Things I Wish I'd Known About Bash

#69

Post by tzs » Sat, Jan 06, 2018, 5:29 PM UTC

jwilk wrote: post #3

> if [ x$(grep not_there /dev/null) = 'x' ] This is still wrong if the command can output spaces or meta-characters. You should quote the left operand, and then you don't need to prepend x: if [ "$(grep not_there /dev/null)" = '' ]

Because when displayed in a variable width font two single quotes can look very similar to one double quote, that last line is very easy to misread. Here it is in code mode:

  if [ "$(grep not_there /dev/null)" = '' ]

Re: Things I Wish I'd Known About Bash

#70

Post by falsedan » Sat, Jan 06, 2018, 5:31 PM UTC

Goladus wrote: post #62

sethrin wrote: post #30

I 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.

I disagree. Here's how I decide: Do I need to manipulate rich data structures like hash-maps or nested lists? That sort of thing tends to stretch the capabilities of Bash to its limits and I tend to set the bar fairly low here. Is the program oriented around commands? If I'm gluing executable scripts and binaries, using bash is often superior to a scripting language. Argument passing is more natural and convenient an…

Also: do I need to run a producer & consumer (and maybe some intermediary filters) on a stream of data, and want to run them in parallel? Shell pipelines are trivially easy to set up & test.