Prev: how to search text in subdirectories
Next: "Why Scripting Is Evil" -- comments?
From: Michael Paoli on 17 Jun 2010 10:01
On Jun 12, 5:04 pm, "Chris F.A. Johnson" <cfajohnson(a)gmail.com> wrote:
> 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.

Hogwash! ;->

Just because some type of terminal "standard"/emulation may be
becoming
more common doesn't obsolete all other types of terminals and
emulations
thereof. Sending arbitrary control/escape sequences presuming one has
some particular type or flavor of terminal, when that may not be the
case, is just plain wrong - and also rather hazardous (e.g. some
control/escape sequences will in fact crash some terminals!).

Do it the right way, use tput, etc.

E.g. if you presume I've got some ANSI or VT-100 terminal type or the
like when I've told you my terminal type is c3102, I, and my Cromemco
3102 terminal, will likely get very upset and annoyed when you send
quite inappropriate control/escape sequences, and mess up - and
possibly
even crash - the terminal. Likewise, if I set TERM=linux-m, I'll get
quite upset if you start bloody mucking about setting/changing colors
on
my Linux console when I explicitly gave a terminal type that has no
color
capabilities so that you'd hopefully be smart enough to respect that
and
do what I properly requested you do (and not do). If I've got some
quite obscure, or brand spanking new terminal/emulator, for which
terminfo/termcap entries haven't been created yet, and I tell you the
terminal type is dumb, so you won't do anything stupid, and you do
anyway, then your stupid program is not behaving reasonably.

So, ... do the right thing! :-) ... tput(1), etc.
From: Michael Paoli on 18 Jun 2010 06:37
On Jun 12, 3:51 am, 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?
>
> 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.

You probably meant to type :-) something more like:

if tput setaf 4; then
if tput bold; then
echo this is blue
tput sgr0 ||
tput reset
else
tput sgr0 ||
tput reset
1>&2 echo bold failed
false
fi
elif tput setf 1; then
if tput bold; then
echo this is blue
tput sgr0 ||
tput reset
else
tput sgr0 ||
tput reset
1>&2 echo bold failed
false
fi
else
1>&2 echo blue failed
false
fi

One should use (e.g. from shell) tput, and not depend upon or presume
specific escape/control sequences for some specific terminal or
emulation.

Also, precise behavior of echo is quite shell-dependent. For a
standards compliant shell, printf may be used more portably, e.g.:
$ printf '\033[1;34m'
.... but don't do something like that for manipulating display modes,
etc. Instead, use tput(1).

references:
tput(1)
terminfo(5)
sh(1)

First  |  Prev  | 
Pages: 1 2
Prev: how to search text in subdirectories
Next: "Why Scripting Is Evil" -- comments?