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

171–180 of 272 posts

Re: Things I Wish I'd Known About Bash

#171

Post by dorfsmay »

jmiserez wrote: post #121
throwanem wrote: post #61

Earlier quoted context omitted.

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!

You should try hstr ( https://github.com/dvorka/hstr ). It replaces CTRL-R with a full page interactive history search that really works. Demo GIF here: https://unix.stackexchange.com/a/375914

If you use either vim or emacs, there's something to be said about using that knowledge for your command line history.

Re: Things I Wish I'd Known About Bash

#172

Post by chriswarbo »

Sir_Cmpwn wrote: post #4

#0: If you're writing scripts that are destined for other users, use POSIX sh instead.

I disagree with this.

There's nothing wrong with writing bash scripts, with a shebang like `#!/usr/bin/env bash`, just like there's nothing wrong with writing python scripts (with `#!/usr/bin/env python`), or Haskell scripts (with `#!/usr/bin/env runhaskell`), or whatever other language you like/think is appropriate/etc.

It's true that bash is unavailable by default on (say) microcontrollers, but I don't see the relevance given that loads of common scripting languages aren't available by default on microcontrollers (Python, Ruby, JS, PHP, etc.).

PS: With this said, don't start your bash scripts with a `sh` path like `#!/bin/sh` or `#!/usr/bin/sh`. In fact, don't use a hard-coded path like `#!/bin/bash` or `#!/usr/bin/bash` either, always use `#!/usr/bin/env bash` unless you have a good reason not to. (Whilst `/usr/bin/env` is a hard-coded path, it can also be treated as a single special-case by systems which don't follow FHS, like NixOS, GuixSD and GoboLinux).

Re: Things I Wish I'd Known About Bash

#174

Post by Sir_Cmpwn »

chriswarbo wrote: post #172
Sir_Cmpwn wrote: post #4

#0: If you're writing scripts that are destined for other users, use POSIX sh instead.

I disagree with this. There's nothing wrong with writing bash scripts, with a shebang like `#!/usr/bin/env bash`, just like there's nothing wrong with writing python scripts (with `#!/usr/bin/env python`), or Haskell scripts (with `#!/usr/bin/env runhaskell`), or whatever other language you like/think is appropriate/etc. It's true that bash is unavailable by default on (say) microcontrollers, but I don't see the rele…

Bash is a special case where there exists a similar tool which is standardized in POSIX, and for most cases where sh is insufficient bash is probably insufficient too. Therefore POSIX sh is almost always the better choice.

Re: Things I Wish I'd Known About Bash

#175

Post by chriswarbo »

For me, the biggest gotcha in bash is whether or not a sub-process/shell will be invoked, which can affect things like mutable variables and the number of open file handles. For example:

    COUNT=0
    someCommand | while read -r LINE
                  do
                    COUNT=$(( COUNT + 1 ))
                  done
    echo "$COUNT"
This will always print `0`, since the `COUNT=` line will be run in a sub-process due to the pipe, and hence it can't mutate the outer-process's `COUNT` variable. The following will count as expected, since the `
    COUNT=0
    while read -r LINE
    do
      COUNT=$(( COUNT + 1 ))
    done
Another issue I ran into is `$()` exit codes being ignored when spliced into strings. For example, if `someCommand` errors-out then so will this:

    set -e
    FOO=$(someCommand)
    BAR="pre $FOO post"
Yet this will fail silently:

    set -e
    BAR="pre $(someCommand) post"

Re: Things I Wish I'd Known About Bash

#176

Post by Hello71 »

chriswarbo wrote: post #175

For me, the biggest gotcha in bash is whether or not a sub-process/shell will be invoked, which can affect things like mutable variables and the number of open file handles. For example: COUNT=0 someCommand | while read -r LINE do COUNT=$(( COUNT + 1 )) done echo "$COUNT" This will always print `0`, since the `COUNT=` line will be run in a sub-process due to the pipe, and hence it can't mutate the outer-process's `CO…

    $ bash -ec 'BAR="pre $(someCommand) post"; echo hi'
    bash: someCommand: command not found
    $
I get the same behavior in bash, zsh, dash, and busybox sh. shbot says the same for bash versions since 1.14, ksh, and even the original bourne shell (modified to use ` instead of $()).

Re: Things I Wish I'd Known About Bash

#177

Post by IshKebab »

JepZ wrote: post #122
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 too. Bash has many downsides, but there are very few languages out there which have the ability to 'connect' different programs so easily. Bash scripts are slow as hell (as most commands have to spawn new processes), it is hard to write "secure" code (if even possible), handling whitespaces can be a pain in the * and the amount of repetition is awful. If your kid has done something wrong, just tell it to w…

The reason it can connect programs so "easily" is because it basically ignores errors and robustness - it really relies on there being a user looking at the output and going "hmm that looked like it failed".

Doing things properly in Python or Go may take a few more lines (not much more really) but it is 100 tones more robust, and you need that if you are writing anything more than a 10-line one-off hack.

Re: Things I Wish I'd Known About Bash

#178

Post by pas »

joncrane wrote: post #158
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.

How do you feel about the use of bash for AWS userdata and the like? You pretty much have to put all the init stuff in a bash script. I can't think of any real-world examples of userdata scripts being less than 10 lines. The alternative of course would be a three line script that downloads a file and executes it. But what language would that file be in? Probably bash. And it would make the infrastructure-as-code trac…

Not OP, but ...

You can use Go/Rust for static linked bootstrap instead of Bash. (See rustup.)

I'm thinking about combining GitLab (private token access + repository files: https://docs.gitlab.com/ce/api/repository_files.html#reposit... ) and a bootstrap script in Bash, that then launches something better. Plus self registration back into a GitLab repo (hey, it has the access token already, so it can push).

Yes, Ansible/SaltStack/Chef/Puppet reinvented, but you're now not bound to the horrible database, language, bootstrap, speed (slowness) and workflow of any of them.

If you want more access control, then creating a HTTP microservice that has the real private token (or proper OAuth2 access) to GitLab plus handles the self-registration and token handout/revocation is easy compared to the other parts. (And it can also store everything in GitLab.)

Re: Things I Wish I'd Known About Bash

#179

Post by i_feel_great »

What is the best alternatives to bash for writing fairly large automation scripts? I have already looked at Python, Lua and Guile. The last two especially since I like using them and they have some sort of posix interfaces. I haven't looked at Perl 6.

Re: Things I Wish I'd Known About Bash

#180

Post by yeukhon »

joncrane wrote: post #158
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.

How do you feel about the use of bash for AWS userdata and the like? You pretty much have to put all the init stuff in a bash script. I can't think of any real-world examples of userdata scripts being less than 10 lines. The alternative of course would be a three line script that downloads a file and executes it. But what language would that file be in? Probably bash. And it would make the infrastructure-as-code trac…

I believe in your userdata script you can write a line to download a Python script from S3, then proceed to execute. Don't quote me on this since I don't use userdata.

However, note that userdata will only run once at launch time. If you ever need to re-run userdata, you have to stop the instance, remove the userdata from settings, and then add again. YMMV.

I do the Python way when launching a beanstalk instance (basically cloud init).

Post reply on HN