Delegating complex treatments to filters in shell programs (2015)

Re:Delegating complex treatments to filters in shell program... by jstimpfle on Friday May 12, 2017 @11:23AM (#14324791)

Yes, the critizised code is definitely bad. Glues two user-defined constructs together (is-in-list and a variable). Also, unquoted variables and relying on shell splitting...

But you don't necessarily need to shell out to awk / perl / grep / whatever.

    is_in_list() {
        local thing=$1
        shift
        while [ $# -gt 0 ] ; do
            [ "$1" = "$thing" ] && return 0
            shift
        done
        return 1
    }

Now just do `is_in_list "$thing" "$@"` where the positional array `"$@"` is the list (or by all means use unquoted `$COMPILER_VERSIONS`, i.e. unsafe shell-splitting).

Another possibility, where the list is given as a space-separated string, is with case statements. That approach is logically equivalent to the awk version, but doesn't fork so is much more performant.

    is_in_list() {
        case $2 in
        $1|*" $1 "*|*" $1"|"$1 "*) return 0;;
        *) return 1;;
        esac
    }

Not tested, but that's the idea.

[ Parent | on HN ]

Re:Delegating complex treatments to filters in shell program... by falsedan on Friday May 12, 2017 @12:22PM (#14325325)

Bash is all about shelling out: it's a shell. I would happily use grep here, and if I had an array:

  printf "%s\0" "$@" | grep -qz needle

> much more performant

I believe that performance-critical code shouldn't be written in bash. I have seen pipelines be much faster than tweaked bash functions, simply because they run in parallel & thus the cost of forking is paid once, up-front.

[ Parent | on HN ]

Re:Delegating complex treatments to filters in shell program... by jstimpfle on Friday May 12, 2017 @12:53PM (#14325606)

I agree with you. I think we are just speaking about different things.

I was more thinking about the things that happen in a configure script, for example. Not a "hoot loop" like a big grep over millions of lines or something.

There are situations in shell code where the difference between a case-match or string-suffix-replace written in shell and a process spawn matters. Not only because forking a process for one simple string operation is wasteful (cost: about 1ms), but also because of the semantic problems that come with child processes (error handling).

[ Parent | on HN ]