Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #27559 > unrolled thread

terminal designed for C

Back to article view | Back to comp.lang.c

Contents

  terminal designed for C kerravon <kerravon@w3.to> - 2012-10-22 21:19 -0700
    Re: terminal designed for C Robert Wessel <robertwessel2@yahoo.com> - 2012-10-22 23:34 -0500
      Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-22 21:56 -0700
    Re: terminal designed for C Sjouke Burry <s@b> - 2012-10-23 14:42 +0000
      Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-10-23 13:06 -0700
        Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-23 15:46 -0700
          Re: terminal designed for C Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-23 20:29 -0400
            Re: terminal designed for C Lew Pitcher <lpitcher@teksavvy.com> - 2012-10-23 21:26 -0400
            Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-24 02:59 -0700
              Re: terminal designed for C Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-24 14:15 -0400
              Re: terminal designed for C Lew Pitcher <lpitcher@teksavvy.com> - 2012-10-24 17:23 -0400
    Re: terminal designed for C Lew Pitcher <lpitcher@teksavvy.com> - 2012-10-23 18:55 -0400
      Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-10-23 19:56 -0700
      Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-24 16:10 -0700
        Re: terminal designed for C Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-24 20:15 -0400
        Re: terminal designed for C Lew Pitcher <lpitcher@teksavvy.com> - 2012-10-24 21:13 -0400
          Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-24 21:09 -0700
            Re: terminal designed for C "BartC" <bc@freeuk.com> - 2012-10-25 11:29 +0100
              Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-25 03:51 -0700
            Re: terminal designed for C James Kuyper <jameskuyper@verizon.net> - 2012-10-25 08:49 -0400
            Re: terminal designed for C Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-25 09:04 -0400
              Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-25 14:11 -0700
                Re: terminal designed for C Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-25 17:29 -0400
                  Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-26 03:33 -0700
                    Re: terminal designed for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-26 12:35 +0100
                      Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-26 15:46 -0700
                        Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-10-26 17:11 -0700
                          Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-26 17:27 -0700
                            Re: terminal designed for C Ian Collins <ian-news@hotmail.com> - 2012-10-27 13:39 +1300
                              Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-26 18:30 -0700
                                Re: terminal designed for C James Kuyper <jameskuyper@verizon.net> - 2012-10-26 22:50 -0400
                                  Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-10-27 01:42 -0700
                                    Re: terminal designed for C James Kuyper <jameskuyper@verizon.net> - 2012-10-27 19:18 -0400
                                    Re: terminal designed for C Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 10:48 -0800
                                      Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-12-17 12:27 -0800
                                        Re: terminal designed for C James Kuyper <jameskuyper@verizon.net> - 2012-12-17 15:51 -0500
                                          Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-12-17 13:35 -0800
                                            Re: terminal designed for C James Kuyper <jameskuyper@verizon.net> - 2012-12-17 16:48 -0500
                                        Re: terminal designed for C Robert Wessel <robertwessel2@yahoo.com> - 2012-12-17 14:53 -0600
                                        Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-12-17 13:20 -0800
                                        Re: terminal designed for C Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-20 10:19 -0800
                        Re: terminal designed for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-27 02:35 +0100
                          Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-26 18:58 -0700
                            Re: terminal designed for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-27 05:01 +0100
                          Re: terminal designed for C Robert Wessel <robertwessel2@yahoo.com> - 2012-10-27 00:56 -0500
                    Re: terminal designed for C James Kuyper <jameskuyper@verizon.net> - 2012-10-26 09:03 -0400
                    Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-10-26 11:13 -0700
                      Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-26 15:15 -0700
              Re: terminal designed for C lawrence.jones@siemens.com - 2012-11-12 18:08 -0500
    Re: terminal designed for C falk@rahul.net (Edward A. Falk) - 2012-10-24 17:29 +0000
    Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-10-24 11:55 -0700

Page 1 of 3  [1] 2 3  Next page →

#27559 — terminal designed for C

Hello folks.

According to the 1990 C standard (which is what I wish to code to), there is no "escape" character. So the only way to produce an escape character is to harcode its ASCII or EBCDIC value (x'1b'/x'27' respectively). I don't like doing that. I want to be able to write an editor like micro-emacs without having to have an #ifdef EBCDIC.

