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

[Chris F.A. Johnson]

On 2004-05-23, Phil Edwards wrote:
> 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()

   Use "f()" (prefereably) or "function f", not both.

>     {
>        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

    You have connected the stdin of everything in the function to the
    file. If you only want the read command to use file as stdin, then
    you have to write it that way:

f() {
   read foo bar baz < 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.
>
>


-- 
        Chris F.A. Johnson                      http://cfaj.freeshell.org
        =================================================================
                Everything in moderation -- including moderation