'read ... < file' works, but horks up subsequent executions

[Phil Edwards]

Previous experience with the read builtin had convinced me that its
limitations made it almost useless, and section E4 of the Bash FAQ backed
this feeling up.  Then I found myself needing to split input up and store
it in successive variables (since arrays can't be exported, and 'export'
won't even print an error if you try).  So I decided to give 'read' one
more chance, because that's exactly what it's supposed to do.

It's almost working, but about to re-convince me that it really is useless.

The task is

    # foo, bar, and baz are already marked as exported
    function f()
    {
       read foo bar baz
       echo baz is $baz
       run_a_program_that_uses_them
       echo result was $?
    }

If f is run from the command prompt, and I type the three inputs directly,
then all is well.  The actual usage of this function, though, would be
like this:

    echo foo_value bar_value baz_value > file
    ...some other day, some other shell instance...
    f < file

After a whole lot of debugging, I've found that this correctly assigns
the three variables -- yay! -- but screws up stdin.  The program isn't
even executed; from there to the end of the function, only the builtin
commands are executed.  No external programs are run, even when prefixed
with 'command'.  The final echo says 'result was $?'.

If 'file' contains more than one line,

    echo foo_value bar_value baz_value > file
    echo wtf >> file

then this behavior doesn't change, but the rest of 'file' is treated as
shell input, which was a harsh surprise.

    baz is baz_value
    bash: wtf: command not found
    result was 127

'file' will normally only ever have one line, but the whole project is an
exercise in futility when the shell stops running external commands.


-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002