[gccsdk] ^H^H^H

Theo Markettos theo at markettos.org.uk
Sat Nov 7 12:36:34 PST 2015

On Fri, Nov 06, 2015 at 02:28:15PM +0000, David Gee wrote:
> In my view this is a bug in GCC SDK. It makes GCC all but useless for
> porting command line programs—it shouldn't be necessary to change the mode
> file just for this: Norcroft (unsurprisingly) works correctly—as does GCC
> on other platforms.
> This has been a "feature" for a long time—it's in GCC 4.1.2 too—and
> affects all task window managers that I've tried on RO 4.39 and 5.21. 
> Isn't it time it was fixed?

It's slightly complicated.  There is a code for backspace (ASCII 8, aka
Ctrl-H) and there is a code for Delete (127).  There has been an eternal
argument in Unix terminal circles which should be backspace and which should
be delete:

In Unix, you fix this in your termcap or with stty - ie you can configure it
on a per-terminal basis.  The reason you may wish to configure it is that if
you set Backspace=Delete then you can no longer tell the difference: this
might not be a problem for command line editing, but becomes more of an
issue for full-screen console programs where you want to pass keypresses
through unchanged and let the program deal with them.

In RISC OS, most task window managers are fairly feeble and don't do proper
terminal emulation, at best basic line editing.  Nettle is the only one that
emulates an actual named terminal (that I know about).  Also, there is no
equivalent of stty (to configure keystrokes on a per session basis), or
.profile (a script that sets your preferences afresh for every session where
you might put your stty settings), so you can't do per-session config, you
have to configure it on a global basis.  While it's possible to configure
UnixLib with unix$something variables, they aren't per-session, they're
the same for all sessions.

The SharedCLibrary, of course, hasn't a clue about terminals so is
unaffected by this.

So the danger is that fixing this for command line programs you will make
things worse for programs that do proper terminal handling.  If it gets
baked into UnixLib it's then impossible to disable if it does break

I don't pretend to understand the UnixLib terminal code however, so reserve
the right to be completely wrong, however.


More information about the gcc mailing list