My conclusion is that I need to create a new type of terminal. Instead of having an ANSI terminal where ESC [ 2 J causes the screen to be cleared:

http://forum.codecall.net/topic/59142-how-to-clear-the-console-screen-with-ansi-any-language/

I instead want to replace the ESC with either a form feed, vertical tab or alert. All of these things are defined in 5.2.2 of the standard. But 5.2.1 of the standard says:

"control characters representing horizontal tab, vertical tab. and form feed."

ie there is no alert defined. So I guess that is ruled out. A reminder that my goal is an "ideal terminal from the C programmer's perspective".

I've never seen a vertical tab defined on a US keyboard, so I'm thinking that can be stolen for this purpose. But I would say that form feed is even more meaningless/useless when an escape sequence exists in order to clear the screen.

So would form-feed be the ideal character to steal?

Note that in order to maintain compatability with existing ANSI terminals, my plan is to get the operating system itself to convert form-feed (or whatever) characters into an ASCII/EBCDIC escape character. Note that form-feed is x'0c' in both ASCII and EBCDIC. I don't mind the operating system having some hard-coding in it to convert x'0c' to x'1b'/x'27'. I just don't want to see that in my application program (in this case my application program will be somewhat of a clone of micro-emacs).

Any room for conceptual improvement?

Note that the main target for this is PDOS/390, which can be found at http://pdos.sourceforge.net - ie this is intended to run in an EBCDIC environment being emulated on an ASCII machine. I will telnet into Hercules.

The short story is that I am happy that the people who wrote the ANSI terminal specification did a reasonable job, they just didn't quite cater for a portable C program to drive the terminal. So it's just a minor thing I want to change. Any name for the new ANSI-like terminal? I was thinking of PANSI/PANSY, the P coming from PDOS.

Thanks.  Paul.

[toc] | [next] | [standalone]

#27561

On Mon, 22 Oct 2012 21:19:19 -0700 (PDT), kerravon <kerravon@w3.to>
wrote:

>Hello folks.
>
>According to the 1990 C standard (which is what I wish to code to), there is no "escape" character. So the only way to produce an escape character is to harcode its ASCII or EBCDIC value (x'1b'/x'27' respectively). I don't like doing that. I want to be able to write an editor like micro-emacs without having to have an #ifdef EBCDIC.
>
>My conclusion is that I need to create a new type of terminal. Instead of having an ANSI terminal where ESC [ 2 J causes the screen to be cleared:
>
>http://forum.codecall.net/topic/59142-how-to-clear-the-console-screen-with-ansi-any-language/
>
>I instead want to replace the ESC with either a form feed, vertical tab or alert. All of these things are defined in 5.2.2 of the standard. But 5.2.1 of the standard says:
>
>"control characters representing horizontal tab, vertical tab. and form feed."
>
>ie there is no alert defined. So I guess that is ruled out. A reminder that my goal is an "ideal terminal from the C programmer's perspective".
>
>I've never seen a vertical tab defined on a US keyboard, so I'm thinking that can be stolen for this purpose. But I would say that form feed is even more meaningless/useless when an escape sequence exists in order to clear the screen.
>
>So would form-feed be the ideal character to steal?
>
>Note that in order to maintain compatability with existing ANSI terminals, my plan is to get the operating system itself to convert form-feed (or whatever) characters into an ASCII/EBCDIC escape character. Note that form-feed is x'0c' in both ASCII and EBCDIC. I don't mind the operating system having some hard-coding in it to convert x'0c' to x'1b'/x'27'. I just don't want to see that in my application program (in this case my application program will be somewhat of a clone of micro-emacs).
>
>Any room for conceptual improvement?
>
>Note that the main target for this is PDOS/390, which can be found at http://pdos.sourceforge.net - ie this is intended to run in an EBCDIC environment being emulated on an ASCII machine. I will telnet into Hercules.
>
>The short story is that I am happy that the people who wrote the ANSI terminal specification did a reasonable job, they just didn't quite cater for a portable C program to drive the terminal. So it's just a minor thing I want to change. Any name for the new ANSI-like terminal? I was thinking of PANSI/PANSY, the P coming from PDOS.


Is this a meaningful problem?  Is there actually a terminal
(presumably emulated) that actually implements *EBCDIC* ANSI escape
sequences?

Most EBCIDIC systems which allow the attachment of ASCII terminals
provide a considerable (and usually very clumsy) translation layer if
the application is to use EBCDIC, or pass through the ASCII unchanged,
in which case the translation needs to happen in the application.  And
most EBCDIC terminals are block mode devices, or line mode devices
with very, very different characteristics than typical ASCII
terminals.

Or am I missing something?

[toc] | [prev] | [next] | [standalone]

#27562

On Tuesday, October 23, 2012 3:34:57 PM UTC+11, robert...@yahoo.com wrote:
> 
> Is this a meaningful problem?  Is there actually a terminal
> (presumably emulated) that actually implements *EBCDIC* ANSI escape
> sequences?

My plan was for the EBCDIC operating system to assume
the existence of an EBCDIC ANSI/PANSY terminal. Then
it would be up to Hercules to translate the ASCII
telnet ANSI terminal into the required EBCDIC form, so
that the EBCDIC application has something to drive.

How else would you propose getting micro-emacs (or
similar) to run on the mainframe?

> Most EBCIDIC systems which allow the attachment of ASCII terminals
> provide a considerable (and usually very clumsy) translation layer if
> the application is to use EBCDIC

Yes, this is the route I intend to take.

> or pass through the ASCII unchanged,
> in which case the translation needs to happen in the application.

I do not wish to go this route. I think I have a fundamental
right to write an execution-character-set-neutral editor in C
without deviating from the C90 standard.

Which raises another point. I intend to make stdin/stdout
be IONBF, and leave them as text mode, since I don't think
there is a standard way to switch to binary mode.

> And most EBCDIC terminals are block mode devices, or line mode devices
> with very, very different characteristics than typical ASCII
> terminals.

Right. Which is why micro-emacs hasn't been implemented on
MVS for decades.

> Or am I missing something?

I intend to change decades of micro-emacs-less mainframes.
I have proposed a path to achieve that. I'm not aware of
a better path, but open to comment.

Thanks.  Paul.

[toc] | [prev] | [next] | [standalone]

#27578

kerravon <kerravon@w3.to> wrote in
news:90bcf5bb-f8e9-4ea2-9cbe-82110bfd059c@googlegroups.com: 

> Hello folks.
> 
> According to the 1990 C standard (which is what I wish to code to),
> there is no "escape" character. So the only way to produce an escape
> character is to harcode its ASCII or EBCDIC value (x'1b'/x'27'
> respectively). I don't like doing that. I want to be able to write an
> editor like micro-emacs without having to have an #ifdef EBCDIC. 
> 
> My conclusion is that I need to create a new type of terminal.
CUT
First you should get a keyboard with an enter key.
Then spend a few hours to learn to use it.

[toc] | [prev] | [next] | [standalone]

#27603

Sjouke Burry <s@b> writes:
> kerravon <kerravon@w3.to> wrote in
> news:90bcf5bb-f8e9-4ea2-9cbe-82110bfd059c@googlegroups.com: 
>> According to the 1990 C standard (which is what I wish to code to),
>> there is no "escape" character. So the only way to produce an escape
>> character is to harcode its ASCII or EBCDIC value (x'1b'/x'27'
>> respectively). I don't like doing that. I want to be able to write an
>> editor like micro-emacs without having to have an #ifdef EBCDIC. 
>> 
>> My conclusion is that I need to create a new type of terminal.
> CUT
> First you should get a keyboard with an enter key.
> Then spend a few hours to learn to use it.

Perhaps a let sarcastic approach would be more productive.

kerravon, the Google Groups interface is not well suited for
posting to Usenet.  One of its problems is that it doesn't make
it easy to write text in a suitable manner.  For a web interface,
it makes sense to write very long lines and let the web interface,
or your browser, wrap it for you.  For Usenet, it's better to post
with lines no longer than 80 columns; 72 or less is even better.
You have to insert explicit line breaks to do this.  (My newsreader,
for example, will wrap long lines, but not at word boundaries;
other news software may be even less friendly to very long lines.)

Google Groups has also recently started double-spacing quoted text,
which is *really* annoying.

You can work around this problem if you can compose your article
in a text editor that lets you do this, and then copy-and-paste it
into the Google Groups text window.  Or, better yet, get a real
Usenet newsreader (I use Gnus, which you'll like if and only if
you like Emacs) and an account on a free or cheap Usenet server
(I use eternal-september.org).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#27608

On Wednesday, October 24, 2012 7:16:57 AM UTC+11, Keith Thompson wrote:
> Sjouke Burry <s@b> writes:
> 
> > First you should get a keyboard with an enter key.
> > Then spend a few hours to learn to use it.
> 
> Perhaps a let sarcastic approach would be more productive.

Yes, I assumed that the other response was along the
lines of EBCDIC devices always operate in either line
mode or block mode, so stop trying to use character
mode, and learn to press enter to terminate text.

> or your browser, wrap it for you.  For Usenet, it's better to post
> with lines no longer than 80 columns; 72 or less is even better.

OK.

So any comment on the C90 not defining an escape
character, while ANSI terminals requiring an
escape character? Which computers did C90 have
in mind when they left out the escape character,
but included a vertical tab?

BFN.  Paul.

[toc] | [prev] | [next] | [standalone]

#27612

On 10/23/2012 6:46 PM, kerravon wrote:
> [...] Which computers did C90 have
> in mind when they left out the escape character,
> but included a vertical tab?

     I don't know "which computers," specifically, the Committee
was concerned about.  According to the Rationale, though:

	"Proposals to add '\e' for ASCII ESC ('\033') were not
	adopted because other popular character sets have no obvious
	equivalent (see §6.4.4.4.)"

and

	"The C89 Committee considered proposals to add the character
	constant '\e' to represent the ASCII ESC ('\033') character.
	This proposal was based upon the use of ESC as the initial
	character of most control sequences in common terminal driving
	disciplines such as ANSI X3.64. However, this usage has no
	obvious counterpart in other popular character codes such as
	EBCDIC."

     At least some versions of EBCDIC feature a control character
named ESC, and I think you can safely assume the Committee was aware
of this.  I do not know their reasons for declaring that EBCDIC/ESC
was not an "obvious counterpart" for ASCII/ESC -- but then, I'm not
a character-set expert.  On the evidence at hand, neither are you.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#27613

On Tuesday 23 October 2012 20:29, in comp.lang.c,
esosman@comcast-dot-net.invalid wrote:
[snip]
> 
>      At least some versions of EBCDIC feature a control character
> named ESC, and I think you can safely assume the Committee was aware
> of this.  I do not know their reasons for declaring that EBCDIC/ESC
> was not an "obvious counterpart" for ASCII/ESC -- but then, I'm not
> a character-set expert.  

And neither am I. But, long ago, I dealt with characterset issues as part of
my job.  :-)

ISTM that, in ASCII, the use of the ESC character has mutated from the
original "characterset selector" (as in ISO 2022) used to select which
glyphs would activate following an SO or SI control character to a more
generic purpose that includes format effectors (like display controls and
cursor positioning controls) and vendor-specific extensions.

OTOH, IBM control characters have never strayed very far from their BSC and
3270 roots, and didn't seem to have any use for ESCape as a characterset
selector (using their "GE" Graphic Escape for that purpose - see the "3270
Data Stream Programmer's Reference" and others for details). AFAIK, there
was no teleterminal use for the EBCDIC ESCape character at all. 

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#27622

On Wednesday, October 24, 2012 11:29:28 AM UTC+11, Eric Sosman wrote:

A truly great response - thanks Eric!

> 	"The C89 Committee considered proposals to add the character
> 	constant '\e' to represent the ASCII ESC ('\033') character.
> 	This proposal was based upon the use of ESC as the initial
> 	character of most control sequences in common terminal driving
> 	disciplines such as ANSI X3.64. However, this usage has no

The exact situation I face.

> 	obvious counterpart in other popular character codes such as
> 	EBCDIC."

> of this.  I do not know their reasons for declaring that EBCDIC/ESC
> was not an "obvious counterpart" for ASCII/ESC -- but then, I'm not
> a character-set expert.  On the evidence at hand, neither are you.

I am using as reference the IBM S/370 reference summary
4th edition dated November 1976 (ie more than a decade
before C90).

It has an ESC at position x'27'.

I have never seen an EBCDIC ESC used for anything though.

I wonder what it all means?

BFN.  Paul.

[toc] | [prev] | [next] | [standalone]

#27639

On 10/24/2012 5:59 AM, kerravon wrote:
> On Wednesday, October 24, 2012 11:29:28 AM UTC+11, Eric Sosman wrote:
>
> A truly great response - thanks Eric!
>
>> 	"The C89 Committee considered proposals to add the character
>> 	constant '\e' to represent the ASCII ESC ('\033') character.
>> 	This proposal was based upon the use of ESC as the initial
>> 	character of most control sequences in common terminal driving
>> 	disciplines such as ANSI X3.64. However, this usage has no
>
> The exact situation I face.
>
>> 	obvious counterpart in other popular character codes such as
>> 	EBCDIC."
>
>> of this.  I do not know their reasons for declaring that EBCDIC/ESC
>> was not an "obvious counterpart" for ASCII/ESC -- but then, I'm not
>> a character-set expert.  On the evidence at hand, neither are you.
>
> I am using as reference the IBM S/370 reference summary
> 4th edition dated November 1976 (ie more than a decade
> before C90).
>
> It has an ESC at position x'27'.
>
> I have never seen an EBCDIC ESC used for anything though.

     Perhaps that's why the C89 Committee didn't deem EBCDIC/ESC
an "obvious counterpart" to ASCII/ESC: The fact that two control
codes have the same three-letter name doesn't mean they have
similar or even comparable significance.  An EBCDIC table on
Wikipedia lists 001B as the "Unicode equivalent" of EBCDIC ESC,
meaning that whoever prepared the table thought there was a
correspondence, but perhaps the C89 Committee deemed Wikipedia
an insufficiently authoritative source.  (At the time, they
probably also considered Wikipedia too new to be trusted. :)

> I wonder what it all means?

     One thing I think it means is that if you want to drive
X3.64 terminals from EBCDIC-based systems, you'd better find
out from those systems' experts how it's done.  It's possible
that system software would notice \x27 being written and say
"Hey, that's an EBCDIC ESC, and I happen to know it's going to
an X3.64 device that expects ASCII ESC; I'll send \x1B instead."
But it seems more likely that the system would provide some
kind of curses-like facility, allowing the application to be
mostly unaware of the type of terminal hardware in use.  The
abstract model presented by such a library (assuming it exists)
would be a candidate for your "terminal designed for C."

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#27649

On Wednesday 24 October 2012 05:59, in comp.lang.c, kerravon@w3.to wrote:

[snip]
> I am using as reference the IBM S/370 reference summary
> 4th edition dated November 1976 (ie more than a decade
> before C90).

Gak! You get a peek at a generic EBCDIC from the "yellow card"
(the "Reference Summary"), you really cannot use that as a reference for
programming for EBCDIC-based terminals.

What the OP needs is something like the "3270 Data Stream Programmers
Reference" available at publibz.boulder.ibm.com (see [1] below for the
overlong URL) that describes exactly how to interact programmatically with
the "standard" IBM EBCDIC-based terminal.

> It has an ESC at position x'27'.
> 
> I have never seen an EBCDIC ESC used for anything though.
> 
> I wonder what it all means?

It likely is so that EBCDIC-based systems could properly converse with
ASCII-based systems and devices through a simple EBCDIC-to-ASCII
translation table. EBCDIC program sends EBCDIC ESC, which the translator
translates to an ASCII ESC, and the end ASCII device/program reads as an
ESC. IBM didn't seem to ascribe a meaning to the ESC character other
than "escape" in any document I've read.

[1] "3270 Data Stream Programmers Reference"
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CN7P4000/CCONTENTS?DT=19920626112004

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#27610

On Tuesday 23 October 2012 00:19, in comp.lang.c, kerravon@w3.to wrote:

> Hello folks.
> 
> According to the 1990 C standard (which is what I wish to code to), there
> is no "escape" character. So the only way to produce an escape character
> is to harcode its ASCII or EBCDIC value (x'1b'/x'27' respectively). I
> don't like doing that. I want to be able to write an editor like
> micro-emacs without having to have an #ifdef EBCDIC.
> 
> My conclusion is that I need to create a new type of terminal. 

Having written code on EBCDIC-based mainframe systems for many years, and
with both hardcopy and video terminals for even more years, I gotta say,
you /are/ ambitious, aren't you.

Some things to think about (none of them C related)

1) EBCDIC is a "family" of related but slightly-differing charactersets.
While I believe that most of the EBCDIC control characters are common to
all of the EBCDIC charactersets, I don't remember the details. You should,
perhaps, specify /which/ EBCDIC you intend to deal with, and/or research to
determine that the control characters you select are common to the EBCDIC
charactersets you intend to work with.

