GCC Issue

I’ve been attempting to compile the open-source database sqlite3 with GCC (4.1.2) on RISC OS (Raspberry Pi, to be precise). I can compile it successfully and get the shell program to run—however, the issue is that, if I backspace in the shell, instead of doing what I expect, ^H is generated instead.

The sqlite3 shell works correctly on Windows as well as Linux, so it’s unlikely to be something UNIX-specific; the code that reads a line uses fgets (since the shell can be set to accept input from a file), and the function that actually inputs a line is as follows:

/*
** This routine reads a line of text from FILE in, stores
** the text in memory obtained from malloc() and returns a pointer
** to the text.  NULL is returned at end of file, or if malloc()
** fails.
**
** If zLine is not NULL then it is a malloced buffer returned from
** a previous call to this routine that may be reused.
*/
static char *local_getline(char *zLine, FILE *in){
  int nLine = zLine==0 ? 0 : 100;
  int n = 0;

  while( 1 ){
    if( n+100>nLine ){
      nLine = nLine*2 + 100;
      zLine = realloc(zLine, nLine);
      if( zLine==0 ) return 0;
    }
    if( fgets(&zLine[n], nLine - n, in)==0 ){
      if( n==0 ){
        free(zLine);
        return 0;
      }
      zLine[n] = 0;
      break;
    }
    while( zLine[n] ) n++;
    if( n>0 && zLine[n-1]=='\n' ){
      n--;
      if( n>0 && zLine[n-1]=='\r' ) n--;
      zLine[n] = 0;
      break;
    }
  }
  return zLine;
}

Any suggestions? Is there an easy fix or do I need a different way of inputting a string?

A quick fix for a StrongED taskwindow is to edit the !StrongEd.Defaults.Modes.Taskwindow.Modefile
Change the line
Backspace ToTask
to
Backspace CharsToBuffer("<127>")

The RISC OS filer for one, does not work well with <127> replacing <8>, so it can’t be done system wide.
Finding where to tweak the unixlib recipe would be better in the long term, as this ^H problem affects other ports also.

Well, it’s a Unixlib problem—I created a small test program, and exactly the same happened; not with the -mlibscl option however, that was fine, but SQLite3 won’t compile with -mlibscl.

I’ve “fixed” the problem for the moment—in the test program at any rate—by replacing fgets with a routine my_fgets which uses fgets only if the source is not stdin, and makes use of OSLib where the source is stdin:

char* my_fgets(char* buffer, int len, FILE* f) {
      int used;
      if (f == stdin) {
         os_read_line32(buffer,len,0,255,0,&used);
         return buffer;
      }
      else
         return fgets(buffer,len,f);
}

It would be better if UNIXLib were fixed though.

Now to see if the fix works correctly in SQLite!

Well, this fix didn’t work as it stood (even though it appeared to in my test program) because fgets adds a LF character (ASCII 10) before the terminating NUL and the OS routine terminates strings with CR (ASCII 13). However, the final version of the routine shown here does work and SQLite3 is now running under RISC OS.

char* my_fgets(char* buffer, int len, FILE* f) {
      int used;
      int i;

      if (f == stdin) {
         os_read_line32(buffer,len-1,32,126,0,&used);
         buffer[used]=10;    /* mimic fgets--add LF */
         buffer[used+1]=0;   /* and terminating NUL */
      }
      else
         return fgets(buffer,len,f);
}

It just remains to package SQLite up in a RISC OS-friendly way and make it available.

The only thing I have found that seems to be related to Backspace is in the termios.h. I gathered from other sources that VERASE2 is referring to Backspace and ^H and the value I think should be in termios.c_cc[7]. I am not good enough at structs yet to know for sure wether I have been successfully changing the value, but I have had no change from outputting ^H so far. The function in sgtty.h allows a change in the delete key but that is of no use.

I’ve been attempting to compile the open-source database sqlite3 with GCC (4.1.2) on RISC OS (Raspberry Pi, to be precise). I can compile it successfully and get the shell program to run—however, the issue is that, if I backspace in the shell, instead of doing what I expect, ^H is generated instead.

I’ve been using the version of sqlite3 in the GCCSDK autobuilder for some time now. I’ve not noticed any problems with ^H appearing. I did reproduce the problem with !Edit running the Task window on a Raspberry Pi. Works OK with StrongED.
Do you get the same problem if you double-click the executable and run it single tasking?

I didn’t double-click it, but I did try running it from the window you get by pressing F12 (which I believe is single-tasking) and got the same result. The “fixed” version is fine though.

