Re: Why does a Bash shell script write prompts followed by reads and do it right?

[Eric Blake]

On 09/02/2015 02:22 PM, Bob Proulx wrote:
> Robert Parker wrote:
>>         fputs(shortprompt, stdout);
>>         fflush(stdin);
> 
> Uhm...  fflush'ing stdin?  That doesn't make sense.

There is one case where fflush(stdin) is useful on a terminal: it lets
you discard any pending input.  For example, if you have just prompted
for a password and altered the tty to not echo what is typed, then
flushing stdin prior to reading the password is a nice step to ensure
that any accidental type-ahead data entered before the prompt doesn't
get mixed up with the password attempt, particularly since the lack of
echoing won't show the user that the password got munged.

Additionally, fflush(stdin) on a regular file is useful for applications
that might be used in a sequence of processes, and which have scenarios
where they only partially consuming input; POSIX requires that such
applications should reset the file pointer to the last byte actually
processed so that the next process starts processing at the next byte
rather than skipping ahead by however many bytes were cached early but
left unprocessed.  Example: { sed -n 1q; cat; } < file | ... - for the
'cat' to pass the remaining lines to the rest of the pipeline, the 'sed'
must rewind back to the end of the first line even if it read more than
that.

But in most coding scenarios, flushing stdin is rather rare; it wasn't
even well-specified by POSIX until 2012.

>  Obviously you
> meant to flush stdout.

And in the code snippet shown here, this observation is certainly correct.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature