Color for text only app
crv...@up-link.net
(80x25). I have a couple of questions the answer to which would improve
the look and feel of the whole thing considerably. First of all, is it
possible to change the background and/or the foreground of certain
texts on the screen while the remaining text continues at default?
Second, is it possible to enter text at other locations on the screen
besides the lower left? Thanks in advance.
sleb...@gmail.com
> I'm writing a tcl script to be used in character based terminals
> (80x25).
When you say character terminals do you mean REAL character terminals
(including virtual terminals) or do you mean DOS/Windows COMSPEC shell?
For real terminals like VT100 & ANSI, you can simply use ANSI escape
sequences. This can be done in any programming language. Here's an
example of colored text:
puts "\033\[43;31m Hello \033\[37;44m World \033\[0m"
Of course, the code above can be made easier to read:
proc ANSI {args} {
set ret "\033\["
foreach {op val} $args {
switch -- $op {
-style {}
-bg {append ret 4}
-fg {append ret 3}
}
switch -- $val {
black {append ret "0;"}
red {append ret "1;"}
green {append ret "2;"}
yellow {append ret "3;"}
blue {append ret "4;"}
magenta {append ret "5;"}
cyan {append ret "6;"}
white {append ret "7;"}
none {append ret "0;"}
bright {append ret "1;"}
dim {append ret "2;"}
underline {append ret "4;"}
blink {append ret "5;"}
reverse {append ret "7;"}
}
}
set ret [string trim $ret ";"]
return ${ret}m
}
puts "[ANSI -fg red -bg yellow] Hello [ANSI -fg blue -bg white] World
[ANSI -style none]"
crv...@up-link.net
On Jan 25, 10:35 pm, "slebet...@yahoo.com" <slebet...@gmail.com> wrote:
> On Jan 26, 10:48 am, crv...@up-link.net wrote:
>
> > I'm writing a tcl script to be used in character based terminals
> > (80x25).When you say character terminals do you mean REAL character terminals
> (including virtual terminals) or do you mean DOS/Windows COMSPEC shell?
>
I was hoping for something that worked for both. The plan is to have
several real character based terminals (VT100) on the shop floor that
will be running the app while the office personnel will be running the
same app on Windows based computers. tclsh doesn't handle the ANSI
codes and thus would be unacceptable for the office people.
Arjen Markus
On 26 jan, 11:54, crv...@up-link.net wrote:
> On Jan 25, 10:35 pm, "slebet...@yahoo.com" <slebet...@gmail.com> wrote:> On Jan 26, 10:48 am, crv...@up-link.net wrote:
>
> > > I'm writing a tcl script to be used in character based terminals
> > > (80x25).When you say character terminals do you mean REAL character terminals
> > (including virtual terminals) or do you mean DOS/Windows COMSPEC shell?I was hoping for something that worked for both. The plan is to have
> several real character based terminals (VT100) on the shop floor that
> will be running the app while the office personnel will be running the
> same app on Windows based computers. tclsh doesn't handle the ANSI
> codes and thus would be unacceptable for the office people.
The Wiki has this page: http://wiki.tcl.tk/1143 - it may work in your
case.
Another possibility is the term package in Tcllib (or better: its child
packages), but I do not
know whether this works alright under Windows.
Regards,
Arjen
Uwe Klein
Can one still load "ansi.sys" for Dos Windows under the newer M$ OSes?
uwe
Mark Janssen
> > codes and thus would be unacceptable for the office people.Can one still load "ansi.sys" for Dos Windows under the newer M$ OSes?
>
> uwe
Only in command.com, not in the cmd.exe. See
http://support.microsoft.com/kb/101875/en-us on how to enable it.
Mark
Larry W. Virden
On Jan 25, 9:48 pm, crv...@up-link.net wrote:
> is it
> possible to change the background and/or the foreground of certain
> texts on the screen while the remaining text continues at default?
It is not possible to do this for every possible terminal that might
exist. However, with some work, you might be able to create a Tcl
extension that makes use of curses and terminfo to be able to determine
whether the terminal actually supports that sort of functionality, and
then use the curses functions to perform the needed actions.
> Second, is it possible to enter text at other locations on the screen
> besides the lower left? Thanks in advance.
If you get the first thing taken care of, then you should have the
functionality to do this as well.
There have been a few attempts at building such an interface over the
years - http://www.ishiboo.com/~nirva/Projects/tclterm/ is, I believe,
one of those attempts. I've never used any of them, so I don't know how
well they do.
Generally people just end up using Tk to generate a GUI interface.
Gerald W. Lester
Do you mean TkCon -- tclsh.exe on Windows tends to be run in a command
prompt window (either command.com or cmd.exe or the new Vista equivalent
which I can not remember the name of) and not in and of itself.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Mark Janssen
If you are on windows and cannot use command.com, you can use twapi
(twapi.sourceforge.net) to access the Win32 console API. For example
the following snippet will display a blinking text and also
demonstrates cursor positioning.
Mark
package require twapi
namespace import ::twapi::*
set cons [get_console_handle stdout]
set i 0
fill_console $cons
while {1} {
after 500
set_console_default_attr $cons -fgbright [expr {$i%2}] -bgblue 1
-fgred 1
set_console_cursor_position $cons {10 10}
write_console $cons test$i
incr i
}
Bruce Hartweg
correct me if I'm wrong, but I believe that this will configure *all*
the text in the console, not a particular word itself.
Bruce
Michael Schlenker
no way short of writing your own console handler.
Michael
Mark Janssen
> the text in the console, not a particular word itself.
>
> Bruce
This only changes the default for anything written to the console
afterwards, so it does not affect the existing console contents. If you
want to change the attributes of existing text, [twapi::fill_console]
can be used.
Mark
Bruce Hartweg
cool, thanks for the info. so the OP could come up with some psuedo
markup for coloring the output, and then depending on which platform
either use ANSI escapes, of the twapi stuff to output the text.
Bruce
crv...@up-link.net
everybody is talking about is that it can be done in windows and it can
be done on a hardware terminal, but not both at the same time with the
same app. Each of the solutions applies to one or the other but not to
both. The tcllib term solution is for hardware terminals and does not
work with tclsh under windows. The other solutions worked for windows
but not for hardware terminals. So, it appears to me that I have two
choices: 1) Write the app for tclsh alone and live with the
monochromatic appearance, 2} Write the app with two interfaces, one
interface for the hardware terminals and the other interface with a Tk
GUI for a windows interface. If I have missed something please let me
know.
For you pro's out there that use character based hardware terminals let
me see if I understand things correctly. When the terminal boots it
will connect to the server via VT100 protocol. At that point the
terminal communicates with the server via stdin and stdout. Now the
user can run any program on the server with the appropriate permissions
and of course that program must communicate via stdin and stdout. One
question, where does the login occur -- before the VT100 connection is
made or after?
Thanks
Charles
Gerald W. Lester
> Okay. Thanks everybody for your input. The way I see everything that
> everybody is talking about is that it can be done in windows and it can
> be done on a hardware terminal, but not both at the same time with the
> same app. Each of the solutions applies to one or the other but not to
> both. The tcllib term solution is for hardware terminals and does not
> work with tclsh under windows. The other solutions worked for windows
> but not for hardware terminals. So, it appears to me that I have two
> choices: 1) Write the app for tclsh alone and live with the
> monochromatic appearance, 2} Write the app with two interfaces, one
> interface for the hardware terminals and the other interface with a Tk
> GUI for a windows interface. If I have missed something please let me
> know.
3) Write a library that insulates the program from knowing if it is on a
physical character cell terminal or windows console. (Suggest enhancing
what is already in tcllib to deal with windows and contributing it back).
> For you pro's out there that use character based hardware terminals let
> me see if I understand things correctly. When the terminal boots it
> will connect to the server via VT100 protocol. At that point the
> terminal communicates with the server via stdin and stdout. Now the
> user can run any program on the server with the appropriate permissions
> and of course that program must communicate via stdin and stdout. One
> question, where does the login occur -- before the VT100 connection is
> made or after?
The answer to the login is -- depends.
It depends if you are running the VT100s:
1) directly connected
2) via a terminal server
3) via a reverse terminal server
1 & 2 mean you login when you "connect" to the server
3 means the server is running an application (as some user) that is
controlling the terminal.
The fact that you ask this question leads me to believe you are in over your
head and should look for a consultant (i.e. pay someone) to work with you.
Larry W. Virden
On Jan 26, 11:47 pm, crv...@up-link.net wrote:
> For you pro's out there that use character based hardware terminals let
> me see if I understand things correctly. When the terminal boots it
> will connect to the server via VT100 protocol.
Hmm - maybe some do. But the hardware terminals of which I'm aware
connect to the server via some sort of RS-232 hardware protocol. VT100
isn't so much a hardware protocol as it is a set of escape sequences
that many hardware terminals support. Note also there's a 3rd kind of
"terminal" that people use - terminal emulators such as hyperterminal,
etc. on Windows, xterm/rxvt/etc. on X, and so forth.
At that point the
> terminal communicates with the server via stdin and stdout.
Well, to be more accurate, the terminal communicates with the server
over a serial line, and the server uses a serial driver to read that
cable, then feeds that through the tty driver into whatever server or
application reads it.
Now the
> user can run any program on the server with the appropriate permissions
> and of course that program must communicate via stdin and stdout. One
> question, where does the login occur -- before the VT100 connection is
> made or after?
The vt100 is a software convention created by D.E.C. about 20+ yrs
ago. The terminal uses rs-232 to "talk" to the server. The server
provides the hardware a login type interface. Once the user has logged
in, the site admin or user can either make assumptions about the type
of hardware, or they can specify a program run that generates an
escape sequence to try to identify whether the hardware supports vt1xx/
vt2xx/vt3xx/some totally different terminal. Once the type of terminal
emulation being done has been identified, proper terminal programs,
written to use curses and/or terminfo can then send call a high level
routine that sends appropriate sequences to the hardware to control
color, etc.
>
> Thanks
> Charles
Cameron Laird
Gerald W. Lester <Gerald...@cox.net> wrote:
>crv...@up-link.net wrote:
>> Okay. Thanks everybody for your input. The way I see everything that
>> everybody is talking about is that it can be done in windows and it can
>> be done on a hardware terminal, but not both at the same time with the
>> same app. Each of the solutions applies to one or the other but not to
.
.
>The fact that you ask this question leads me to believe you are in over your
>head and should look for a consultant (i.e. pay someone) to work with you.
.
.
I want to reinforce a copy of Gerald's points as explicitly as possible.
You probably would reap a huge return on a modest investment in help from
a consultant.
That's no insult.
On another hand, my own judgment is that it's not impossible for you to
succeed, starting from where you are--just more wasteful than necessary.
comp.lang.tcl will likely provide cheerful and accurate assistance in
either case.
The proposition about "... not both at the same time with the same app"
is ... very different from the way we're accustomed to talking around
here. It makes me wonder if there's a fundamental conflict in vocabulary
afoot. I read what you wrote about needing to take care of factory-floor
*and* back-office workers. I constantly encounter requirements where,
for example, different users (on different hardware, software, ...) have
to be serviced by different algorithms. Much of what I do is to package
work as a single application that correctly handles different
possibilities. In Tcl in particular, it is VERY common to construct a
single application that knows how to pop up a GUI when it can, fall back
to the most rudimentary character-oriented interaction when no more is
feasible, and perhaps even do one or more things "in-between", as
circumstances merit. We can give examples, if this isn't clear.
David Gravereaux
I agree. It would be nice if the windows console understood ANSI control
sequences, but it doesn't. But the raw win32 console API calls can do most of
what it would take given a decoder for ANSI escapes. It might even be said that
the existing console channel driver in the core should get ANSI terminal-like
capabilities.
Just for fun, I slapped together an ANSI parser and gave it proper output to the
windows console. underline and blink don't work, but everything else ansi.sys
did, this will do except for key remapping and graphic mode selection.
http://www.pobox.com/~davygrvy/tclstuff/winAnsiCon.zip (with source)
Using it to show some of the ANSI artworks @ http://www.acid.org/100/lorez.html
looks really cool:
package require http
load winAnsiCon
set urls [list \
http://www.acid.org/100/lorez/ANSI-100.ANS \
http://www.acid.org/100/lorez/ANSC-100.ANS \
http://www.acid.org/100/lorez/NS-EAST.ANS \
http://www.acid.org/100/lorez/ASX-ACID.ANS \
http://www.acid.org/100/lorez/DA-ANIME.ANS \
http://www.acid.org/100/lorez/33-MOOT3.ANS \
http://www.acid.org/100/lorez/GO-EAST.ANS \
http://www.acid.org/100/lorez/LD-RIP.ANS \
http://www.acid.org/100/lorez/MAY-ACID.ANS \
http://www.acid.org/100/lorez/NE-ACID.ANS \
http://www.acid.org/100/lorez/OS-HAZ01.ANS \
http://www.acid.org/100/lorez/OS-HAZ02.ANS \
http://www.acid.org/100/lorez/TXT-RZ.ANS \
]
foreach url $urls {
set token [http::geturl $url -binary yes]
if {[http::ncode $token] == 200} {
ansi_puts [encoding convertfrom cp437 [http::data $token]]
}
http::cleanup $token
after 6000
ansi_puts \033\1330m\n ;# reset any mess between pages
}
I haven't tried the extension from wish, but it might work. My parser isn't
stream capable, so it isn't a full solution to a core patch for the console
channel driver.. ignoring that I wrote it in C++ for the moment.. I'm sure it
has a few bugs.
This isn't "product" worthy, just play fun.
Would adding ANSI features to the windows console channel driver be worth TIP'ing?
It wouldn't be hard code to write. Underline (esc[4m) and blink (esc[5m) I'll
have to research how to do it.
--
Hobbes: What would you call the creation of the universe?
Calvin: The Horrendous Space Kablooie!
Michael Schlenker
> Michael Schlenker wrote:
>> crv...@up-link.net schrieb:
>>> I'm writing a tcl script to be used in character based terminals
>>> (80x25). I have a couple of questions the answer to which would improve
>>> the look and feel of the whole thing considerably. First of all, is it
>>> possible to change the background and/or the foreground of certain
>>> texts on the screen while the remaining text continues at default?
>>> Second, is it possible to enter text at other locations on the screen
>>> besides the lower left? Thanks in advance.
>>>
>> On unix, take a look at the term package in tcllib, on windows your have
>> no way short of writing your own console handler.
>>
>> Michael
>
>
>
>
> Would adding ANSI features to the windows console channel driver be worth TIP'ing?
cross platform support a bit more complete...
Michael
David Gravereaux
> Underline (esc[4m) and blink (esc[5m) I'll
> have to research how to do it.
>
You can do a manual blink like so:
proc esc {} {return "\033\133"}
for {set b 0} {$b < 20} {incr b} {
if {$b % 2} {
ansi_puts "[esc]s[esc]0;0H[esc]1;31mhi[esc]Cthere[esc]0m[esc]u"
} else {
ansi_puts "[esc]s[esc]0;0H[esc]30mhi[esc]Cthere[esc]0m[esc]u"
}
after 500
}
At the attribute level would be a difficult in code to manage.
--
"I propose we leave math to the machines and go play outside."
--- Calvin
David Gravereaux
>> This isn't "product" worthy, just play fun.
> But really cool...
Tnks.. Just for fun..
>> Would adding ANSI features to the windows console channel driver be worth TIP'ing?
> Yes. I at least would really like this... and it would make the Tcl
> cross platform support a bit more complete...
Ok. I have a number of bugs to fixed that push beyond the limits of Win32's
rather lame Console API. Progress is going slow, but I'm making some headway.
I'll get a rough patch patch going. Hopefully in a couple weeks I'll have
something near ready... minus the system limitations regarding blink and underline.
This might even be a good base layer for someone to make a "curses" like library
on top of it... all in script code.
--
I imagine girls and bugs have a dim perception that nature played a cruel
trick on them but they lack the intelligence to really comprehend the magnitude
of it. -- Calvin
Donal K. Fellows
> Would adding ANSI features to the windows console channel driver be worth TIP'ing?
Yes. It might even be worth breaking our rule on "no more features for
8.5" to get it fast-tracked in. (No promises on that though.)
Donal.
Andreas Leitgeb
I wonder, how many of those stoneaged, non-ansi/vt???-compatible
terminals there are still out in the wild...
I remember some hp-terminals being real beasts, and "97801" another one.
Is the "adding ANSI features" meant to take termcap/terminfo
into account (for unix at least), or direct support of
sufficiently "ANSI" compatible (probably the vt###-series)
devices(and emulations thereof) ?
David Gravereaux
Well, I can't speak for the linux/unix side of the fence nor the existence of such
"stone-age" hardware as this has nothing to do with hardware. It has to do with
extending the capabilities of the console channel type on windows to allow a more
rich programming environment. The Console API on windows does allow for colors
and cursor movements, but there isn't a way to access it.
All I'm saying is, "Why not call the channel type an ANSI capable device, and put
an ANSI decoder in the channel driver itself?"
I'm thinking just sufficient understanding of color and cursor movements. What a
linux console does without any assistance in the channel driver, I can't say. It
just might already work and understand ANSI escapes sent to it. <- I'll bet money
on that :)
And I don't have to bet money ->
davygrvy@kilauea ~
$ ssh davy...@mosfet.expression.edu
Last login: Tue Feb 6 12:07:37 2007 from c-24-7-73-235.hsd1.ca.comcast.net
davygrvy@mosfet ~
$ tclsh
% uname -a
Linux mosfet.expression.edu 2.6.9-42.0.3.EL #1 Mon Sep 25 17:14:19 EDT 2006 i686
i686 i386 GNU/Linux
% puts "\033\1331;31mhi there\033\133m"
hi there
%
"hi there" was displayed in red as expected, but I wasn't at the terminal, though.
I'm thinking pretty much the all the escape sequences mentioned @
http://www.bribes.org/perl/ansi.html
plus ->
- 39m for return to foreground default (which doesn't have to be 75% grey)
- 49m for return to background default (which doesn't have to be black)
minus ->
- his addons for translations which we won't have a problem with. Unicode is a
wonderful thing when combined with a unicode console font (such as "Lucida
Console" or maybe "Code2000").
There are some technical limitations with the blink, underline and reverse modes.
As far as I can tell, the attribute values for those modes are old cruft leftover
from the IBM OS/2 -> M$'s NewTechnology split from NT's birth and are just not
implemented.
I can fake reverse easy enough and maybe even blink, but underline looks like a
NOP. There's a color palette problem I'm working on regarding low-intensity
yellow, which is sometimes called brown. On DOS (yes, the real ol` MS-DOS with
ansi.sys), that color (esc[33m) is really supposed to be orange. I'm having to
delve into some undocumented kernel32 API calls to manipulate it, but progress is
going well reverse engineering how the undocumented stuff works.
The windows Console API is unforgivably limited.
--
Why should I have to work for everything? It's like saying that I don't
deserve it. -- Calvin
Bruce Hartweg
If your up for doing it, it would be cool if the windows console handled
things it could. and don't sweat the bits that don't work. I remember
actual consoles that didn't support blinking.
Bruce
David Gravereaux
> If your up for doing it, it would be cool if the windows console handled
> things it could. and don't sweat the bits that don't work. I remember
> actual consoles that didn't support blinking.
Thanks Bruce. What's funny/odd/strange is that VGA does support those attributes
at the hardware level:
http://www.stanford.edu/class/cs140/projects/pintos/specs/freevga/vga/vgatext.htm
I think its unforgivable that Microsoft doesn't implement the high attribute flags
listed in their programming reference for SetConsoleTextAttribute().
I still remember when dual monitor was an HGA and a VGA in the same computer,
mode=mono :) I wonder if XP would even recognize a Hercules card.. Gosh, does my
motherboard even have an 8-bit IDE slot? I wonder if I could even find a (used)
green screen that doesn't have burnt phosphor? While I'm at it.. I should scour
eBay for 8-tracks and Atari 2600 game cartridges :)
Pong lives!
Sorry.. just feeling expressive tonight. My test code is done then. I'll move
it into the channel driver over the coming weeks in my free time and propose a patch.
--
"That's the problem with science. You've got a bunch of empiricists trying
to describe things of unimaginable wonder." -Calvin
Bruce Hartweg
If your up for doing it, it would be cool if the windows console handled
things it could. and don't sweat the bits that don't work. I remember
actual consoles that didn't support blinking.
Bruce