...making Linux just a little more fun!
Mulyadi Santosa [mulyadi.santosa at 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 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.
Thomas Adam [thomas.adam22 at gmail.com]
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
Mulyadi Santosa [mulyadi.santosa at gmail.com]
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.
Ben Okopnik [ben at linuxgazette.net]
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 * https://LinuxGazette.NET *
Ben Okopnik [ben at linuxgazette.net]
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 * https://LinuxGazette.NET *
Neil Youngman [Neil.Youngman at youngman.org.uk]
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
Ben Okopnik [ben at linuxgazette.net]
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 * https://LinuxGazette.NET *
Neil Youngman [ny at youngman.org.uk]
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
Thomas Adam [thomas.adam22 at gmail.com]
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
Ben Okopnik [ben at linuxgazette.net]
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 * https://LinuxGazette.NET *
Ben Okopnik [ben at linuxgazette.net]
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 * https://LinuxGazette.NET *