Tux

...making Linux just a little more fun!

2-cent Tip: make script command logs without escape character

Mulyadi Santosa [mulyadi.santosa at gmail.com]


Tue, 27 May 2008 13:34:22 +0700

Tired of script-generated logs cluttered with escape characters all over the place?

Try to change the terminal into "dumb" and repeat:

$ export TERM=dumb
$ script
<do whatever necessary to be logged>
<type exit or press Ctrl-D>
$ export TERM=xterm
Switch back to vt100, xterm, or other when you're done, to recover your
terminal's original mode.
Observe the generated log:
$ cat -A typescript
 
mulyadi@mushu:/tmp$ ls^M$
gconfd-mulyadi^I^I  mc-mulyadi^I ssh-tYecBM5768^M$
gedit.mulyadi.3088662139  orbit-mulyadi  Tracker-mulyadi.5855^M$
keyring-HzVeHi^I^I  plugtmp^I typescript^M$
mapping-mulyadi^I^I  sqlGIskW0^I virtual-mulyadi.SGmoJb^M$

Note that we see ^I, ^M, and so on, because of the -A option on "cat". This is needed so we are sure there are no escape characters there.


Top    Back


Thomas Adam [thomas.adam22 at gmail.com]


Tue, 27 May 2008 08:12:10 +0100

2008/5/27 Mulyadi Santosa <mulyadi.santosa@gmail.com>:

> Tired of script-generated logs cluttered with escape
> characters all over the place?
>
> Try to change the terminal into "dumb" and repeat:
> $ export TERM=dumb
> $ script
> <do whatever necessary to be logged>
> <type exit or press Ctrl-D>
> $ export TERM=xterm
> Switch back to vt100, xterm, or other when you're done, to recover your
> terminal's original mode.
>
> Observe the generated log:
> $ cat -A typescript

I don't think "cat -A" is standard. And indeed the canonical approach to this has always been:

script -f foo
$ blah
$ ls
$ sudo rm -fr / # :P
^D
 
$ col -bx < ./foo > ./foo.transcript

-- Thomas Adam


Top    Back


Mulyadi Santosa [mulyadi.santosa at gmail.com]


Tue, 27 May 2008 16:07:43 +0700

Hi Thomas :)

On Tue, May 27, 2008 at 2:12 PM, Thomas Adam <thomas.adam22@gmail.com> wrote:

> 2008/5/27 Mulyadi Santosa <mulyadi.santosa@gmail.com>:
>> Tired of script-generated logs cluttered with escape
>> characters all over the place?
>>
>> Try to change the terminal into "dumb" and repeat:
>> $ export TERM=dumb
>> $ script
>> <do whatever necessary to be logged>
>> <type exit or press Ctrl-D>
>> $ export TERM=xterm
>> Switch back to vt100, xterm, or other when you're done, to recover your
>> terminal's original mode.
>>
>> Observe the generated log:
>> $ cat -A typescript
>
> I don't think "cat -A" is standard.  And indeed the canonical approach
> to this has always been:
>
> ```
> script -f foo
> $ blah
> $ ls
> $ sudo rm -fr / # :P
> ^D
>
> $ col -bx < ./foo > ./foo.transcript
> '''

ahh, I think that's better :) thanks for pointing me that :)

regards,

Mulyadi.


Top    Back


Ben Okopnik [ben at linuxgazette.net]


Tue, 27 May 2008 08:39:05 -0400

On Tue, May 27, 2008 at 08:12:10AM +0100, Thomas Adam wrote:

> 
> ```
> script -f foo
> $ blah
> $ ls
> $ sudo rm -fr / # :P
> ^D

Heh. Here's a cute-but-stupid (in a "watch me cut my leg off with a chainsaw - WHOOPS!" way) trick:

ben@Tyr:/tmp/foo$ >-rf			# Create a file called '-rf'
ben@Tyr:/tmp/foo$ mkdir xyz		# Create a directory called 'xyz'
ben@Tyr:/tmp/foo$ >xyz/foobar	# Create a file called 'foobar' in 'xyz/'
ben@Tyr:/tmp/foo$ ls -1F
-rf
xyz/
ben@Tyr:/tmp/foo$ rm *
ben@Tyr:/tmp/foo$ ls
-rf

