Modulinos in Bash | Hacker News Reader

Modulinos in Bash

blog.dnmfarrell.com

66 pointstodsacerdoti18 comments

As a Python beginner I found the ubiquitous if __name__ == '__main__' very confusing...

Yeah, naming things is hard. In retrospect it really should have been something like __modulename__ but that’s also not right because it doesn’t always return the name of the current module. If you run foo.bar.baz as a script you’ll get __main__ which is actually kinda weird when you think about it. But __modulenameormain__ is a bit long to type.

Now the Python devs will say that this is perfectly consistent because the names of modules are determined by the __main__ module and how they’re imported and so the idea that the entry point of a script not being __main__ is preposterous but I don’t think that jives with how people actually write Python code and that “the main module” can actually be “mycompany.app.serverboi” and probably should be for the purposes of logging.

I mean the real trick there is to not use single-file modules. If you make a folder with a __main__.py and __init__.py you can get rid of the if statement.

Not entirely obvious.

Modulinos are nice (using them in Python and Ruby ever since I did Perl), sometimes an entirely self-contained single-sourcefile program is very useful, especially when leaning on literate programming, yet one may still want its functions to be importable by an outsider program.

Light reminder that this would be a problem when the shell got set -e:

    [[ "$BASH_SOURCE" == "$0" ]] && hello

Shellcheck to the rescue, use if; then; fi instead which is barely longer.

Why would that be a problem with set -e? Both in that form and with if-then, if the [[ ... ]] fails, the shell does not exit, if any command in hello (or, in rare cases, hello itself) fails, it does. Shellcheck does not print anything related to this, it only prints "SC2128: Expanding an array without an index only gives the first element."

foo.sh:

    set -e
    
    function hello() {
        echo "hello"
    }
    [[ "$BASH_SOURCE" == "$0" ]] && hello

bar.sh:

    source foo.sh
    hello

then:

    $ bash bar.sh; echo $?
    1

because the [[ ]] exits with nonzero, right hand of && does not execute, so the whole expression exits with nonzero, and thus the errexit condition triggers, bailing out of everything.

This also happens when moving set -e from foo.sh (the modulino, as a lib) to bar.sh (the modulino consumer), so since in the modulino you can't be sure which of +e or -e will be, you basically have to pick the strictest for robustness.

That's not entirely what is happening there. The shell doesn't exit because the [[ "$BASH_SOURCE" == "$0" ]] condition is false. Its status is checked, so it doesn't cause the shell to exit. What's happening instead is that the exit status of the "source" command is that of the last command executed in the sourced file, and its status is not checked, so the failure there does cause the shell to exit under -e. Add a command that's just "true" or ":" or "echo debug" to foo.sh and you'll see a change in behaviour.

It's probably best to ensure that sourcing a source-able file results in a 0 return status if sourcing succeeded even under +e, since the caller may be using something along the lines of source file || { echo "failed to source file" >&2; exit 1; }. And sure, using if-then-fi rather than && can be a perfectly good way of achieving that.

[[ "$BASH_SOURCE" == "$0" ]] && hello || true

true will run if hello fails. if...else and &&..|| are not equivalent.

Bug: return code of hello will be ignored. Moreover, it's better to use nop: ":" instead of "true".

Correct version:

  [[ "$BASH_SOURCE" == "$0" ]] && { main "$@" ; exit $?; } || :

Wouldn't a more robust check be the following:

  if [[ "${BASH_SOURCE[0]}" = "${0}" ]]; then
    hello "${@}"
    exit $?
  fi

I would add the index on BASH_SOURCE, but the braces on $0 and $@ are just verbose.

Agreed - I just put braces and quotes wherever I can. There's also no need for the quotes inside double brackets, but I prefer a consistent (verbose) style.

This is really cool, and would be especially useful for unit testing like the article says!

put your tests into the module!

. . # exit when sourcing [ "$0" == "${BASH_SOURCE[0]}" ] || return 0

echo "Tests for [$0]" . .

this way you'll wind up able to load/source globs of reusable self testing code into the global namespace with ease.

add a [ -n "$1" ] && { undef and exit } block at the top of the file where you document the names you're using as you would in a header.c and packaging your code for reuse becomes easy.

at last count i have 19 such modules in /ops/bash. they are immensely useful to help me remember this atrocious language :)

I am having a hard time conceptualizing that (maybe I need caffeine). Could you post an example?

This introduces a global namespace for all modules and scripts, with potential for collisions.

That should be avoidable with "include guards" like

  [ -n "$_MY_FILE" ] && return || readonly _MY_FILE=1

Reply on news.ycombinator.com