Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11471

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

From Eric Blake <eblake@redhat.com>
Newsgroups gnu.bash.bug
Subject Re: Why does a Bash shell script write prompts followed by reads and do it right?
Date 2015-09-02 14:55 -0600
Organization Red Hat, Inc.
Message-ID <mailman.424.1441227338.19560.bug-bash@gnu.org> (permalink)
References <CAAykW6m4H2sSshWNfv3mQr9q6ScKzLebqMBgEo96vRUSBY6SAQ@mail.gmail.com> <1441218426.1517.2.camel@16bits.net> <CAAykW6mnTcLA21h79YDb_4-Pv3GhG_8xBhhNcG0unzYpkfqGMQ@mail.gmail.com> <20150902141935720946809@bob.proulx.com>

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: Why does a Bash shell script write prompts followed by reads and do it right? Eric Blake <eblake@redhat.com> - 2015-09-02 14:55 -0600

csiph-web