Is it possible to execute a bash script from the SD card?

[godel10]

As far as I remember the DR is running under Linux, so yesterday I was wondering if it is possible to execute from the device (without the help of a computer) a bash script that is in the SD card.

Does anybody know the answer? If the answer is positive, how do you launch the script?

[Adam B.]

It's possible, just look at the installation script for the updated content browser with FBReader support.

[godel10]

Originally Posted by Adam B.

It's possible, just look at the installation script for the updated content browser with FBReader support.

Thanks for the answer. It seems that bash scripts work without any trouble.

Now my next question. Does anybody know how to create a bash script that asks the reader (i.e., an alternative way to the command "read") for some options (perhaps using somethink like the displayed keyboard that the device uses for the dictionary searches)?

[wallcraft]

I think what you are looking for is dmenu

dynamic menu is a generic menu for X

dmenu reads a list of newline-separated items from standard input and creates a menu. When the user selects an item or enters any text and presses Return, his/her choice is printed to standard output and dmenu terminates.

If dmenu could be made to work on the DR then lots of things could be done using scripts. There are probably more script coders out there than full application porters, so this might be a good thing. However, the "Unix" way would be to port a full terminal program and let everyone type in their own commands. No real reason why both a terminal and dmenu can't be available though.

[UtterInanity]

Please, somebody manage to port a terminal app. I've tried, but it's not as easy as it might seem. There was only one I got running, but the screen wouldn't refresh properly. (Had to pop up the menu to get anything to appear... but then the menu wouldn't disappear...) I've been meaning to add the screen refresh code I put into xournal in there, but have't gotten around to it. It was mrxvt, if anyone's interested in a starting point.

[Mackx]

Originally Posted by UtterInanity

It was mrxvt, if anyone's interested in a starting point.

I would be interested, I tried myself, but ran into a lot of problems. I also hope to learn from the steps you took until now.

[wallcraft]

Originally Posted by UtterInanity

It was mrxvt, if anyone's interested in a starting point.

On the DR1000S, if I understand Adam B.'s description correctly, the best choice is going to be a GTK+ based application because this library on the DR1000S includes built-in EInk page refresh support. The trick, though, is to find lightweight GTK+ applications. One possibility for a terminal is Sakura.

[Mackx]

Thanks for the link, I will give it a try.

[Mackx]

Sakura uses vte which is easy to compile for the DR (I used version 0.17.4) with Anjuta. It even has a small example application that uses the terminal widget of the vte-library.

So far for the good news ... I can start it (the little app of vte and sakura) on the emulator, but I do not see anything but a white block (black for sakura) and the keyboard. Entering 'exit' stops the program, entering 'ls >somefile' creates the file, so the terminal-part seems to work, but getting output on the screen is the challenge...

Any help is welcome

[Grimulkan]

Originally Posted by Mackx

Sakura uses vte which is easy to compile for the DR (I used version 0.17.4) with Anjuta. It even has a small example application that uses the terminal widget of the vte-library.

So far for the good news ... I can start it (the little app of vte and sakura) on the emulator, but I do not see anything but a white block (black for sakura) and the keyboard. Entering 'exit' stops the program, entering 'ls >somefile' creates the file, so the terminal-part seems to work, but getting output on the screen is the challenge...

Any help is welcome

Maybe Sakura uses custom GTK widgets (or doesn't use GTK widgets at all), I don't know if the iRex refresh hooks would work for them. Leafpad displays stuff fine, so we do know that apps like this should work. Could you try including the usual e-ink files (like you did with Xournal) and manually call the irex_display_update function (or a direct ioctl() call)? That way we can see if the trouble is in getting the display to refresh, or if for some reason there is nothing being drawn to the screen itself.

[Mackx]

Originally Posted by Grimulkan

Maybe Sakura uses custom GTK widgets (or doesn't use GTK widgets at all), I don't know if the iRex refresh hooks would work for them. Leafpad displays stuff fine, so we do know that apps like this should work. Could you try including the usual e-ink files (like you did with Xournal) and manually call the irex_display_update function (or a direct ioctl() call)? That way we can see if the trouble is in getting the display to refresh, or if for some reason there is nothing being drawn to the screen itself.

I experimented a little today, the problem is not with the refresh (I can do a ctrl-alt-1 on the qemu which does not help). I am not really sure what the problem is... more debugging to do ...

[Grimulkan]

Why not try it directly on the DR? There are some things that are not fully implemented on the emulator (I know some DBUS commands to sysd etc. don't work). Of course, the problem is probably something else altogether. Perhaps some library that compiled fine but barfs during runtime.

[Mackx]

There is some 'intelligence' deciding when to update the screen, which seems to decide never to update the actual widget. (In the expose-event via some function calls an gdk_window_invalidate_rect is called, which only results in a new expose-event. I have to debug the code a little more.)
After modifying to always update the widget, I could get something on the screen. However this is very slow. So next I tried on the DR, first time I started the batch file to install the ipk-file, I had to reset the DR since the 'wait'-dialog would not disapear (after 5 minutes). Trying a second time it seemed to work. The vte-application was copied to /usr/bin/ but after starting it nothing happened... more debugging to do...
A terminal window would have been handy ... ;-)

[Grimulkan]

Originally Posted by Mackx

[...]
After modifying to always update the widget, I could get something on the screen. However this is very slow.

You could try using one of the other waveforms to always update the widget. You used waveform 1 in the ioctl() call in your Xournal port, try doing exactly the same thing with waveform 6 (very very fast, but rounds off colors to either black or white), or waveform 9 (still fast, but rounds off colors to 4 shades instead of 16). Neither of these cause the screen to flicker like the 16 shade full refresh of waveform 1.

You can see waveforms 6 and 9 in action while entering text in a GTK text entry widget, while changing tabs in the settings dialog in FBReader or while toggling shift/caps on the Matchbox keyboard.

Originally Posted by Mackx

[...] A terminal window would have been handy ... ;-)

Lol, the old chicken and egg problem

[Mackx]

Most of the code in vte seems to be dedicated to translating characters and intelligent mechanism to get a responsive terminal even if you have several of them opened. On the emulator the problem is to get characters correctly on the screen. Most of them are printed as black rectangles unless you do an 'ls -R /media' after which the text is correctly visible on the emulator most of the time. The cursor is also not properly shown, so using vi is very difficult.
On the DR I did not get it to work at all. I am not sure if I can install it properly maybe some components are missing, but I am not getting any proper feedback.
So although VTE seems like a nice library to get ported on the DR, it is too difficult for me :-(. I will look for some easier libraries, maybe it is easier to port rxvt or mrxvt to gtk (for me). More experienced 'porters' could get a better look at it.

To Grimulkan: it is not a display refreshing problem that I have, it is more deep in the code somewere. I am not getting the correct things on the screen.