tinysh - tiny limited onscreen shell

[drauger]

Is there any alternative to waitforkey which reads state of a key and goes further without waiting for key pressing?

[geekmaster]

Originally Posted by drauger

Is there any alternative to waitforkey which reads state of a key and goes further without waiting for key pressing?

I did "waitforkey >/tmp/key &" which continues immediately, leaving waitforkey running in the background until a key is pressed, when it outputs the keypress value and quits. While waiting for a key, you can periodically check for a keypress in the main script with "key=$(cat /tmp/key)". You just need to get creative and try stuff...

[knc1]

Originally Posted by geekmaster

I did "waitforkey >/tmp/key &" which continues immediately, leaving waitforkey running in the background until a key is pressed, when it outputs the keypress value and quits. While waiting for a key, you can periodically check for a keypress in the main script with "key=$(cat /tmp/key)". You just need to get creative and try stuff...

Important Disclaimer for the following:
What the copy of busybox does that you might be using may vary from the following, you just have to try it to find out.

Every time you start a background job, that command __should__ return a "job id" number.

Then you can do other things, and when ready to proceed with the result of the background job, do a "wait <job id>".

Which will wait for the background job without the cpu overhead of a busy loop wait for the contents of /tmp/key to change. Where changes to /tmp/key is the expected result of the background job in this example case.

[geekmaster]

Originally Posted by knc1

Important Disclaimer for the following:
What the copy of busybox does that you might be using may vary from the following, you just have to try it to find out.

Every time you start a background job, that command __should__ return a "job id" number.

Then you can do other things, and when ready to proceed with the result of the background job, do a "wait <job id>".

Which will wait for the background job without the cpu overhead of a busy loop wait for the contents of /tmp/key to change. Where changes to /tmp/key is the expected result of the background job in this example case.

Wait is good when your parallel processing tasks are done and you want to wait in a blocking call for background task completion.

But waiting for a keypress this way would stop the foreground process indefinately (until or if a key ever gets pressed). I am doing animation with regular frame updates, so that is not an option. I prefer completing my update cycle, then waiting for a timer event (in a blocking call) until time to begin the next update cycle. A simpler way than timer events is to sleep ALMOST until time to begin the new update cycle, then sync to the timer with a "busy loop" (a/k/a. spinlock).

To conserve energy, you want to sleep as long as possible and busy-loop as short as possible. If you study video game source code, you will see that this is a very popular technique for controlling continuous interactive animation. This is what most of my demos do (see "usleep(K4DLY)"), which is followed in some code (removed from most published code for simplification) by a "while :;do" loop that calls my getmsec() function to continue at the exact millisecond to begin the next update cycle.

Waiting for a keypress as you suggested can be done a lot easier than calling "wait" with the process ID. You could just call "waitforkey" after your updates are complete and you are ready to wait for a key press.

There are useful reasons to use the "wait" function, but not using to convert a blocking waitforkey call (purposely forked to the background) BACK INTO a blocking waitforkey call is needless complicated, when you could have just called waitforkey in the foreground in the first place.

[drauger]

Originally Posted by geekmaster

I did "waitforkey >/tmp/key &" which continues immediately, leaving waitforkey running in the background until a key is pressed, when it outputs the keypress value and quits. While waiting for a key, you can periodically check for a keypress in the main script with "key=$(cat /tmp/key)". You just need to get creative and try stuff...

OK, let's try to be creative
This code will be executing untill you press DOWN key:

waitforkey 108 &
W=$!
while [[ $W == $(ps $W | grep $W | sed 's/pts.*//') ]] ; do
##some code##
done

I've written it to create clock that can be used as a screensaver - before I've realized that clock sitting in status bar is much better thing.

[MaPePeR]

Originally Posted by drauger

OK, let's try to be creative
This code will be executing untill you press DOWN key:

You could also do this with

while [[ `ps $W | wc -l` -eq 2 ]]

or

while pgrep -s $W > /dev/null

(kindle untested)

[hippy dave]

would it be feasible to adapt this to take keyboard input from the ssh session that it was run from, rather than the kindle's keyboard (or my kindle 4's lack-of-keyboard)?
i don't know much linux but i googled and fiddled with the script using a "read" command, but that only takes a whole line of text at a time and doesn't show up on the kindle screen until you press enter. any way to grab individual keystrokes?

[geekmaster]

There are some interesting ideas here:
http://www.etalabs.net/sh_tricks.html

Especially the "reading input byte-by-byte" which claims that "dd" is the only thing guaranteed to read a single byte, and the inline piping trick. You might also need to mess with the IFS environment var. And where they show "od" you probably need to use "hexdump" instead.

A good place to start anyway...

[hippy dave]

thanks!

[geekmaster]

Originally Posted by hippy dave

thanks!

It would probably be easier to write a little C program to do a getch(), then print its number value, then exit. It could be compiled with the tcc (tinycc) package in another thread (see the tools index wiki). That new "getchar" program could be called from a script to fetch a single ascii character on STDIN.

But that "cheat" would take all the fun out of these scripts that use only built-ins. If you use C, you may as well draw to the framebuffer in C for much faster speed.

My demo scripts are mostly for fun, like puzzle solving (but in a useful way).

[hippy dave]

cool, thanks again. this is a neat little demo. all i really want is a terminal running on my k4's screen that i can control from my computer's keyboard, but the various terminal options don't play nicely on the k4 at this point. i'm not much of a coder myself, can sometimes hack things a little to get what i'm after, but not sure where's the best starting point for this.

[geekmaster]

Originally Posted by hippy dave

cool, thanks again. this is a neat little demo. all i really want is a terminal running on my k4's screen that i can control from my computer's keyboard, but the various terminal options don't play nicely on the k4 at this point. i'm not much of a coder myself, can sometimes hack things a little to get what i'm after, but not sure where's the best starting point for this.

Check out the "eink algorithmic art scripts" thread for more things like tinysh. You can find it in the "Native" index wiki.

For a terminal for the K4, you need an onscreen keyboard. Check out JoppyFur's thread that has a terminal for the K5. You could make a hybrid that uses K3 type keyboard processing to move a cursor around an onscreen keyboard like the K5 uses. You need to replace the touchscreen code with 5-way joystick code, but it can be done...

[hippy dave]

yeah, would be good to have an onscreen keyboard as an option, but ideally i'd rather be able to use it remotely via my computer's real keyboard. basically setting the kindle up as a remote display for text editing and who knows what else.

[geekmaster]

Originally Posted by hippy dave

yeah, would be good to have an onscreen keyboard as an option, but ideally i'd rather be able to use it remotely via my computer's real keyboard. basically setting the kindle up as a remote display for text editing and who knows what else.

VNC would be better for that.

[hippy dave]

that would be good too, but also currently doesn't run on k4