ash busybox read command not working inside function....

Shell Programming and Scripting
1

I have a script that has to execute a read command in a function, this is in an ash busybox.

The code is...

trapcatch ()  { echo "Ctl-c Detected, what do you want to do?"   
echo "Please choose the number of one of the following options"   
echo "1.  Jump past this Set"   
echo "2.  Exit altogether"   
echo "Any other key or no key just continues"    

read -t 5 -p "Choose option 1-3 now : " KEYHIT    

case $KEYHIT in   

1*) echo "OK, I'll bypass this Set then"       
continue 2       
;;   

2*) echo "OK, I'll exit gracefully then"       
# need to add the graceful exit here       
exit 99       
;;   

*)  echo "OK I'll just carry on then......"       
;;   

esac    }

However the prompt in the read command is never appearing and indeed the script is just falling through to the 'OK I'll just carry on then...." option in case.

So it looks to me like the read command is not getting executed at all, however if I put the same read line in a separate stand alone busybox script it seems to work.

Could someone possibly explain why.

2

ash does not support the read -t BASH extension.

ash does not support the read -p BASH extension.

ash does not support functions.

You need to rewrite your script without these things if you want it to run in ash.

3

OK, I'm not arguing but.....

The function is getting called correctly else I wouldn't be getting to the CTR-c detected text.

The identical read statement is working perfectly in an ash busybox on the same machine, it's just not working inside the function. i.e. What I did was separate out just the read command to it's own script and tested it.

4

Show your entire code, then. It's probably the way the function's being called, redirections and such, preventing it from reading standard input.

5

[edit] Ignore that. Far too early in the morning. My apologies.

Also, thanks for teaching me things I didn't know about ash. I have confirmed that it supports all the things you show. It having functions makes it a much more useful shell than I realized.

6

Morning????

Bruddy Canucks :slight_smile:

I think your point about a redirect could be it though.....

I'm abit out of my comfort zone on the subtleties of redirects.

Could it be due to the fact that the function is getting called inside the loops that stops the read working?

So in a nutshell....

start loop 1

Lets pick which set were going to work on

start loop 2

lets collect and analyse the data from set chosen in loop 1 till we get a match or a terminating match.

now setup our Ctl-C function to allow us manual exit

end loop 2 - No matching conditions found yet so go round again.

end loop 1 - we've finished working on that set so let's pick another one.

7

I tested this snipplet on busybox 1.19.4 and it works as expected.

So as Corona688 requests, I also must ask how the trap is being called. If there are redirections affecting stdin, maybe read is operating on /dev/null, in which case, it would just carry on since that's your default case statement and KEYHIT would be null...

Edit: My reply took too long.. Is your loop operating as,

while ...; do
...
done <file

I wonder what read works on then? :smiley:

Maybe try read ... </dev/tty inside your trap

2 Likes
8

Yes, exactly, if that code is operating inside a loop like that, it will read from the file and not from the terminal. </dev/tty will always read from the terminal -- if you have a terminal, that is.

1 Like
9

Yes the loop 1 is while ....; do
.....
done < file

So I think you've cracked it.....the redirect is confused about where the read should come from!!

read < /dev/tty fixed it.

Thanks

The traps of loops and redirects when your handling live data streams.......

1 Like