Prev: how to search text in subdirectories
Next: "Why Scripting Is Evil" -- comments?
From: Paul Branon on 12 Jun 2010 06:51

why is it that echo -e '\[1;34m'; echo "this is blue"
prints "this is blue" in blue but only if I type it in my Console
window?

If I type it in my Putty window it prints it in black and if I ssh
through a console connection and type it the results are weird.
From: Janis Papanagnou on 12 Jun 2010 06:58
Paul Branon wrote:
> why is it that echo -e '\[1;34m'; echo "this is blue"
> prints "this is blue" in blue but only if I type it in my Console
> window?
>
> If I type it in my Putty window it prints it in black and if I ssh
> through a console connection and type it the results are weird.

Just a note; echo -e '\[1;34m' does nothing in a console on my
system while echo -e '\E[1;34m' works as described (in a console
window at least).

Janis
From: Thomas 'PointedEars' Lahn on 12 Jun 2010 07:01
Paul Branon wrote:

> why is it that echo -e '\[1;34m'; echo "this is blue"
> prints "this is blue" in blue but only if I type it in my Console
> window?
>
> If I type it in my Putty window it prints it in black and if I ssh
> through a console connection and type it the results are weird.

It depends on the `echo' implementation and the value of the TERM
environment variable. We've been over the former recently. Avoid
`echo -e', use tput(1) and terminfo(5) capabilities instead.

--
PointedEars
From: Seebs on 12 Jun 2010 13:13
On 2010-06-12, Paul Branon <paulbranon(a)googlemail.com> wrote:
> why is it that echo -e '\[1;34m'; echo "this is blue"
> prints "this is blue" in blue but only if I type it in my Console
> window?

A closer examination of the subject line will resolve everything.

"Bash Shell escapes"

These have nothing to do with bash. They work identically in al
conceivable shells, whether it's bash, dash, ash, ksh, rc, es, or
a cleverly constructed emulator for COMMAND.COM.

What they don't work identically in, as you've just found out, is
all *TERMINALS*. See, those "escape sequences" are used to send
special commands to *terminals*. Different terminals use different
sets of escape sequences. The kind you describe is mostly used on
terminals implementing the "ANSI" escape sequence set (which I suspect
is actually standardized by ANSI, but you never know...)

That's a superset of the vt100 standard. Most terminal programs can
emulate some reasonable subset of vt100 escape sequences or ANSI codes,
but, many either don't implement color, or don't enable it by default.

If you mess around with settings in your terminal programs, you may
find ways to enable color.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Chris F.A. Johnson on 12 Jun 2010 20:04
On 2010-06-12, Seebs wrote:
> On 2010-06-12, Paul Branon <paulbranon(a)googlemail.com> wrote:
>> why is it that echo -e '\[1;34m'; echo "this is blue"
>> prints "this is blue" in blue but only if I type it in my Console
>> window?
>
> A closer examination of the subject line will resolve everything.
>
> "Bash Shell escapes"
>
> These have nothing to do with bash. They work identically in al
> conceivable shells, whether it's bash, dash, ash, ksh, rc, es, or
> a cleverly constructed emulator for COMMAND.COM.
>
> What they don't work identically in, as you've just found out, is
> all *TERMINALS*. See, those "escape sequences" are used to send
> special commands to *terminals*. Different terminals use different
> sets of escape sequences. The kind you describe is mostly used on
> terminals implementing the "ANSI" escape sequence set (which I suspect
> is actually standardized by ANSI, but you never know...)
>
> That's a superset of the vt100 standard. Most terminal programs can
> emulate some reasonable subset of vt100 escape sequences or ANSI codes,
> but, many either don't implement color, or don't enable it by default.

To quote from my book, Pro Bash Programming:

Unix purists will shake their heads over this chapter. Traditionally,
screen manipulation is done through the termcap or terminfo database
that supplies the information necessary to manipulate any of dozens or
even hundreds of types of terminal. The shell interface to the
database is an external command, tput.

On some systems, tput uses the termcap database; on others (mostly
newer systems) it uses the terminfo database. The commands for the two
databases are not the same, so a tput command written for one system
may not work on another.

On one system, the command to place the cursor at the 20th column on
the 10th row is:

tput cup 9 19

On another system, the command is:

tput cm 19 9

These commands will produce the correct output for whatever type of
terminal is specified in the TERM variable. (Note: tput starts
counting at 0.)

However, the plethora of terminal types has, for all intents and
purposes, been reduced to a single, standard type. This standard, ISO
6429 (also known as ECMA-48, and formerly known as ANSI X3.64 or
VT100), is ubiquitous, and terminals that do not support it are few
and far between. As a result, it is now feasible to code for a single
terminal type. One advantage of this homogeneity is that the necessary
coding can be done entirely within the shell. There's no need for an
external command.


--
Chris F.A. Johnson, author <http://shell.cfajohnson.com/>
===================================================================
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
 |  Next  |  Last
Pages: 1 2
Prev: how to search text in subdirectories
Next: "Why Scripting Is Evil" -- comments?