Re: set -F kills read -t

[Ray Andrews <rayandrews@eastlink.ca>]

[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]

On 03/18/2014 11:37 PM, Bart Schaefer wrote:
>      cat /dev/null | func
>
> There will be no output from cat, so as seen by [the commands in the
> definition of] func, there's a pipe, but there is no input.
Yabut 'cat' still returns, so I'd use that as the terminator.

      echo "" | func

... would 'know' that echo is 'finished' and that's that. Can't one 
process know that
another process is finished? Anyway it doesn't matter, Jan's solution is 
crisp,
understandable, robust and has no ifs, buts or maybes. As you said, this 
asynchronous
stuff is bedrock to shell and it ain't going to change, I hafta get used 
to it.
>
> Shell functions are little more than names for the set of commands
> inside them; it's nonsensical to say that "func should politely wait".
> What will politely wait (or not) is the first command inside func
> that attempts to read standard input.  If there is no such command,
> nothing waits.
Of course. One can't presume that the function has some behaviours apart 
from
the behaviours of it's contents. But in this case we're referring to 
'read' and  I
had speculated that 'read' might be able to have the option of being 
asked to wait
for some previous command to finish. Come to think of it, what it would 
do is
take Jan's code and more or less bundle that into an option to 'read'. 
Nevermind:

     if [ ! -t 0 ]; then read input; fi

... isn't exactly hard to type. I yield the point.
>
> It's not actually the case that $@ "soaks up" anything.
>
> and then grep, noting that it has only a pattern and no file name, reads
> from standard input just like it always does.
I see. Thanks for pointing that out, I was about to replace ignorance 
with false understanding.
I thought I was expecting this to work:

      $ y () { echo "$1, $2, $3 "; }

      $ y one two three
     one, two, three

     $ echo "one two three" | y
     , ,                                                  << :-(


So grep is doing the 'switcheroo' here--going from reading arguments, to 
reading stdin, and
the pipe is the de facto 'stdin', and piped input does NOT become 
arguments :-)

Got it.

I'm doing this sort of thing now, and I'm as happy as a clam:

    function y ()
    {
         pipeinput='(nothing in the pipe)'
         terminalinput='(nothing from the terminal)'
         if [ ! -t 0 ];  then read pipeinput; fi
         if [ -n "$1" ]; then terminalinput="$@"; fi
         echo "$pipeinput $terminalinput"
    }

    $ y "from an antique land"
    (nothing in the pipe) from an antique land

    $ echo "I met a traveller" | y
    I met a traveller (nothing from the terminal)

    $ echo "I met a traveller" | y "from an antique land"
    I met a traveller from an antique land

    $ echo "I met a traveller" | y "from an antique land" | y "\nWho
    said: \"Two vast and trunkless legs of stone"
    I met a traveller from an antique land
    Who said: "Two vast and trunkless legs of stone


...

Who could ask for more transparent code? Thanks all for your patience.