Util-linux cheat sheet(catonmat.net)
catonmat.net
Util-linux cheat sheet
http://www.catonmat.net/blog/util-linux-cheat-sheet/
2 comments
Which control characters?
And you say around file names... did you run "ls" while in your script session? if you generated colorized output, script will record that.
If you don't want colorized output, run "\ls" (bypass any alias you might have for ls, and just run ls directly) or use "ls --color=never".
You'll still see ^M at the end of each line.
You can run "dos2unix typescript" to strip those out.
It's script's job to record your entire session, including any control characters, and it does that.
And you say around file names... did you run "ls" while in your script session? if you generated colorized output, script will record that.
If you don't want colorized output, run "\ls" (bypass any alias you might have for ls, and just run ls directly) or use "ls --color=never".
You'll still see ^M at the end of each line.
You can run "dos2unix typescript" to strip those out.
It's script's job to record your entire session, including any control characters, and it does that.
For more joy:
script --timing=typescript.time
<stuff>
exit
scriptreplay -t typescript.time typescript
I bet you've got ls set to colorize file names, right? What you're seeing as"control characters around file names" is VT-100 escape codes to colorize the text different ways. If you do command-line editing in Bash (vi or emacs mode) you'll also see all the control characters that implement the editing. Again, more VT-100 escape code to position the cursor, overwrite characters, etc etc.
Either you set ls to not colorize filenames, or you edit the 'typescript' file. One of the values of script is that it doesn't do any interpretation of the characters it records.
Either you set ls to not colorize filenames, or you edit the 'typescript' file. One of the values of script is that it doesn't do any interpretation of the characters it records.
You are correct- that is exactly what it is. Thanks.
cat the file.
Interesting- the control characters get re-interpreted into screen commands. Thanks for that.
You can achieve the some of the same results with less -R and you also get searching and scrolling. (It colorizes ls's output, but it doesn't do the scrolling or screen-clearing stuff.)
To get a handle on why this happens, think of it this way: Back in 1983 using Unix (and I mean a full-size Serious Unix, not Xenix for the 8088 or anything) meant hooking a text terminal (like the brand-new VT-220!) to a minicomputer (like a PDP-11 or a VAX) over a serial line, possibly also involving a modem.
Now you only have one communication channel between your text terminal and the computer. That's a bidirectional link that ships characters at, say, 120 characters per second, a good speed for the time. Given that there is only one channel to work with, if you want to make some text underlined, for example, you have to tell the terminal to do it using in-band signalling. The VT-220 has a complex set of such commands, or control codes, prefixed with the ESC character (0x1b in ASCII). In-band means everything is done using the same line, so there is fundamentally no difference between the characters in the "Hello, world!" your application prints and the control codes that make some of ls's output bold.
And that's it: If an application sends a sequence of characters that's a control code recognized by the terminal, the terminal will interpret it and do something special, like make the following text yellow-on-red and blinking. (The VT-220 might not have been able to do color, but other terminals could, including terminal emulation software for the IBM PC, say.)
The catch is, there was very little standardization about what control codes did what. ANSI tried to standardize, and was successful to the extent the popular VT-100 family followed the standard at least partway, but it was too complex a standard to succeed completely. These days, of course, pretty much everyone uses xterms and they're pretty close to the ANSI standard as well. On the other hand, back when ADM-3As and Wyse 60s roamed the Earth, just about all you could assume was that all of the printable ASCII characters (plus space) would make the appropriate characters on the screen and that CR (0x0d) would be a carriage return.
That lack of standardization is why termcap and terminfo exist: They map 'what the terminal can do' with 'how to do it' in terms of control codes. It's also why curses and ncurses were written (as APIs to abstract 'what' from 'how'), and why terminal handling code has largely been done via an API of some kind for the past three decades or so. ncurses is like Xlib for text terminals, right down to the network transparency.
Here's an interesting article on modem speeds because it's Saturday: http://www.textfiles.com/computers/bitsbaud.txt
Here's a page where you can download massive termcap and terminfo files, if you ever need to know how to make an ADM-3A clear its screen: http://www.catb.org/terminfo/
To get a handle on why this happens, think of it this way: Back in 1983 using Unix (and I mean a full-size Serious Unix, not Xenix for the 8088 or anything) meant hooking a text terminal (like the brand-new VT-220!) to a minicomputer (like a PDP-11 or a VAX) over a serial line, possibly also involving a modem.
Now you only have one communication channel between your text terminal and the computer. That's a bidirectional link that ships characters at, say, 120 characters per second, a good speed for the time. Given that there is only one channel to work with, if you want to make some text underlined, for example, you have to tell the terminal to do it using in-band signalling. The VT-220 has a complex set of such commands, or control codes, prefixed with the ESC character (0x1b in ASCII). In-band means everything is done using the same line, so there is fundamentally no difference between the characters in the "Hello, world!" your application prints and the control codes that make some of ls's output bold.
And that's it: If an application sends a sequence of characters that's a control code recognized by the terminal, the terminal will interpret it and do something special, like make the following text yellow-on-red and blinking. (The VT-220 might not have been able to do color, but other terminals could, including terminal emulation software for the IBM PC, say.)
The catch is, there was very little standardization about what control codes did what. ANSI tried to standardize, and was successful to the extent the popular VT-100 family followed the standard at least partway, but it was too complex a standard to succeed completely. These days, of course, pretty much everyone uses xterms and they're pretty close to the ANSI standard as well. On the other hand, back when ADM-3As and Wyse 60s roamed the Earth, just about all you could assume was that all of the printable ASCII characters (plus space) would make the appropriate characters on the screen and that CR (0x0d) would be a carriage return.
That lack of standardization is why termcap and terminfo exist: They map 'what the terminal can do' with 'how to do it' in terms of control codes. It's also why curses and ncurses were written (as APIs to abstract 'what' from 'how'), and why terminal handling code has largely been done via an API of some kind for the past three decades or so. ncurses is like Xlib for text terminals, right down to the network transparency.
Here's an interesting article on modem speeds because it's Saturday: http://www.textfiles.com/computers/bitsbaud.txt
Here's a page where you can download massive termcap and terminfo files, if you ever need to know how to make an ADM-3A clear its screen: http://www.catb.org/terminfo/
Awesome stuff, derleth. I do remember the days of ctrl-h backspace and ctrl-g ringing a bell. I also remember playing with the escape codes more-- goofy high school ('70s) and college ('80s) tricks. Back in the days of "Creative Computing" (later -> Byte)
Almost forgot: Under xterm, at least, ^V is the escape character and ^[ is ESC, so you can type things like:
$ echo '^[[0m^[[01;32mfoo^[[0m'
with a ^V before every ^[ (the ^V doesn't get echoed back to you unless you type ^V^V to enter a single ^V). That makes 'foo' bold and lime green.
Once you learn how to read a terminfo file, you can do everything your terminal is capable of (and xterm can do quite a bit) entirely by typing control codes by hand. Which is pointless, given that tput, from the ncurses package, does the same thing in a much more user-friendly way that's also completely terminal-independent.
http://en.wikipedia.org/wiki/Ncurses
http://www.gnu.org/software/ncurses/ncurses.html
http://en.wikipedia.org/wiki/Tput
http://tldp.org/HOWTO/Bash-Prompt-HOWTO/x405.html -- Explicitly about using tput, which really is a neat way to make your shell script's output look nice.
$ echo '^[[0m^[[01;32mfoo^[[0m'
with a ^V before every ^[ (the ^V doesn't get echoed back to you unless you type ^V^V to enter a single ^V). That makes 'foo' bold and lime green.
Once you learn how to read a terminfo file, you can do everything your terminal is capable of (and xterm can do quite a bit) entirely by typing control codes by hand. Which is pointless, given that tput, from the ncurses package, does the same thing in a much more user-friendly way that's also completely terminal-independent.
http://en.wikipedia.org/wiki/Ncurses
http://www.gnu.org/software/ncurses/ncurses.html
http://en.wikipedia.org/wiki/Tput
http://tldp.org/HOWTO/Bash-Prompt-HOWTO/x405.html -- Explicitly about using tput, which really is a neat way to make your shell script's output look nice.
Well, I guess that about makes thoughts of doing anything useful the rest of today pointless....This is way too fun.
Haven't looked at the cheat sheets but...
If you just want something readable, a couple of quick and dirty ways are:
If you just want something readable, a couple of quick and dirty ways are:
col -bx < typescript|less
strings typescript |less
strings typescript|sed '1d;/deleteme/d;s/deleteme//g'|less
Thanks. It was more curiosity necessity (although now my mind is thinking, "what can I use this for?").
- interesting with ttyrec/ttyplay. I'll check on this if my mind comes up with something important.
- interesting with ttyrec/ttyplay. I'll check on this if my mind comes up with something important.
I'm guessing this was generated by running `man -f` on the list of executables provided by util-linux.
descriptions() { xargs -I '{}' man -f '{}' ; }
executables() { pkgfile -bl $1 | cut -f 2; } # Arch Linux specific
executables util-linux | descriptions 2> missed | sort | less
But when looking at my output file (if you just do what I did above it will be called 'typescript') it has control characters around the file names. How can I suppress these?