Shell script to wait for user input from K3g keyboard

[geekmaster]

Originally Posted by knc1

For authors in the US, published in the US, my own personal preference is:
http://www.opensource.org/licenses/mit-license.html

That was my preference too, and I added the MIT license text from wikipedia to my code above.

[geekmaster]

Originally Posted by hawhill

In most cases, however, using third-party software will force me into the GPL one way or another. So lots of things I write end up being GPL.

I am not fond of the GPL because if I allow my code to become dependent on something bound by the GPL, I cannot use my code in a commercial product until I rewrite those portions (which can delay a project). The LGPL is annoying enough, with its "dynamically loaded library" requirement for commercial apps, but the GPL outright forbids commercial reuse.

This is a significant contributing factor to why I prefer coding "on the bare metal". It is a lot of extra work to find sample code from which to borrow that is NOT bound by the GPL. I often have to go back to the basic research and thesis papers and write my own code directly from their base concepts. This gets interesting when there is a lot of difficult mathematics involved. In my commercial code, I add URLs and book references for where I got my information, to prove that it is not legally encumbered. I cannot include GPL references.

[knc1]

Originally Posted by geekmaster

That was my preference too, and I added the MIT license text from wikipedia to my code above.

Thanks!
You can't be much clearer than that. Even I know what you mean.

[knc1]

Originally Posted by geekmaster

EDIT: I added the MIT license to the above script. I suppose I need to add it to my other published scripts and C programs now... And for that matter, is it even a LEGAL license if the copyright holder is identified by a pseudonym?

Now there is a good test question for students of some legal forum.

My layman's guess is "yes", since many printed books are published under a pseudonym.

For the prior musing...

I have seen people just include a reference in their signature to their intended license.

Something I often do myself is:

License Name, <link>, included wherein by reference.

(If you type small, you can get it on one line in the source. Which helps deal with the problem of the license text being longer than the code.)


But I am not an attorney licensed to practice law, so readers of this thread should make their own decision (or hire a legal decision).

[jmseight]

Hi Geekmaster,

Thank you very much for the code. I am trying to learn Linux script programming and this is very instructive, especially when I tried to modify it to do something a little different.

I noticed that any key pressed will be typed at the Kindle home screen as well. So typing and enter will cause a search to be performed. I substituted Aa as Enter.

I made some modification so it will display the string on the screen with a cursor and added the delete key.

I have not figured out how to get SPACE to work with this one.

BTW, is there a way to remove this behavior - so waitforkey does not type into the Kindle home screen?

Please see the below code - I am sure it can be optimized:

#!/bin/sh
#================================================= ==
# getkb - get translated ascii keys from K3 keyboard
# v1.2 by geekmaster
# STDOUT: pressed keys, until Enter key pressed.
#---------------------------------------------------
getkb() {
XP=$1
YP=$2
DN=/dev/null
KN="1234567890____qwertyuiop____asdfghjkl_____zxcv bnm_."
KS="1234567890____QWERTYUIOP____ASDFGHJKL_____ZXCV BNM_,"
KP="1234567890____~@#$%^&*()____<>[]{}?/\_____;:'|-+=_?"
KM=$KN
killall -stop cvm launchpad 2>$DN
ST=""
while :;do
eips $XP $YP $ST"_ "
L="_"
set $(waitforkey); K=$1 D=$2
[[ $D -eq 0 ]]&& continue
# [[ $K -eq 28 ]]&& break # enter
[[ $K -eq 190 ]]&& break # use Aa for enter
[[ $K -eq 14 ]]&& ST="$(echo ${ST%?})" && continue # del
[[ $K -eq 42 ]]&& KM=$KS && continue # shift
[[ $K -eq 126 ]]&& KM=$KP && continue # Sym
[[ $K -eq 57 ]]&& L=" " # space
[[ $K -le 52 ]]&& L="$(echo \"$KM\"|cut -b$K-$K)"
# [[ "$L" == "_" ]]&& L="($K)"
[[ "$L" == "_" ]]&& continue
# echo -n "$L"
ST="$(echo $ST$L)"
KM=$KN
done
echo "$ST"
echo ""
killall -cont cvm launchpad 2>$DN
}

