A non-graphical OSCLI

(Updated because the previous version wouldn't run without a running ROLF server.)
(Updated again, Wed 9 June 2010, because of a bug in the interpreter, now built from revision 81.)

I've just put a Linux x86 executable to run command line RISC OS programs here (48785 bytes, md5sum 72db2104a71d0f2c5527dae1b0597fe3 48843 bytes, md5sum 5deb778bdbb5e7e1eef06fbc358f8bf8).

command_line_oscli is released under the GPL version 2.

To get it to run usefully, you will need a file called mimemap.txt containing at least the following three lines, in a directory whose name is stored in the environment variable
ROLF_RESOURCES:

application/x-riscos-absolute           Absolute        ff8     .ff8    .abs
application/x-riscos-module             RelocatableModule       ffa     .ffa
application/x-riscosobey                Obey            feb     .oby    .feb

RISC OS applications and modules will have to be "filetyped" appropriately by creating a hidden symbolic link to the mime type for the file named .filename,type

e.g.

ln -s application/x-riscos-module .SharedCLibrary,type

The source is available as revision 80 81 of the ro-lf project on
http://sourceforge.net/projects/ro-lf/develop.

The build command was:

gcc -DNO_DISASSEMBLE -DNO_GRAPHICS -DNO_FPE Libs/Compatibility/arm_emulator.c \
Libs/Compatibility/compatibility_switch.c External/Compatibility/oscli.c \
Libs/Environment/*.c -I Libs/Environment/includes/ -I Libs/Compatibility/includes/ \
-o command_line_oscli -std=gnu99 -lmagic

If Floating Point Emulation is needed, try not defining NO_FPE and including some more of the files from the Libs/Compatibility directory.

All the testing I've done was to run unmodsqz from !SqzUnSqz/Abs on CLib from the ROOL website and look to see that the file size had changed.

ln -s application/x-riscos-module .CLib,type
ln -s application/x-riscos-absolute .unmodsqz,type
( echo rmload .home.knoppix.Apps.\!Compatibility.SharedCLibrary
  echo run unmodsqz CLib ) | ./command_line_oscli

There's quite a lot of debug output to stderr (try 2> /dev/null) and the test ends with "Should do a handler function here", which means an unexpected SEGV trap was caught, but that's after the program has run.