Note that 'xyz', even though it was non-empty, is gone - and '-rf' is still there.

  UNIX was never designed to keep people from doing stupid things, because
  that policy would also keep them from doing clever things.
 -- Doug Gwyn
-- 
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *


Top    Back


Ben Okopnik [ben at linuxgazette.net]


Tue, 27 May 2008 07:29:46 -0400

On Tue, May 27, 2008 at 01:34:22PM +0700, Mulyadi Santosa wrote:

> Tired of script-generated logs cluttered with escape
> characters all over the place?
> 
> Try to change the terminal into "dumb" and repeat:
> $ export TERM=dumb
> $ script
> <do whatever necessary to be logged>
> <type exit or press Ctrl-D>
> $ export TERM=xterm
> Switch back to vt100, xterm, or other when you're done, to recover your
> terminal's original mode.

This is not specific to 'script', but - if you just want to set a variable's value for the duration of a given program, the syntax works like this:

TERM=dumb script

Doing it this way means that there's no need to reset it at the end (I note that your second invocation would have set it incorrectly for my terminal - which is indeed an xterm):

ben@Tyr:/tmp/foo$ TERM=dumb bash
ben@Tyr:/tmp/foo$ echo $TERM
dumb
ben@Tyr:/tmp/foo$ exit
exit
ben@Tyr:/tmp/foo$ echo $TERM
linux

Incidentally, 'TERM=none' appears to work just as well as 'TERM='dumb'.

-- 
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *


Top    Back


Neil Youngman [Neil.Youngman at youngman.org.uk]


Tue, 27 May 2008 13:20:09 +0100

On Tuesday 27 May 2008 12:29, Ben Okopnik wrote:

> This is not specific to 'script', but - if you just want to set a
> variable's value for the duration of a given program, the syntax works
> like this:
>
> ``
> TERM=dumb script
> ''

This usually works well in BASH, but I'm not sure other shells support this syntax?

Also a badly setup .bashrc may set TERM to what it thinks is right. If that happens, you're stuffed whichever method you use to change $TERM. If you have a .bashrc that overrides variables that you don't want changed, you can always wrap them like this:

if [ -z "$TERM" ]
then
  TERM=vt666
fi

Neil


Top    Back


Ben Okopnik [ben at linuxgazette.net]


Tue, 27 May 2008 09:02:07 -0400

On Tue, May 27, 2008 at 01:20:09PM +0100, Neil Youngman wrote:

> On Tuesday 27 May 2008 12:29, Ben Okopnik wrote:
> > This is not specific to 'script', but - if you just want to set a
> > variable's value for the duration of a given program, the syntax works
> > like this:
> >
> > ``
> > TERM=dumb script
> > ''
> 
> This usually works well in BASH, but I'm not sure other shells support this 
> syntax?

Any Bourne-derived shell will.

ben@Tyr:~$ sh
[sh] ben@Tyr:/home/ben$ echo $TERM
xterm
[sh] ben@Tyr:/home/ben$ TERM=dumb sh
[sh] ben@Tyr:/home/ben$ echo $TERM
dumb
[sh] ben@Tyr:/home/ben$ exit
[sh] ben@Tyr:/home/ben$ ksh
[ksh] ben@Tyr:/home/ben$ echo $TERM
xterm
[ksh] ben@Tyr:/home/ben$ TERM=dumb ksh
[ksh] ben@Tyr:/home/ben$ echo $TERM
dumb
> Also a badly setup .bashrc may set TERM to what it thinks is right. If that 
> happens, you're stuffed whichever method you use to change $TERM. 

Unless, of course, you use the '--norc' option. :)

> If you have 
> a .bashrc that overrides variables that you don't want changed, you can always 
> wrap them like this:
> 
> if [ -z "$TERM" ]
> then
>   TERM=vt666
> fi

