You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think this is probably a feature request rather than bugfix, but I'm hoping it can be done in a backwards compatible way.
I find it frequently useful to be able to differentiate "timeout" other causes of read failures. Example use case is reading escape sequences from the terminal/keyboard, where you need to differentiate standalone 'esc' from and 'escape sequence' - while also retaining the ability to detect EOF because the input closed.
On ksh, read returns '1' for most errors, ( from the code it seems like there should be others for signal induced read termination, but in practice I have not noticed it actually happen in scripts?? )
In particular, it returns both 1 for EOF and timeout ( when using read -t [tmout] )
I had a look at the code, and at first glance, it looks like modifying sh_exit() in read.c/timedout() would do it.. but in practice read.c/sh_readline() seems hit the final return jmpval, ignoring sh.exitval?
The code is a little beyond my meagre skills. A simple change of return jmpval to return sh.exitval combined with modifying timedout() as above, appears to do what I want, but I have no idea what else I might be breaking of if that's the right choice!
bash ( on my machine anyway ) - returns 1 for error, and 142 for timeout
Regardless of how the change is implemented ( and I'm assuming my actual approach is wrong? ),
given both 1 and 142 ( or whatever ) are both still failure codes, this shouldn't break the common while read... idioms - especially if read actually does sometimes return other codes for signal induced errors anyway?
Thankyou for your time - and the revived efforts on ksh in general!
The text was updated successfully, but these errors were encountered:
I think this is probably a feature request rather than bugfix, but I'm hoping it can be done in a backwards compatible way.
I find it frequently useful to be able to differentiate "timeout" other causes of read failures. Example use case is reading escape sequences from the terminal/keyboard, where you need to differentiate standalone 'esc' from and 'escape sequence' - while also retaining the ability to detect EOF because the input closed.
On ksh,
read
returns '1' for most errors, ( from the code it seems like there should be others for signal induced read termination, but in practice I have not noticed it actually happen in scripts?? )In particular, it returns both 1 for
EOF
and timeout ( when usingread -t [tmout]
)I had a look at the code, and at first glance, it looks like modifying
sh_exit()
inread.c/timedout()
would do it.. but in practiceread.c/sh_readline()
seems hit the finalreturn jmpval
, ignoringsh.exitval
?The code is a little beyond my meagre skills. A simple change of
return jmpval
toreturn sh.exitval
combined with modifyingtimedout()
as above, appears to do what I want, but I have no idea what else I might be breaking of if that's the right choice!bash ( on my machine anyway ) - returns 1 for error, and 142 for timeout
By making the changes above, I get..
Regardless of how the change is implemented ( and I'm assuming my actual approach is wrong? ),
given both 1 and 142 ( or whatever ) are both still failure codes, this shouldn't break the common
while read...
idioms - especially if read actually does sometimes return other codes for signal induced errors anyway?Thankyou for your time - and the revived efforts on ksh in general!
The text was updated successfully, but these errors were encountered: