From bug-octave-request at bevo dot che dot wisc dot edu  Fri Feb 20 08:56:40 1998
Subject: cp850 terminal  at cygwin32
From: fabian at olymp dot Umwelt dot TU-Cottbus dot de (Rolf Fabian)
To: bug-octave at bevo dot che dot wisc dot edu
Date: Fri, 20 Feb 1998 15:56:48 +0100

Dear John W.,

cygwin32-b18 terminal problems

Sorry for the typographical error in the script included
in the previous mail. It's present only in the mail and not
in our application. Hence it cannot be responsible for our
described problem under cygwin32, that input of range-variables
into function scripts lead to errors on this platform!

But your answer gave me some hints what might be the reason
of this problem and even much more trouble with the gnuwin32-platform
for octave:

>>> Now, I suspect the underlying reason to be a rather limited support
>>> of cygwin32 for code-pages other that US standard cp437 ! But in many
>>> European countries like here in Germany, we use cp850 as standard.

You told us, that you wondered about our statement, that a simple
command like 
octave:> gset xrange [A:B] 
should be shorthanded by a script.

Here's a detailed explanation

After installation of gnuwin32-b18 on a win95-system with standard cp850
(like ours) and invokation of octave from an MSDOS-prompt, you get an
octave command line with *NO FUNCTIONALITY AT ALL* concerning the 
following special characters (list might be incomplete!):

+ vertical bar		
+ backslash
+ left and right square bracket	
+ left and right curly  brace
+ tilde
+ at-operator at 
* caret		
* backward upper-comma (don't know US-name, French: 'accent grave')
* foreward upper-comma (don't know US-name, French: 'accent aigue')

Such a terminal is useless for interactive octave-sessions,
because most of these special characters are important operators.

We've found empirically (no docs found!),  an really
*exotic file*  named  '[.exe'  (in words: left_square_bracket.exe) 
inside folder X:\gnuwin32\b18\H-i386-cygwin32\bin ,
which indicates that a left_square_bracket seems to be a special
escape-sequence for generating those missing special characters. 

And indeed, if you preceed the characters mentioned in the list 
above tagged with '+' you are able to 'type' them on such a command line. 
The '*'-tagged characters may not be generated in this way!
For the caret (exponentiation-operator) we use '.**' or '**' .
The others are not octave-relevant.

Hence for the example given above we've to input to gnuwin32-octave-terminal:

octave:> gset xrange [[A:B[] 

Furthermore you have to realize, that under cp850 and e.g. German keyboard 
a left square brack is already a combination of two keyhits, i.e. 'AltGr'+'['
So this leads to really exotic keyboard-typing scrumbling up your fingers! 

gset xrange  #nothing special
'AltGr' 
'left square bracket'
'AltGr' 
'left square bracket'
'shift'
'A'
'shift'
'colon'
'shift'
'B'
'AltGr' 
'left square bracket'
'AltGr' 
'right square bracket'

Calling other operators, e.g. 'or=two vertical bars=||' 
is only slightly less difficult/dangerous. This gives only very limited 
functionality for interactive sessions.

I really doubt, that anybody works efficiently in interactive sessions on such an
exotic terminal.

Concerning arguments of internal functions 
e.g. typing 'exp(1:5)' or 'exp([[1,5[])' is interpreted correctly, 
but calling a script foo(xrange).m like
'foo(1:5)' leads to an error (see bug report yesterday). Most propably because 
the argument's colon might not be correctly transferred from the shell
to the octave-parser.

HENCE WE USE THIS PLATFORM SIMPLY AS A COMMAND-LINE TO RUN OCTAVE-SCRIPTS
CREATED AND INTERACTIVELY TESTED ON A DIFFERENT OCTAVE-PLATFORM
(namely OS/2 by K. Gebhardt, which doesn't possess any of the described
problems).

SUMMARY:
Making the gnuwin32-terminal more comfortable for outside-US codepages
should give programs such as octave the potential of getting much more popular.
Alternate: OS/2 - version doesn't have such codepage problems!

Best wishes
R. Fabian fabian at umwelt dot tu-cottbus dot de 980220