From: Thomas.Mcwilliams@f42.n377.z1.fidonet.org (Thomas Mcwilliams)
Newsgroups: comp.os.linux
Subject: Good comm program?
Date: Tue, 21 Jul 1992 00:01:00 -0800

Michael O'Reilly, In a message on 18 July wrote :

MO> xcomm has a nasty hack is the source (in some file that I forget)
that
MO> explicitly converts char 127 ---> char 8. This just needs fixing. If
you
MO> prefer I could upload the correct binaries.
                              ????????????????  

As the one who did the port of XC to Linux, and as the one who has
been maintaining it, please discuss this with me before uploading
any new binaries. It would be better for any "fix" to be coordinated
so that we are all on the same page, and can arrive at the best
solution.
Uploading a new binary will only break XC for those outside of VAX 
servers.

Allow me to offer you some background information, and then a proposed
solution. XC has been a standard comm program for Unix since about 1985
.
It has a long and interesting history. If ever there was a good
argument
for having freely available source code, XC belongs in that class. Some
of the original contributors to XC are now dead but their code still 
benefits us. The current overall maintainer is jpr@jpr.com.  

When I was porting XC over to Linux in the spring, several problems
presented themselves in the way Linux defines the backspace key.
Normally, under the C language and most other systems (the notable
exception being VAXen) the backspace key echoes '\b' ( '\08' ). The
delete character of course is '\177'.  XC has an internal line editor
and command parser which was confounded by the delete character being
echoed instead of backspace. In addition, when connected to a remote
non-VAX server, the delete causes all kinds of problems. I would have
liked to have had XC work "out of the box" but because of the Linux 
keyboard some changes had to be made to the command parser and line 
editor. In addition, sending the delete character when a backspace 
was expected also had to be changed. Quite frankly, getting XC to
work nicely under Linux was not a trivial task, every change has
its rhyme and reason. If you compile XC "out of the box" you will
indeed have your delete character but you won't have a line editor
or working command parser.

Most users who need the delete can change the erase character with 
the stty command at the remote. However, the converse is not true:
the stty command is not available to most people outside of their
own shell accounts.  Public information services don't generally 
give you this option.  In the world at large, most information 
servers don't know what to do with '\177'. And most Linux users 
have no option but to connect to non-VAX servers which predominate
public access systems.

I mentioned this in the docs, but only one other person has contacted
me on this point. My own opinion is that the Linux keyboard should be
setup to reflect the way the keys are actually labeled:

Let the <Backspace> key echo '\b' the backspace character.

Let the <Delete> key echo '\177' the delete character.

Logical right? The XC program has been with us for 7 years and on many
Unix systems. The fact that XC is setup with its own internal line
editor and command parser to interpret the backspace key as 
the backspace character leads me to conclude that it the Linux 
interpretation which is non-standard. Generally terminals that use
the delete character have it assigned to a key labeled "rubout". 
I think that Linux should use the <Delete> key as the "rubout/delete"
key and let the <Backspace> key echo '\b' as Comrade Lenin intended.
Others have posted comments about this in the past but I don't know
that there was any resolution. Most people would never notice it but
those porting various softwares will most definitely notice it
again, and have to deal with it in some fashion.

However, all that doesn't change the reality of what we have now.
What I propose to do is add the code to allow the interpretation of
the <Delete> character be settable at the command line or from
the init file like the other options. Does this sound ok to you?
I think this immediate solution is the most desirable rather than
different compile-time solutions proffered by the parochial interests
of the Deletenik and Backspacenik factions. The only elegant solution
involves changing the keyboard definitions. In that case XC would 
compile "out of the box" and (save for the broken xmodem module which
I also fixed) be quite usable "plain vanilla". Any thoughts?

Thomas

...
 * ATP/Linux 1.3bv * Thomas McWilliams (ARS KI4N)
                                           

 * Origin: The Slut Club -- 813-689-1150 (1:377/42.0)

Newsgroups: comp.os.linux