2) EBCDIC terminals don't act like ASCII terminals. IBM defined them as
a "block oriented" device, taking a specific set of (already predefined)
commands, that are /nothing/ like the ANSI escape sequences you already
know. On such a terminal, each printing position is paired with a second,
control, octet, which governs the form and function of that position
(readable, writable, colour, intensity, etc.) Terminals are read and
written screen at a time (up to 4000 characters at a time (80x25x2),
including the non-data "status line", depending on those paired control
bytes).  The equivalent to the ANSI "clear screen" escape sequence is a
full screen block (80x25) of non-rereadable blanks.

3) On most ASCII-based terminals, the ASCII "form feed" (FF) character will
clear the screen. It does not guarantee the cursor position. Alternatively,
a series of ASCII "line feed" characters will also clear such a screen,
again without guarantee of cursor position. Neither is acceptable on a
hardcopy terminal.

4) I seriously doubt that you will actually "create a new type of terminal".
Is hardware your specialty? And do you have a market? You probably mean
that you want to write some sort of "terminal emulator". This isn't easy,
but it isn't difficult either. You /do/ need a hardware terminal to target
to; you need something to display on, and you have to build your emulator
to interpret input and write or read on the hardware.

5) This seems all to 1990's for me. You are running at least 30 years behind
the times; this has all been done before, many times over. Perhaps you need
to look into prior art.