[knc1]

One hint of something to check for in __any__ shell script -
The handling of whitespace.
More correctly, the handling of the "Input Field Seperator" character(s).

Often defined in the "IFS" variable and having the default of "space, tab, new-line" characters.

I can read where G.M. has dealt with space and new-line.
Perhaps tab (\x09) needs to be dealt with also?

Since this code is a shell function, and since most shell implementations recognize a function local setting of IFS -
Perhaps adding the pair of lines:

local IFS
IFS='some character you know will never show up in the key codes'

Will aid in dealing with the whitespace issues.

One hint about re-using G.M.'s function -

It is a function.
Add your code outside to the function and call the function from your added code passing the two expected parameters.

If running this function under Bash or Bash's sh mode -
You can pass any character (except \x00) by escaping it in the call.
I.E:
getkb $(printf '%q %q', parm-1, parm-2)
That will properly escape the two parameters at the point of the call and Bash's function argument processing will un-escape them.

For other sh implementations - a bit of experimenting might be required.

[knc1]

Originally Posted by jmseight

Hi Geekmaster,

Thank you very much for the code. I am trying to learn Linux script programming and this is very instructive, especially when I tried to modify it to do something a little different.

A good reference here:
http://tldp.org/LDP/abs/html/

[geekmaster]

@jmseight: The "killall" statements pause and resume the framework on my kindle, however some of the keypress events do remain in the keyboard input buffer so that after pressing Enter they show up in the search bar. I also had to pause the "launchpad" app I have running, or it "eats" spacebar presses.

I think there is a /proc to lock the keyboard for exclusive use, but that needs some research. The "myts" program locks the keyboard with with a C ioctl() call...

I was thinking about using a buffer string and supporting the Del key later (like you did), but I needed to stop for sleep when I was writing that.

Does "${ST%?}" work on the K3? A lot of other similar string processing that works on newer kindles does not work on the K3.

[[ $K -eq 14 ]]&& ST="$(echo ${ST%?})" && continue # del

For example, where I used ${ST:$K:1} on newer kindles I had to change to the older "echo|cut" for the K3 in this script. I will test the "%?" thing you did later when I get time...

[[ $K -le 52 ]]&& L="$(echo \"$KM\"|cut -b$K-$K)"

Question: Why are you using Aa for Enter?

# [[ $K -eq 28 ]]&& break # enter
[[ $K -eq 190 ]]&& break # use Aa for enter

The spacebar (keycode 57) worked for me:

[[ $K -eq 57 ]]&& L=" " # space

I think that this is eating your space:

ST="$(echo $ST$L)"

When passing parameters that may contain spaces, you should wrap them in quotes like this:

ST="$(echo \"$ST$L\")"

In this case, the escaped quotes become part of the echo command, and they protect any trailing space that is contained in the expansion of $L.

However in this particular case, why bother with an external command? Just do this instead:

ST="$ST$L"

[geekmaster]

Originally Posted by knc1

One hint of something to check for in __any__ shell script -
The handling of whitespace.
More correctly, the handling of the "Input Field Seperator" character(s).

Often defined in the "IFS" variable and having the default of "space, tab, new-line" characters.

I can read where G.M. has dealt with space and new-line.
Perhaps tab (\x09) needs to be dealt with also?

One of the FIRST things I tried was defining IFS, but the busybox in the touch had that jiggered such that I could not extract substrings with it. I ended up using ${string:start:length}, but then that did not work on the K3, so I ended up here with "echo|cut". You need to use whatever works, and I want simple code that is not locked to one specific kindle (this script is locked to the K3, for now, but that will change over time).

About handling the tab key, well that would add complexity to my "one page" script, with code that would never get used (the K3 does not have a tab key). Of course, you can make it as complex as you want, if you want to. Just add your name to the credits so I do not get all the blame.