I had things back to front, this will assign the Backspace key to what the Delete key was doing, and gives the Delete key the function of kill, which turns out to be delete everything on that line.
#include <sgtty.h>
struct sgttyb sgbuf[255];
gtty(0,sgbuf);
sgbuf->sg_erase = 0x08;
sgbuf->sg_kill = 0x7f;
stty(0,sgbuf);

Please correct or improve my useage if you see what I’m trying to do.
I will try simply swapping the symbols in termios.h later, but this may have to be done in the GCC recipe for it to work.

After finding a book on the subject, I have found examples on termios struct useage and can correct my last effort.

struct sgttyb sgbuf;
        gtty(STDIN_FILENO,&sgbuf);
        sgbuf.sg_erase = 0x08; /*Backspace key*/
        sgbuf.sg_kill = 0x7f;  /*Delete key*/
        stty(STDIN_FILENO,&sgbuf);

I think the root of the original problem is not the ^H as such, (it /is/ the <8> key) but the terminal stdin was not set to do anything with it.

The sgtty.h method has few options, and I got a better result by using termios.h and struct termios like this:

#include <termios.h>
struct termios tcbuf;
       tcgetattr(STDIN_FILENO,&tcbuf);
       tcbuf.c_cc[VERASE] = 0x08; /* erase one char = Backspace */
       tcbuf.c_cc[VWERASE] = 0x7f; /* erase one word = Delete */
       tcbuf.c_cc[VKILL] = 0x15; /* erase line = ^U */
       tcbuf.c_cc[VREPRINT] = 0x12; /* reprint line = ^R */
       /* VERASE2 not functional */
       /*tcbuf.c_cc[VERASE2] = 0x7f; *//* erase one char = Delete */
       tcbuf.c_cc[VINTR] = 0x18; /* intr = ^X (taskwindow uses ^C) */
       tcsetattr(STDIN_FILENO,TCSANOW,&tcbuf);

On non-RISC OS platforms, Delete is forward-delete, not backspace — it only appears to be on RISC OS computers where it’s this way (possibly the original keyboards used didn’t have both keys?); isn’t it possible to make Delete be a forward-delete?

isn’t it possible to make Delete be a forward-delete?

You probably want Steve Fryatts PCKeys

David, the way I see it, this is very basic terminal io that is getting used here, it only recognises characters up to 127 so not only the arrow keys that would be needed for forward delete to be of use aren’t available, but that function isn’t supplied either. I think different platforms have implemented termios.h different ways so it may be possible to change functionality. I think ncurses style libraries are used when a terminal that is more than a command line is needed.
Also, I noted that running psftp in my sash shell that it had inherited the improvements I’d made to sash. So maybe a simple generic ncurses shell could be used to run command line ports without deploying ncurses on every port? The author of sash also has an easier lighter version of curses that I intend to look at sometime.
My RISC OS port of sash
(Updated with the code mentioned previously)

Would running it in a Nettle ANSI Taskwindow help?

Running ports that were printing ^H instead of doing a backspace was not being fixed by running it in a !Nettle ANSI Taskwindow. Maybe it is because it is not compiled with like for like unixlib. I’m unsure of how it is actually built though. The sash is done with unixlib and when executing another unixlib port, this port seems to be inheriting the features. (maybe because of fork taking a copy) !Nettle is doing a translation of ansi codes to a RISC OS window, so it probably departs from unixlib in a few areas. A Chox11/Desklib approach might keep things in the unixlib domain, but I doubt if it would work and display as nice.
Edit: !Nettle has a line editor option that does take control of entering a line to the display window.
BTW, the port of dpy-3.1 library has a demo that moves around and edits text in a !Nettle taskwindow, and may be helpful for building shells that can run in !Nettle. I haven’t looked at libncurses useage yet.
Further Edit: I haven’t used the Nettle line editor option much but it appears to be the only way to edit a command line for a running shell anyway Actually deletes etc are working, just not visible until hitting return or ^R (in sash anyway).
The printing of ^H to a display is a result from termios printing control characters that it hasn’t got mapped to a function. (The ^R reprint line function is doing both things though.) StrongEd Taskwindow can be configured to do something with this form, But it may be less confusing to configure the termios flag so that it doesn’t print control characters. When termios is communicating through a serial port to a remote terminal, it may become important to print control characters, I haven’t tried or needed to turn them off previously. I will try programming termios with STDOUT_FILENO set to see what happens.
I think the main change for a serial terminal is to not use one serial device name for input and output, I dont know how well the termios unblock flags etc will perform if at all.
Using the Nettle line editor, all line editting by the binary is gone and it enters a line to the running binary as a whole line (from the Nettle white field) Note for Steve and Dave: Nettle LineEditor does do forward delete