Re: About the coprocess article of the Bash man page
I'm sorry for late reply. I understand what the sentence means. Thank you. 2014-12-15 18:17 GMT+09:00 Eduardo A. Bustamante López : > Here 'terminated' is related to shell syntax, as in: 'the command line is > terminated by the & character' > > You can terminate commands with & ; \n ...
Re: read -t
Forgot to include mksh: | dualbus@hp ~ % mksh -c 'read -t 3' | afafafafafafa% | dualbus@hp ~ % afafafafafafa | zsh: command not found: afafafafafafa | dualbus@hp ~ % mksh -c 'read -t 3 -d d' | affafafafafafaf% | dualbus@hp ~ % affafafafafafaf | zsh: command not found: affafafafafafaf :-) 4 implementations, 4 different behaviors.
Re: read -t
I think the issue here is the inconsistent behavior of read -t when delim != '\n'. read -t 3 -d will *not* leave the input as typeahead. read -t 3 -d $'\n'will leave the input as typeahead. I tried playing with the 'unbuffered_read' variable in builtins/read.def (forcing it to be 1 even for delim == '\n'), but it seems that the special behavior for '\n' is further down the code. Also, this is how ksh93 and zsh behave: ksh93 behaves consistently (delim == or != to '\n') | dualbus@hp ...local/src/bash % /bin/ksh93 -c "false; read -t 3" | afafafafafafa% | dualbus@hp ...local/src/bash % /bin/ksh93 -c "false; read -d d -t 3" | afafafafafafa% zsh ignores -t when a custom -d is in effect, does the same thing as bash when delim == '\n' | dualbus@hp ...local/src/bash % /bin/zsh -c "false; read -t 3" | afafafafafafafafa% | dualbus@hp ...local/src/bash % afafafafafafafafa | zsh: command not found: afafafafafafafafa | dualbus@hp ...local/src/bash % /bin/zsh -c "false; read -d d -t 3" | afafafafafafafa | | d% bash leaves the input in some buffer when delim == '\n' and the timeout is reached. It consumes the input when delim != '\n'. | dualbus@hp ...local/src/bash % /bin/bash -c "false; read -t 3" | afafafafafaf% | dualbus@hp ...local/src/bash % afafafafafaf | zsh: command not found: afafafafafaf | dualbus@hp ...local/src/bash % /bin/bash -c "false; read -d d -t 3" | afafafafafafafaf% | dualbus@hp ...local/src/bash %
Re: read -t
Ok, that makes sense, but why doesn't it work if I change the delimiter? read -t 3 -d q *press random keys without pressing q* I think the same should happen here, I'm asking bash to read as much input as it can until it reads a q. Since I don't press q, whatever I typed should be used as typeahead. But that's not the case, and I don't understand why. 2015-01-04 17:21 GMT+01:00, Chet Ramey : > On 1/4/15 12:45 AM, isabella parakiss wrote: >> I'm trying to use read -t in an interactive shell >> >> read -t 3 *press random keys* >> >> Everything i press is now part of the next command in the prompt. >> It only happens when the delimiter is a \n. >> Is this intended? What's the point? > > It's difficult for me to tell what the question is here. You've asked > for bash to read as much input as it can until it reads a newline, with > the read aborted if you don't press a newline within three seconds. Since > you don't press newline, read(2) doesn't return anything and whatever > you've typed is left in the input buffer as typeahead for readline. When > readline is called, it is able to read all of the typeahead and use it as > part of the next input line. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer >``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ >
Re: read -t
On 1/4/15 12:45 AM, isabella parakiss wrote: > I'm trying to use read -t in an interactive shell > > read -t 3 *press random keys* > > Everything i press is now part of the next command in the prompt. > It only happens when the delimiter is a \n. > Is this intended? What's the point? It's difficult for me to tell what the question is here. You've asked for bash to read as much input as it can until it reads a newline, with the read aborted if you don't press a newline within three seconds. Since you don't press newline, read(2) doesn't return anything and whatever you've typed is left in the input buffer as typeahead for readline. When readline is called, it is able to read all of the typeahead and use it as part of the next input line. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
read -t
I'm trying to use read -t in an interactive shell read -t 3 *press random keys* Everything i press is now part of the next command in the prompt. It only happens when the delimiter is a \n. Is this intended? What's the point?
