From owner-freebsd-hackers  Sat Sep 27 23:07:28 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id XAA09739
          for hackers-outgoing; Sat, 27 Sep 1997 23:07:28 -0700 (PDT)
Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA09726
          for <hackers@FreeBSD.ORG>; Sat, 27 Sep 1997 23:07:05 -0700 (PDT)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id PAA04849;
	Sun, 28 Sep 1997 15:33:18 +0930 (CST)
Message-Id: <199709280603.PAA04849@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
cc: hackers@FreeBSD.ORG
Subject: Re: Timeout for sh(1) 'read' ?? 
In-reply-to: Your message of "Sun, 28 Sep 1997 07:34:30 +0200."
             <19970928073430.CC50911@uriah.heep.sax.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 28 Sep 1997 15:33:13 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Please don't introduce options with a different meaning than in ksh.
> ksh93 uses -d delim for an alternate line delimiter character than
> newline, and does not provide for a default value.

Ok.

> I see a need for the -t timeout parameter, since it's basically not
> possible to catch it otherwise without going through major hoops (due
> to shell-internal variable assignments that are required, so you can't
> e.g. easily employ a subshell).  However, assigning default values is
> something that is reasonably covered by things like:
> 
> 	$foo=${foo:-default}

Hmm.  Actually,  you would get the desired behaviour with 

val=${default}
read -t 5 val

because read won't have had a chance to modify 'val' if it does time 
out.  So should read return an error if it times out? What does ksh do?

> (Implementing -r)
> 
> > I could do with some guidance from people likely to be bitten by this; 
> > is such a major change in the name of POSIX worthwhile?
> 
> Well, it's hard to proclaim Posix conformance otherwise.  I thought
> that was one of our goals.  I doubt anybody would notice the change...

This is where I'm not so sure.  Naturally, POSIX is desirable (if 
stupid), I just don't want to get stomped for violating POLA.

mike