HTH
-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#27616

Lew Pitcher <lpitcher@teksavvy.com> writes:
[...]
> 3) On most ASCII-based terminals, the ASCII "form feed" (FF) character will
> clear the screen.
[...]

That doesn't seem to be the case.

I haven't used an ASCII-based *terminal*, as opposed to a terminal
emulator, in years.  But most terminal emulators, and probably
most actual terminals, are VT-100 compatible -- and a form feed
character, as far as I can tell, doesn't clear the screen.  In the
several emulators I've tried, it either does nothing or moves the
cursor down one line.

A working clear-screen sequence is "^[[H^[[2J", where "^[" denotes the
ASCII Escape character.

The comp.lang.c FAQ <http://www.c-faq.com/>, in question 19.4, says that
form-feed "will cause some displays to clear".

(Incidentally, a commonly suggested portable solution is to print enough
newlines to scroll everything of the top of the display.  Drawbacks of
this approach are: (1) it's hard to tell how many newlines are needed;
(2) the cursor is left at the bottom of the screen, and (3) text can
still be seen by scrolling up, which is a problem if you want to erase
sensitive information.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#27654

On Wednesday, October 24, 2012 9:55:29 AM UTC+11, Lew Pitcher wrote:
> Having written code on EBCDIC-based mainframe systems for many years, and
> with both hardcopy and video terminals for even more years, I gotta say,
> you /are/ ambitious, aren't you.

I've been doing other similar changes to the mainframe
platform, like making the RDW come through in RECFM=VB
when opened in binary mode, and reading and writing NL
characters to RECFM=U in text mode. This is a divergence
from how IBM did it. I think IBM got it wrong.

> 1) EBCDIC is a "family" of related but slightly-differing charactersets.
> While I believe that most of the EBCDIC control characters are common to
> all of the EBCDIC charactersets, I don't remember the details. You should,
> perhaps, specify /which/ EBCDIC you intend to deal with, and/or research to
> determine that the control characters you select are common to the EBCDIC
> charactersets you intend to work with.

