Comment by csours

8 hours ago

The conveniences also mean that there is more than ~one~ ~two~ several ways to do something.

Which means that reading someone else's shell script (or awk, or perl, or regex) is INCREDIBLY inconvenient.

5 comments

csours

Reply
amelius  8 hours ago

Yes. There are many reasons why one shouldn't use sh/bash for scripting.

But my main reason is that most scripts break when you call them with filenames that contain spaces. And they break spectacularly.

  • nixon_why69  5 hours ago

    Counter reason in favor is that you can always count on it being there and working the same way. Perl is too out of fashion and python has too many versioning/library complexities.

    You have to write the crappy sh script once but then you get simple, easy usage every time. (If you're revising the script frequently enough that sh/bash are the bottleneck, then what you have is a dev project and not a script, use a programming language).

  • ndsipa_pomu  7 hours ago

    You're not wrong, but there's fairly easy ways to deal with filenames containing spaces - usually just enclosing any variable use within double quotes will be sufficient. It's tricker to deal with filenames that contain things such as line breaks as that usually involves using null terminated filenames (null being the only character that is not allowed in filenames). e.g find . -type f -print0

    • deathanatos  5 hours ago

      You're not wrong, but at my place, our main repository does not permit cloning into a directory with spaces in it.

      Three factors conspire to make a bug:

        1. Someone decides to use a space
  2. We use Python
  3. macOS

      Say you clone into a directory with a space in it. We use Python, so thus our scripts are scripts in the Unix sense. (So, Python here is replacable with any scripting language that uses a shebang, so long as the rest of what comes after holds.) Some of our Python dependencies install executables; those necessarily start with a shebang:

        #!/usr/bin/env python3

      Note that space.

      Since we use Python virtualenvs,

        #!/home/bob/src/repo/.venv/bin/python3

      But … now what if the dir has a space?

        #!/home/bob/src/repo with a space/.venv/bin/python3

      Those look like arguments, now, to a shebang. Shebangs have no escaping mechanism.

      As I also discovered when I discovered this, the Python tooling checks for this! It will instead emit a polyglot!

        #!/bin/bash

  # <what follows in a bash/python polyglot>
  # the bash will find the right Python interpreter, and then re-exec this
  # script using that interpreter. The Python will skip the bash portion,
  # b/c of cleverness in the polyglot.

      Which is really quite clever, IMO. But, … it hits (2.). It execs bash, and worse, it is macOS's bash, and macOS's bash will corrupt^W remove for your safety! certain environment variables from the environment.

      Took me forever to figure out what was going on. So yeah … spaces in paths. Can't recommend them. Stuff breaks, and it breaks in weird and hard to debug ways.

      1 reply →