Re: set -F kills read -t

[Ray Andrews <rayandrews@eastlink.ca>]

On 03/18/2014 06:17 PM, Bart Schaefer wrote:

Bart,
> Pardon me while I provide further evidence in support of the theorem that
> the best way to get the correct answer from the internet is to post the
> wrong answer.
Who's answer was wrong?
> (except of course that the size of the input is not predetermined).  If
> you cojole that C into a runnable program and try it, you'll find that
> it behaves just the way "read -t" does.  If you don't want that fcntl()
> in there, don't pass the -t option.
>   
Ok, then how else would one write a function that could use arguments 
*or* piped input? grep
does it, and doesn't need an arbitrary wait. Again, in *practice* the " 
-t 1 " seems perfectly good
enough, I don't want to belabour this, it's a theoretical/philosophical 
point only.
>
>    input=START
>    if read -t input
>    then print "I definitely read input: $input"
>    elif (( $#input ))
>    then print "Error, input unchanged: $input"
>    else print "End of file: $input"
>    fi
>
Ok, that  at least covers the bases if the read failed

> } Identical runs of identical code should produce identical results, no?
>
> No.  Consider for example:
>
>     for (( count=1; count <= 10000; count++ )) do
>       if read -t something
>       then print "GOT: $something"; break
>       fi
>       print $count
>     done
>
> This happily counts to 10000, stopping as soon as it gets input.  Exactly
> how many numbers are printed before it stops depends on when the input
> arrives.  Identical runs of identical code, but not identical results.
> If the most important thing is watching it count, then this is exactly
> what "read -t" is for.  If the important thing is "GOT: $something",
> then don't use -t.
Point made. That's well and good, I can see that " -t " would be exactly 
right in that situation, but in my
pipe situation, it's not exactly right.
> } Or at least warn you if that isn't going to happen. I appeal to the
> } doctrine of least surprise.
>
> I appeal to the documentation:
>
>      -t [ NUM ]
>            Test if input is available BEFORE ATTEMPTING TO READ.  ...
> 	  If no input is available, return status 1 AND DO NOT SET
> 	  ANY VARIABLES.
Yeah ... I guess in my still synchronous and 'blocking' mind, when 
there's a pipe there is
*always* input so always 'available'.  It will take some getting used to 
the idea that the
various steps in a long sequence of piped functions can quit any time 
they like in any
order that happens to happen.
>
> Consider what would happen if "echo" produced a gigabyte of output, or
> a terabyte, or a petabyte.  Where is all of that supposed to go while
> waiting for echo to return?  Do you always expect your web browser to
> download an entire video before beginning to play it?
A valid point. I have no issue that " -t [seconds to wait] " is 
available when needed, but in
the case of:

echo "a string" | func

I hardly think that func should not politely wait for "a string", and as 
my tests showed,
sometimes it didn't. I dunno, maybe there is no way that 'read' can be 
aware that
something to the left of it in a pipe situation has returned, so what 
I'm wanting might
be impossible. If it was possible it would be the '-p' switch: 'pipe 
mode' ... wait for piped
input to finish.
> } It's just a wrapper function. In this test case, around 'grep'.
>
> OK, but the wrapper must be doing *something*.  I mean, this is a
> wrapper around grep:
>
>    mygrep() {
>      print -u2 "Hi, I'm going to grep now."
>      grep "$@"
>    }
>
> This will perfectly happily read from a pipe, a file, or a file named
> in the arguments, without needing "read" at all.  So what exactly is
> your wrapper doing, such that it needs to consume standard input before
> grep does?
Yabut, in the pipe situation you don't supply a filespec ....

Shoot.  All this 'read' stuff has been a colossal mistake. Damn, 
everything I read on the
internet said 'read' was the way to go. HAAA, which get's back to your 
theorem! 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 <:-(

Sorry Bart, I'm a long study.