This one is easy - the Yellow Card has the definitive
reference.

> 2) EBCDIC terminals don't act like ASCII terminals. IBM defined them as
> a "block oriented" device, taking a specific set of (already predefined)
> commands, that are /nothing/ like the ANSI escape sequences you already
> know. On such a terminal, each printing position is paired with a second,
> control, octet, which governs the form and function of that position

I am roughly familiar with the 3270 data stream, and as
per original post, I don't want a 3270 data stream. I'm
trying to implement micro-emacs. So a new terminal type
is required.

> 3) On most ASCII-based terminals, the ASCII "form feed" (FF) character will
> clear the screen. It does not guarantee the cursor position. Alternatively,
> a series of ASCII "line feed" characters will also clear such a screen,
> again without guarantee of cursor position. Neither is acceptable on a
> hardcopy terminal.

I am specifically dealing with an ANSI X3.64 terminal (or
close), which is not required or designed to react to the
form feed.

> 4) I seriously doubt that you will actually "create a new type of terminal".
> Is hardware your specialty? And do you have a market? You probably mean
> that you want to write some sort of "terminal emulator". This isn't easy,
> but it isn't difficult either. You /do/ need a hardware terminal to target
> to; you need something to display on, and you have to build your emulator
> to interpret input and write or read on the hardware.

I wish to posit the existence of an EBCDIC-equivalent of
an ANSI X3.64 terminal, which I will then drive from the
EBCDIC application.

> 5) This seems all to 1990's for me. You are running at least 30 years behind
> the times; this has all been done before, many times over. Perhaps you need
> to look into prior art.

If it has been done many times over, and given that
micro-emacs is open source, where can I download a
pre-compiled micro-emacs binary for MVS?

Regarding being 1990s - I am not yet satisfied that
1990s has been done properly. There are computer
systems in existence where a computer programmer
does not even have C90 available. Only very recently
(2011) has a free C90 compiler been made available
on every commercial platform, the last nail in the
coffin being z/VSE. Now that C90 is a universal
language for computers, the next thing bugging me is
a universal editor. When I was complaining about the
different editors on the different systems circa
1988, somebody told me I was in desperate need of
micro-emacs. I went and got micro-emacs for MSDOS
and still use it today (well, Windows command line
version anyway). But I don't have it for the
mainframe. I'm willing to replace MVS with PDOS if
that's what it takes to get micro-emacs working on
the mainframe.

BFN.  Paul.

[toc] | [prev] | [next] | [standalone]

#27658

On 10/24/2012 7:10 PM, kerravon wrote:
> On Wednesday, October 24, 2012 9:55:29 AM UTC+11, Lew Pitcher wrote:
>> Having written code on EBCDIC-based mainframe systems for many years, and
>> with both hardcopy and video terminals for even more years, I gotta say,
>> you /are/ ambitious, aren't you.
>
> I've been doing other similar changes to the mainframe
> platform, like making the RDW come through in RECFM=VB
> when opened in binary mode, and reading and writing NL
> characters to RECFM=U in text mode. This is a divergence
> from how IBM did it. I think IBM got it wrong.
>
>> 1) EBCDIC is a "family" of related but slightly-differing charactersets.
>> While I believe that most of the EBCDIC control characters are common to
>> all of the EBCDIC charactersets, I don't remember the details. You should,
>> perhaps, specify /which/ EBCDIC you intend to deal with, and/or research to
>> determine that the control characters you select are common to the EBCDIC
>> charactersets you intend to work with.
>
> This one is easy - the Yellow Card has the definitive
> reference.

     Pfui.  There's a green card somewhere in a box in my attic.
Vintage 1968 or thereabouts.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#27662

On Wednesday 24 October 2012 19:10, in comp.lang.c, kerravon@w3.to wrote:

