[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sourcing a script from a pipe is not reliable

From: Martijn Dekker
Subject: Re: Sourcing a script from a pipe is not reliable
Date: Fri, 11 Jan 2019 00:29:21 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Op 10-01-19 om 22:52 schreef Jeremy:
> We are trying to determine if the current shell supports passing positional
> arguments to a script sourced by dot (.), and we are trying to do it in a
> way that will work under pretty much any shell.  If you can show me how to
> do that with eval, then that would be great, even though in general I hate
> to ship a script that uses eval.

While not all shells support passing positional parameters to dot
scripts, it is very simple to make work for POSIX sh: shell functions
provide positional parameters, so wrap the dot command in one of those.

        dot() {
                . "$_myscript"
        # use like:
        dot ./somescript.sh one two three

"Sourcing" a script read from standard input without relying on the
non-standard /dev/stdin is also very simple:

        eval "$(cat)"

This does load the entire script in memory before beginning execution,
but I can't imagine that being a problem in 2019, unless the script is
generated by some infinite loop.

To get your local positional parameters for a script read from standard
input, you can combine both techniques:

        dotstdin() {
                eval "$(cat)"

The following then works as expected:

        dotstdin one two three <<-'EOF'
        printf "ok: %s\\n" "$@"

Note that double-quoting the "$(cat)" command substitution is essential
to avoid globally active split and glob; among other things, this makes
multiple-line scripts work.

This is all perfectly POSIX and should also work fine on bash 3.2.

Hope this helps.

- M.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]