>What, no takers? Come on, guys, that can't be normal for the read
>command to get stuck like that. After all, I've given it the timeout
>option, "read -t 1", which means, "In one second, read-or-not, be out
>of there!", does it not? There must be something I could do to avoid
>getting stuck like t
Stan Marsh wrote:
> >What, no takers? Come on, guys, that can't be normal for the read
> >command to get stuck like that. After all, I've given it the timeout
> >option, "read -t 1", which means, "In one second, read-or-not, be out
> >of there!", does it not? There must be something I could do to a
pourko--- via Bug reports for the GNU Bourne Again SHell
writes:
> What, no takers? Come on, guys, that can't be normal for the read command to
> get stuck like that. After all, I've given it the timeout option, "read -t 1",
> which means, "In one second, read-or-not, be out of there!", does it
What, no takers? Come on, guys, that can't be normal for the read command to
get stuck like that. After all, I've given it the timeout option, "read -t 1",
which means, "In one second, read-or-not, be out of there!", does it not?
There must be something I could do to avoid getting stuck like that
Greetings, you almighty problem-solvers!
I'll illustrate my problem with a couple of simple examples.
Let's set aside for the moment the reason for doing something like this:
fun1 () { local tty
if [ -t 1 ] ;then tty=1; elif [ -t 2 ] ;then tty=2; elif [ -t 0 ] ;then
tty=0; else return 1; fi