> On Wednesday, October 24, 2012 9:55:29 AM UTC+11, Lew Pitcher wrote:
>> Having written code on EBCDIC-based mainframe systems for many years, and
>> with both hardcopy and video terminals for even more years, I gotta say,
>> you /are/ ambitious, aren't you.
> 
> I've been doing other similar changes to the mainframe
> platform, like making the RDW come through in RECFM=VB
> when opened in binary mode, and reading and writing NL
> characters to RECFM=U in text mode. This is a divergence
> from how IBM did it. I think IBM got it wrong.
> 
>> 1) EBCDIC is a "family" of related but slightly-differing charactersets.
>> While I believe that most of the EBCDIC control characters are common to
>> all of the EBCDIC charactersets, I don't remember the details. You
>> should, perhaps, specify /which/ EBCDIC you intend to deal with, and/or
>> research to determine that the control characters you select are common
>> to the EBCDIC charactersets you intend to work with.
> 
> This one is easy - the Yellow Card has the definitive
> reference.

Only if you are dealing with (IIRC) IBM-1047 EBCDIC. It doesn't cover the
other EBCDICs, like EBCDIC-US or EBCDIC-INT, although these variants share
many common codepoints with the EBCDIC documented on the Yellow Card.

>> 2) EBCDIC terminals don't act like ASCII terminals. IBM defined them as
>> a "block oriented" device, taking a specific set of (already predefined)
>> commands, that are /nothing/ like the ANSI escape sequences you already
>> know. On such a terminal, each printing position is paired with a second,
>> control, octet, which governs the form and function of that position
> 
> I am roughly familiar with the 3270 data stream, and as
> per original post, I don't want a 3270 data stream. I'm
> trying to implement micro-emacs. So a new terminal type
> is required.

Then, why worry about EBCDIC at all? Programs running on modern IBM systems
can use ASCII (under the POSIX subsystem), and can talk to ASCII devices
using TCP/IP. The only case I can think of where you'd /want/ to talk
EBCDIC is when your code talks to an EBCDIC-based terminal device, and that
pretty much requires you to talk 3270 data stream (there aren't any other
EBCDIC terminals to speak of).

But, this is your project. I expect that you know what you are doing wrt
talking EBCDIC.

>> 3) On most ASCII-based terminals, the ASCII "form feed" (FF) character
>> will clear the screen. It does not guarantee the cursor position.
>> Alternatively, a series of ASCII "line feed" characters will also clear
>> such a screen, again without guarantee of cursor position. Neither is
>> acceptable on a hardcopy terminal.
> 
> I am specifically dealing with an ANSI X3.64 terminal (or
> close), which is not required or designed to react to the
> form feed.

So, an external EBCDIC-to-ASCII translation layer? And the target program
(on an EBCDIC machine) talks EBCDIC to the translation layer, letting that
layer talk ASCII to the target terminal? OK, sounds cumbersome, but OK.

WRT an EBCDIC version of your program, it sounds like the translation layer
will have to translate outbound EBCDIC FF characters into the proper
ASCII "clear screen and reset cursor" ANSI sequence. That's ok; the
translation layer will need some intelligence; interpreting escape
sequences and such (does x'270c' represent a nonprintable, nonactionable
character, followed by a formfeed, or does it represent a two character
escape sequence that does something other than formfeed?). Of course,
that's your decision as well.

>> 4) I seriously doubt that you will actually "create a new type of
>> terminal". Is hardware your specialty? And do you have a market? You
>> probably mean that you want to write some sort of "terminal emulator".
>> This isn't easy, but it isn't difficult either. You /do/ need a hardware
>> terminal to target to; you need something to display on, and you have to
>> build your emulator to interpret input and write or read on the hardware.
> 
> I wish to posit the existence of an EBCDIC-equivalent of
> an ANSI X3.64 terminal, which I will then drive from the
> EBCDIC application.

OK, a new type of terminal emulator, then. One that uses EBCDIC characters
but acts like an ANSI x3.64 terminal. But, my point was that terminals need
a physical existence; a "screen" on which to display characters, and
a "keyboard" from which to retrieve characters to send to the mainframe.
Are you building a new ANSI x3.64 terminal, one that uses EBCDIC instead of
ASCII, or are you front-ending an existing terminal with an EBCDIC-to-ASCII
translator? The simpler approach would be to build the translator, and use
someone else's X3.64 terminal (or software terminal), but you /could/
actually be building a complete software terminal, or (heaven forbid) a
complete hardware terminal. A much harder task.

>> 5) This seems all to 1990's for me. You are running at least 30 years
>> behind the times; this has all been done before, many times over. Perhaps
>> you need to look into prior art.
> 
> If it has been done many times over, and given that
> micro-emacs is open source, where can I download a
> pre-compiled micro-emacs binary for MVS?

Hmmmmm....  I've been out of the mainframe world for a few years, but I can
guess....

How about http://www.jasspa.com/download.html, compiled and run under either
a Linux LPAR or the Unix System Services component of MVS. It should work;
IBM's been supporting Unix on MVS since the late 1990's, and MVS-managed
Linux since the early 2000s.

Other than that, there are a number of commercial sites who offer (or
offerred) Unix programs for MVS; Mortice Kern used to offer such, although
they seem to be out of business now.

Heck, even IBM offers emacs free for MVS (zOS, actually)
http://www-03.ibm.com/systems/z/os/zos/features/unix/tools/


> Regarding being 1990s - I am not yet satisfied that
> 1990s has been done properly.

Amen to that, brother. 

> There are computer 
> systems in existence where a computer programmer
> does not even have C90 available.

I feel your pain. Once, I tried to get a Perl CPAN package installed on a
development AIX box without a C compiler. I couldn't even convince them to
install GCC, and had to develop my solution on a Linux-based laptop
instead.

