Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we have different return codes for "timeout" vs "failed" for "read" #819

Open
TristanJamesBall opened this issue Jan 26, 2025 · 0 comments
Labels
1.1 Issue relevant to dev branch (v1.1.*) enhancement New feature or request

Comments

@TristanJamesBall
Copy link

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

# bash
# read -t 2 ; echo "Ret=[$?] REPLY=[$REPLY]"
Ret=[142] REPLY=[]
# ksh ( everwhere I've tested... All versions? )
# read -t 2 ; echo "Ret=[$?] REPLY=[$REPLY]"
Ret=[1] REPLY=[]

By making the changes above, I get..

# ksh - desired behaviour
# read -t 2 ; echo "Ret=[$?] REPLY=[$REPLY]"
Ret=[142] REPLY=[]

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!

@McDutchie McDutchie added the enhancement New feature or request label Jan 27, 2025
@McDutchie McDutchie added the 1.1 Issue relevant to dev branch (v1.1.*) label Mar 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.1 Issue relevant to dev branch (v1.1.*) enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants