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

Things I Wish I'd Known About Bash

zwischenzugs.com

Post reply on HN
Print view View original

131–140 of 272 posts

Re: Things I Wish I'd Known About Bash

#131

Post by JepZ »

One of my favorite Bash patterns is the following. I call it 'feed the fish':

  .
While it is extremely dangerous I found it so easy to remember, that it stuck in my head. It downloads the script and executes it in the current shell. So if anything unexpected happens you probably have a real problem ;-)

Background: A few years ago I was writing a Bash based OS installer. So after booting from a live CD I had to fetch the installer and execute it, which lead me to using that pattern frequently.

While I love it, I can't stress enough how dangerous it is.

Re: Things I Wish I'd Known About Bash

#132

Post by shrumm »

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 think the 10 line limit seems a little harsh. Bash is great to prototype something, especially because of all the great commands at your disposal versus writing it yourself. e.g. grep, sed, cut are all commands I use frequently. Once you've got a working script and it proves useful or needs to scale - that's a good time to go the 'real language' route like Python.

Re: Things I Wish I'd Known About Bash

#133

Post by Sniffnoy »

wodenokoto wrote: post #129

What was the surprising part about echo '*' echo "*" ? Both prints an asterisk. Is '*' some sort of BASH variable?

The asterisk * is a glob. Since double-quotes allow variables inside to be dereferenced rather than always quoting everything literally, presumably he was expecting that double-quotes might still allow globs to work rather than causing them to be quoted, when in fact all quotes will quote globs whether single or double. So he was expecting it might print out "a".

Re: Things I Wish I'd Known About Bash

#134

Post by coldtea »

stephenr wrote: post #64
coldtea wrote: post #47

Earlier quoted context omitted.

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

And it's all 2 minutes to add it as your default shell (including installing brew itself).

  22:06  ~  $ bash --version
  GNU bash, version 4.4.12(1)-release (x86_64-apple-
  darwin16.3.0)
Much easier than constraining oneself about what to put in one's script (assuming one is indeed targeting Linux, OS X etc released in the last 10+ years and not some embedded etc platforms).

Re: Things I Wish I'd Known About Bash

#135

Post by mdaniel »

hyperpape wrote: post #48
tomsmeding wrote: post #28

Earlier quoted context omitted.

Which is why the parent advised to treat the man page like a reference document, by searching in it. Some man pages are just badly written and are indigestible even when searching for a specific thing, but in general, that approach works quite often.

Is there some trick to searching man pages that I don’t know? Because my usual experience is: type man foo type /-p type n n n n n n n n n as there are a bunch of matches like “...does bar when combined with -p...” A presentation of man pages that used hypertext would make me a lot happier.

as there are a bunch of matches like "...does bar when combined with -p..."

It has been my experience that the definition of switches, unlike their use in examples or other text, occurs as the first thing on the line, so my search expression would be:

    /^ *-p
(you likely can't see it, but there is a trailing space, too, to ensure it's just that flag, and not "-parallel" or whatever)

It's possible the text will be tab-indented, in which case:

    /^[ ^I]*-p[ ^I]
(most pagers will accept just pressing the tab key in the search string, and it may show up as ^I or the literal tab character)

Re: Things I Wish I'd Known About Bash

#136

Post by khedoros1 »

Pete_D wrote: post #84
hyperpape wrote: post #48

Earlier quoted context omitted.

Is there some trick to searching man pages that I don’t know? Because my usual experience is: type man foo type /-p type n n n n n n n n n as there are a bunch of matches like “...does bar when combined with -p...” A presentation of man pages that used hypertext would make me a lot happier.

If foo has a Texinfo manual (GNU tools like bash usually do) then you can try `info foo` and search the index with i or I for -p. Texinfo manuals also have hyperlinks you can press enter on. info is a greatly underused system and I'd recommend any *nix users to spend some time learning how to navigate it.

For bash: 'i' gives me "no indices found" and 'I' says "no index". I can do a '/' search, which finds some "-p" strings, but "n" doesn't work to find the next.

From some other comments, it sounds like "info" uses emacs at its core? So I suppose I'd have to learn some emacs commands, if that's the case.

Re: Things I Wish I'd Known About Bash

#138

Post by mdaniel »

lobster_johnson wrote: post #120
tzahola wrote: post #2

My take on the same topic: - use the unofficial strict mode: http://redsymbol.net/articles/unofficial-bash-strict-mode/ - use parameter substitutions like ${foo#prefix}, ${foo%suffix} instead of invoking sed/awk - process substitution instead of named pipes: () - know the difference between an inline group {} and a subshell () - use printf "%q" when passing variables to another shell (e.g. assembling a command locall…

While process substitution is great on the surface, it comes with a troubling downside: There is no way, that I have found, to reliably catch errors. That is, this: some-command ...will succeed. And -e and pipefail do nothing here. I have not found any way to push the error up. Plenty of questions on Stackoverflow and elsewhere, no good answers.

pipefail do nothing here

Isn't that because the syntax provided doesn't use a pipe? Which is why actually using a pipe, rather than paren redirection, is easier on the eyes and the shell. It reads more like the flow of text:

    maybe_failing() {
        if ! some-failing-command; then
           echo "That did not shake out" >&2
           return 1
        fi
    }

    maybe_failing | some-command
Is that one of the things StackOverflow said? And if so, why is it not a "good" answer (verbosity concerns aside)?

Re: Things I Wish I'd Known About Bash

#139

Post by LukeShu »

kps wrote: post #57
rocqua wrote: post #32

Earlier quoted context omitted.

The article doesn't mention which are portable and which aren't.

It's a cultural thing. GNU is intended to replace Unix, so interoperability is (at best) not a priority. Same as Microsoft's “embrace, extend, extinguish”, which shows how important a good slogan is if you want your ambitions recognized. A POSIX (or older Bourne-descended) shell can be distinguished from ‘bash --posix’ in a script with a fragment like “date&>F”, because Bash authors either didn't realize or didn't ca…

I wanted to argue that POSIX didn't define this behavior. But, reading the spec: I agree with you, Bash is non-compliant there.

According to POSIX (2016 edition)

    date&>F
should be equivalent to

    date &
    (exec >F)
where in Bash, it's equivalent to

    date >F 2>&1

Re: Things I Wish I'd Known About Bash

#140

Post by npongratz »

hyperpape wrote: post #48
tomsmeding wrote: post #28

Earlier quoted context omitted.

Which is why the parent advised to treat the man page like a reference document, by searching in it. Some man pages are just badly written and are indigestible even when searching for a specific thing, but in general, that approach works quite often.

Is there some trick to searching man pages that I don’t know? Because my usual experience is: type man foo type /-p type n n n n n n n n n as there are a bunch of matches like “...does bar when combined with -p...” A presentation of man pages that used hypertext would make me a lot happier.

You can use apropos to search names and descriptions inside man pages. For example:

    $ apropos timezone
    Date::Manip::DM5abbrevs (3pm) - A list of all timezone abbreviations
    dm_zdump (1p)        - timezone dumper
    Time::Zone (3pm)     - - miscellaneous timezone manipulations routines
    timezone (3)         - initialize time conversion information
    tzfile (5)           - timezone information
    tzselect (1)         - view timezones
    tzselect (8)         - select a timezone
    zdump (8)            - timezone dumper
    zic (8)              - timezone compiler
Can even search using regular expressions.
Post reply on HN