> Only very recently 
> (2011) has a free C90 compiler been made available
> on every commercial platform, the last nail in the
> coffin being z/VSE.

I used to work (System Programmer) on DOS/VSE, VSE/SP, and VSE/ESA. I moved
on before it became z/VSE.

> Now that C90 is a universal 
> language for computers, the next thing bugging me is
> a universal editor. When I was complaining about the
> different editors on the different systems circa
> 1988, somebody told me I was in desperate need of
> micro-emacs. I went and got micro-emacs for MSDOS
> and still use it today (well, Windows command line
> version anyway). But I don't have it for the
> mainframe. I'm willing to replace MVS with PDOS if
> that's what it takes to get micro-emacs working on
> the mainframe.

Luck be with you, my friend. If you've got a C compiler on that mainframe,
and a copy of emacs or microemacs source code, you shouldn't have too much
trouble getting it up and running against existing ASCII terminals. If your
MVS supports USS or a POSIX subsystem, you may even have a termcap or
terminfo to handle the terminal management heavy lifting for you. 

If you /have/ to work with an EBCDIC compiler, then stick with the EBCDIC
variant that /it/ knows; the IBM C compiler I used 10 years ago only knew
EBCDIC-CP-US (which /isn't/ the Yellow Card EBCDIC).

As for your program, you could just use C macros defined in header files,
and provide header files based on the platform you are compiling on.
One "charset.h" file for ASCII-based platforms, and a totally different
one, defining the same macros, but with different values, for EBCDIC-based
systems. Your code just uses the macro ccESC (for instance), and leaves the
header to define it as 0x27 or 0x1b, depending on which version of the
header file you #included.

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#27666

On Thursday, October 25, 2012 12:15:21 PM UTC+11, Lew Pitcher wrote:
> On Wednesday 24 October 2012 19:10, in comp.lang.c, kerravon@w3.to wrote:
> > This one is easy - the Yellow Card has the definitive
> > reference.

> Only if you are dealing with (IIRC) IBM-1047 EBCDIC. It doesn't cover the
> other EBCDICs, like EBCDIC-US or EBCDIC-INT, although these variants share
> many common codepoints with the EBCDIC documented on the Yellow Card.

I am happy to use the character set defined by GCCMVS,
which was basically copied from IBM C/370.

> >> 2) EBCDIC terminals don't act like ASCII terminals. IBM defined them as
> >> a "block oriented" device, taking a specific set of (already predefined)
> >> commands, that are /nothing/ like the ANSI escape sequences you already
> >> know. On such a terminal, each printing position is paired with a second,
> >> control, octet, which governs the form and function of that position
> > 
> > I am roughly familiar with the 3270 data stream, and as
> > per original post, I don't want a 3270 data stream. I'm
> > trying to implement micro-emacs. So a new terminal type
> > is required.

> Then, why worry about EBCDIC at all? Programs running on modern IBM systems
> can use ASCII (under the POSIX subsystem), and can talk to ASCII devices
> using TCP/IP.

For the purpose of this conversation, I hate ASCII and
love EBCDIC. I don't want anything ASCII to be involved
in any step of the process. EBCDIC was invented before
ASCII, and C90 is the language of choice for EBCDIC
machines. Fantastic S/370 code is generated by the
EBCDIC C90 compilers (there are several to choose from,
and they all produce great code).

> The only case I can think of where you'd /want/ to talk
> EBCDIC is when your code talks to an EBCDIC-based terminal device, and that
> pretty much requires you to talk 3270 data stream (there aren't any other
> EBCDIC terminals to speak of).