The only time that I'm aware of when TERM isn't set is when you login via maintenance mode (and I'm not even sure of that one on Linux - Solaris does this). Modern shells all set their own TERM values, too. I'm not being snarky, but I really would like to know: in what situation would this be useful?

-- 
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *


Top    Back


Neil Youngman [ny at youngman.org.uk]


Tue, 27 May 2008 14:13:42 +0100

On Tuesday 27 May 2008 14:02, Ben Okopnik wrote:

> > Also a badly setup .bashrc may set TERM to what it thinks is right. If
> > that happens, you're stuffed whichever method you use to change $TERM.
>
> Unless, of course, you use the '--norc' option. :)

True, but most people calling a script will be unlikely to do that.

> > If you have
> > a .bashrc that overrides variables that you don't want changed, you can
> > always wrap them like this:
> >
> > if [ -z "$TERM" ]
> > then
> >    TERM=vt666
> > fi
>
> The only time that I'm aware of when TERM isn't set is when you login
> via maintenance mode (and I'm not even sure of that one on Linux -
> Solaris does this). Modern shells all set their own TERM values, too.
> I'm not being snarky, but I really would like to know: in what situation
> would this be useful?

I'm sure I have seen people blindly overriding TERM in their .bashrc's. OTOH, that could just be my memory playing tricks on me?

It's not something I would recommend, but, if someone insists, "I have to make sure it's set" and I can't apply a clue bat, then this allows them to make sure it's set without overriding anything that's already set.

Neil


Top    Back


Thomas Adam [thomas.adam22 at gmail.com]


Tue, 27 May 2008 14:20:31 +0100

2008/5/27 Neil Youngman <ny@youngman.org.uk>:

> I'm sure I have seen people blindly overriding TERM in their .bashrc's. OTOH,
> that could just be my memory playing tricks on me?

No -- it used to be a common trick for people with weird term{cap,info} entries, although this is almost always the wrong way to fixing things.

-- Thomas Adam


Top    Back


Ben Okopnik [ben at linuxgazette.net]


Tue, 27 May 2008 09:51:25 -0400

On Tue, May 27, 2008 at 02:20:31PM +0100, Thomas Adam wrote:

> 2008/5/27 Neil Youngman <ny@youngman.org.uk>:
> > I'm sure I have seen people blindly overriding TERM in their .bashrc's. OTOH,
> > that could just be my memory playing tricks on me?
> 
> No -- it used to be a common trick for people with weird
> term{cap,info} entries, although this is almost always the wrong way
> to fixing things.

Ah. Ah-hah! A light dawns. I can see how someone could go haring off in this direction - and, as you say, it's the wrong one. Thanks - this is kinda like one of those tech-support horror stories...

-- 
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *


Top    Back


Ben Okopnik [ben at linuxgazette.net]


Tue, 27 May 2008 09:49:44 -0400

On Tue, May 27, 2008 at 02:13:42PM +0100, Neil Youngman wrote:

> On Tuesday 27 May 2008 14:02, Ben Okopnik wrote:
> >
> > The only time that I'm aware of when TERM isn't set is when you login
> > via maintenance mode (and I'm not even sure of that one on Linux -
> > Solaris does this). Modern shells all set their own TERM values, too.
> > I'm not being snarky, but I really would like to know: in what situation
> > would this be useful?
> 
> I'm sure I have seen people blindly overriding TERM in their .bashrc's. OTOH,
> that could just be my memory playing tricks on me?
> 
> It's not something I would recommend, but if someone insists, "I have to make 
> sure it's set" and I can't apply a clue bat, then this allows them to make 
> sure it's set without overriding anything that's already set.

That makes sense - it's the sort of "solution" that I've applied in the past (harmless, but pacifies the idiots[1]). Oh, and since I just taught a class on Bash (BTW, "Learning bash" is the first truly awful book I've seen from O'Reilly), here's the Bash way to do it:

${TERM:=some_value}		# Set $TERM to 'some_value' if it's empty

[1] I take a certain grim pleasure from implementing this kind of thing - although I do it with a put-upon air, much gnashing of teeth and (careful) rending of hair, and finally a hang-dog look of defeat. This gives the idiots tons of satisfaction (they *won*!) and makes sure they never bother me about this issue again (given what a hassle it was the last time.)

I just love these little corporate games. That's why I'm a consultant.

-- 
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *


Top    Back