Personally, before publishing, I like to strip out all unessential code, leaving only the elegant essence of the idea I am demonstrating... All the corner-case enhancements that add complexity ARE essential to some life-critical or mission-critical apps, but for demos or simple tools such as this, these safety features are better left out to aid understanding of the essential idea. IFS is one such unessential thing for here...

[jmseight]

Hi geekmaster,

Thank you for the hints. I am totally new at shell programming so am learning quite a bit from this. Thank you.

Does "${ST%?}" work on the K3? A lot of other similar string processing that works on newer kindles does not work on the K3.

>>>Yes. It works well.

[[ $K -eq 14 ]]&& ST="$(echo ${ST%?})" && continue # del

For example, where I used ${ST:$K:1} on newer kindles I had to change to the older "echo|cut" for the K3 in this script. I will test the "%?" thing you did later when I get time...

[[ $K -le 52 ]]&& L="$(echo \"$KM\"|cut -b$K-$K)"

Question: Why are you using Aa for Enter?

# [[ $K -eq 28 ]]&& break # enter
[[ $K -eq 190 ]]&& break # use Aa for enter

>>> If I used enter, then the Kindle home screen actually does a search of what I typed, and sometimes an annoying dialog box comes up. I find that Aa is more graceful.

The spacebar (keycode 57) worked for me:

[[ $K -eq 57 ]]&& L=" " # space

I think that this is eating your space:

ST="$(echo $ST$L)"

When passing parameters that may contain spaces, you should wrap them in quotes like this:

ST="$(echo \"$ST$L\")"

In this case, the escaped quotes become part of the echo command, and they protect any trailing space that is contained in the expansion of $L.

However in this particular case, why bother with an external command? Just do this instead:

ST="$ST$L"

>>> Got it. I did not know you can do this.

Best Regards,
James

[knc1]

Yup, looks like it gets stripped:

core2quad $ sh
$ ST="_ _" ; L=' ' ; ST="$ST$L" ; echo ${#ST}
4
$ ST="_ _" ; L=' ' ; ST="$(echo $ST$L)" ; echo ${#ST}
3

The same behavior will be seen where you try to return a string with a trailing IFS character at the end of the function, unless you escape the string.

Use the %q format to printf rather than echo to return a string that might have a trailing IFS character.

[knc1]

@G.M.

Not specifically to handle the "tab" key, but to handle the byte value \x09 as a keycode data value.

[jmseight]

Hi,

I tried
ST="$ST$L"

and whenever I hit the space things seems to get messed up so I cna no longer type anything else except Aa to terminate the script.

The echo command
ST="$(echo \"$ST$L\")"

also does the same thing, except a lot of " signs are added to the string.

Thanks,
JAmes

[geekmaster]

Originally Posted by jmseight

Hi,

I tried
ST="$ST$L"

and whenever I hit the space things seems to get messed up so I cna no longer type anything else except Aa to terminate the script.

The echo command
ST="$(echo \"$ST$L\")"

also does the same thing, except a lot of " signs are added to the string.

Thanks,
JAmes

Like I said, I did not test it. It was just something that *should* work. The problem is, many things that *should* work in these versions of busybox do not work as expected, requiring more tinkering than you would expect.

However, I just tried this on my K3:

# ST="abcdefg"
# L=" "
# ST="$ST$L"
# echo "($ST)"
(abcdefg )
#

Notice that the space was appended to ST as expected, so your problem must be in other code. Still, the quotes are needed to prevent chopping the trailing space off the string, like I said...

After looking at your code again, I see another problem:

eips $XP $YP $ST"_ "

really should be:

eips $XP $YP "$ST_ "

Otherwise, a space in ST will expand the 3rd parameter into a 3rd and 4th parameter that will make eips unhappy, giving an error message to STDERR. In linux, parameters that may contain spaces MUST be enclosed in quotes. It's the law! Fear it! (Only leave out quotes when you know you can get away with it, like I do.)

[jmseight]

Yep. The problem is in the eips. Thanks for the great help.

The following works:

eips $XP $YP "$ST""_ "

I can use this to type commands into the shell, correct?

eips 10 10 "Type command?"
S="$(getkb 10 11)"
sh < S

Is the last statement correct?

Thanks,
James