For the purposes of this conversation, back in 1990 I was the
CEO of both General Electric and General Motors, and I told
IBM that if they didn't deliver me a character-mode terminal
that recognized the sequence x'27', x'ad', x'f2', x'd1'
(ESC [ 2 J), that I would take my business to Amdahl instead.
IBM delivered me such a terminal (dubbed PANSY) as requested,
and as a bonus it has some switches I can set on. Switch 1
will interpret x'0c' (FF) as identical to x'27'. Switch 2 will
interpret x'0b' (vertical tab) as identical to x'27'. Neither
switch is currently on, and I'm after advice from "the internet"
as to whether to switch either or both on.

I also raised a "please explain what you were smoking" to
the X3J11 committee when I saw them write "there is no
escape in EBCDIC", but I think the letter might have got
lost as I still haven't received a reply.

> > I am specifically dealing with an ANSI X3.64 terminal (or
> > close), which is not required or designed to react to the
> > form feed.

> So, an external EBCDIC-to-ASCII translation layer?

For the purposes of this conversation, there is no ASCII
device in sight. If someone hands me an ASCII machine,
locks me in a room, and says "ha ha, no more EBCDIC", I'll
download Hercules, which emulates whatever hardware you
want it to, including but not limited to the S/370 processor.

> ASCII "clear screen and reset cursor" ANSI sequence. That's ok; the
> translation layer will need some intelligence; interpreting escape
> sequences and such (does x'270c' represent a nonprintable, nonactionable
> character, followed by a formfeed, or does it represent a two character

x'270c' = x'2727' = x'0c0c' = x'0c27'. I am not aware of
any ANSI X3.64 or PANSY escape sequence that involves two
escape characters in a row, and I guess the result of doing
so would be classified as "undefined".

> OK, a new type of terminal emulator, then. One that uses EBCDIC characters
> but acts like an ANSI x3.64 terminal. But, my point was that terminals need
> a physical existence; a "screen" on which to display characters, and
> a "keyboard" from which to retrieve characters to send to the mainframe.
> Are you building a new ANSI x3.64 terminal, one that uses EBCDIC instead of
> ASCII, or are you front-ending an existing terminal with an EBCDIC-to-ASCII
> translator? The simpler approach would be to build the translator, and use
> someone else's X3.64 terminal (or software terminal), but you /could/
> actually be building a complete software terminal, or (heaven forbid) a
> complete hardware terminal. A much harder task.

From both the application (micro-emacs) or from the
operating system (MVS or PDOS) perspective, I don't
see that it makes any difference. However, if it does
make a difference, then for the purposes of this
conversation I am good friends with Bill Gates (read:
I have some photos of him in a compromising position
with a sheep), and he has agreed to manufacture the
hardware terminal of my dreams.

> >> 5) This seems all to 1990's for me. You are running at least 30 years
> >> behind the times; this has all been done before, many times over. Perhaps
> >> you need to look into prior art.
> > 
> > If it has been done many times over, and given that
> > micro-emacs is open source, where can I download a
> > pre-compiled micro-emacs binary for MVS?

> Hmmmmm....  I've been out of the mainframe world for a few years, but I can
> guess....
> How about http://www.jasspa.com/download.html, compiled and run under either
> a Linux LPAR or the Unix System Services component of MVS. It should work;
> IBM's been supporting Unix on MVS since the late 1990's, and MVS-managed
> Linux since the early 2000s.
> Other than that, there are a number of commercial sites who offer (or
> offerred) Unix programs for MVS; Mortice Kern used to offer such, although
> they seem to be out of business now.
> Heck, even IBM offers emacs free for MVS (zOS, actually)
> http://www-03.ibm.com/systems/z/os/zos/features/unix/tools/

I don't wish to run an alien operating system like Linux,
especially not ASCII. Nor do I want to use USS. I want to
use the real MVS interface to drive it, not an emulator.
MVS is 20 million lines of assembler code. I'm sure it
knows how to drive a character mode terminal, e.g. the
2741.

http://en.wikipedia.org/wiki/IBM_2741

> > There are computer 
> > systems in existence where a computer programmer
> > does not even have C90 available.

> I feel your pain. Once, I tried to get a Perl CPAN package installed on a
> development AIX box without a C compiler. I couldn't even convince them to
> install GCC,

Terrible! What was their objection to having a free C
compiler made available to them?

> I used to work (System Programmer) on DOS/VSE, VSE/SP, and VSE/ESA. I moved
> on before it became z/VSE.

Cool. Were you aware that DOS/VS is available to the
hobbyist community? That's how I managed to build GCCVSE.

> > Now that C90 is a universal 
> > language for computers, the next thing bugging me is
> > a universal editor. When I was complaining about the
> > different editors on the different systems circa
> > 1988, somebody told me I was in desperate need of
> > micro-emacs. I went and got micro-emacs for MSDOS
> > and still use it today (well, Windows command line
> > version anyway). But I don't have it for the
> > mainframe. I'm willing to replace MVS with PDOS if
> > that's what it takes to get micro-emacs working on
> > the mainframe.

> Luck be with you, my friend. If you've got a C compiler on that mainframe,
> and a copy of emacs or microemacs source code, you shouldn't have too much
> trouble getting it up and running against existing ASCII terminals. If your
> MVS supports USS or a POSIX subsystem, you may even have a termcap or
> terminfo to handle the terminal management heavy lifting for you. 
> If you /have/ to work with an EBCDIC compiler, then stick with the EBCDIC
> variant that /it/ knows; the IBM C compiler I used 10 years ago only knew
> EBCDIC-CP-US (which /isn't/ the Yellow Card EBCDIC).

Do you remember a code point that was different? I don't
remember seeing any code point differing from the yellow
card.

> As for your program, you could just use C macros defined in header files,
> and provide header files based on the platform you are compiling on.
> One "charset.h" file for ASCII-based platforms, and a totally different
> one, defining the same macros, but with different values, for EBCDIC-based
> systems. Your code just uses the macro ccESC (for instance), and leaves the
> header to define it as 0x27 or 0x1b, depending on which version of the
> header file you #included.

That's a very good idea, and satisfies my technical requirement
of not having to do a #ifdef EBCDIC. However, I'd still like to
know the underlying technical reason as to why there's no \e
for ESC. For that matter I'd also like to know whether there
should be escapes for other characters, like ctrl-a for
micro-emacs beginning of line. Will that work in EBCDIC?

Thanks.  Paul.

[toc] | [prev] | [next] | [standalone]

#27672

"kerravon" <kerravon@w3.to> wrote in message 
news:d133dc43-bd8c-4743-9451-e0a9162eab2e@googlegroups.com...

> For the purpose of this conversation, I hate ASCII and
> love EBCDIC.

Yet your message was posted in ASCII ... ?

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#27673

On Thursday, October 25, 2012 9:30:27 PM UTC+11, Bart wrote:
> "kerravon" <kerravon@w3.to> wrote in message 
> 
> > For the purpose of this conversation, I hate ASCII and
> > love EBCDIC.
> 
> Yet your message was posted in ASCII ... ?

I was careful to restrict my message to characters
that were available in EBCDIC. :-)

BFN.  Paul.

[toc] | [prev] | [next] | [standalone]

#27674

On 10/25/2012 12:09 AM, kerravon wrote:
...
> I also raised a "please explain what you were smoking" to
> the X3J11 committee when I saw them write "there is no
> escape in EBCDIC", but I think the letter might have got
> lost as I still haven't received a reply.

It's been explained to you that while there is a character named ESC in
EBCDIC, almost the only thing it shares with the ASCII ESC is the
spelling of it's name. If I've followed the discussion correctly, it's
barely even used, and not for any of the same purposes as the ASCII ESC.

I doubt that you'll ever receive a fuller explanation than that. I doubt
that there is a fuller explanation to be given. If that were in fact the
case, what kind of reply, beyond what you've already been given, would
be both truthful and satisfying to you?
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web