Re: set -F kills read -t

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 18, 10:00pm, Ray Andrews wrote:
}
} Yeah ... I guess in my still synchronous and 'blocking' mind, when 
} there's a pipe there is *always* input so always 'available'.

Consider this silly example:

    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.

} ... in the case of:
} 
} echo "a string" | func
} 
} I hardly think that func should not politely wait for "a string"

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.

} >    mygrep() {
} >      print -u2 "Hi, I'm going to grep now."
} >      grep "$@"
} >    }
} 
} ... I see now how I've been barking up the wrong tree. It never even
} occurred to me that " $@ " would soak up piped input, I thought " $@ "
} stuff had to be arguments after the command <:-(

It's not actually the case that $@ "soaks up" anything.

   mygrep pattern file

expands to

  {
   print -u2 "Hi, I'm going to grep now."
   grep "pattern" "file"
  }

so grep reads from the file named "file", whereas

   mygrep pattern

expands to

  {
   print -u2 "Hi, I'm going to grep now."
   grep "pattern"
  }

and then grep, noting that it has only a pattern and no file name, reads
from standard input just like it always does.  If there's any magic here
at all, it's that the standard input of mygrep and the standard input of
grep are the same pipe.