I was just curious to know if there any difference in keeping the record of the terminal commands using script filename
and manually copying it from terminal. Please tell me if there exists a bit of diffrence. What i know is using script command brings unnecessary keystrokes to file.
-
Did u try the 'history' command?– JayDec 9, 2015 at 11:31
-
Yes i have tried. I just need to know if there are difference between above two methods– AbiralDec 9, 2015 at 11:32
-
I don't think so. But it is not difficult to find out. Just type some commands using both the methods and check it yourself.– JayDec 9, 2015 at 11:37
3 Answers
The script
command creates a script containing all your interactions with the terminal for your current session. It is basically creating a live screen dump and pasting the contents into a file.
It includes all inputs and outputs visible in the terminal.
The history
command gives you all the commands entered into the terminal from the first time you used it.
It shows only inputs, either for your current session or for all sessions.
There is a difference, but not how you might think.
The terminal can support ASCII characters - 0 to 127. This includes the Western, Latin Alphabet, including some accents like the grave accent ` and the punctuation like { and ~.
So when you copy paste from a terminal emulator you are copying ASCII characters into a UTF-8 file (most likely). Of course, UTF-8 and ASCII are compatible. The characters 0 to 127 in UTF-8 are the same as ASCII.
When you output into a file, it will be ASCII by default, however that can be changed.
So why would anyone use redirection to a file if it's a less good encoding? Automation or Incompatibility.
The terminal you are using (likely Gnome Terminal or X-Term) is a terminal emulator - a terminal inside a graphical window.
But some terminal aren't like this - they are completely non graphical, CLI only - like the TTY terminals, accessed with Ctrl + Alt + FX where X
is a number from 1 to 6. E.g. to access TTY2, use Ctrl + Alt + F2.
These terminals have no mouse - so you can't copy the output, or even scroll it.
If you are running a command with a lot of output you can either output it to a file and use nano
or vi
to view it, or you could use the less
command, so allow arrow key scrolling.
And if I have a code to monitor my dreadful internet speeds so I can get a discount on the cost of the internet I might want to automatically save the speed to a file - for example redirect the output of wget
to a file.
This is the main use case - a computer can do it without any human input, and without a GUI. In these cases, the lack of characters like 🦄 and ☺ is not a big deal - you're just saving numbers essentially.
If you want to share the output, pastebinit
is an excellent command. Simply run yourcommand | pastebinit
and it will upload it to paste.ubuntu.com
and give you the link.
-
You can scroll output on TTYs with Shift-PgUp/PgDn.
gpm
provides a mouse for TTYs, which can paste highlighted text with the middle button like in X11.– bmclainDec 9, 2015 at 16:26 -
I didn't remember to remove my downvote on this, I removed it now, because I rather wanted to post a comment but couldn't before. The first part is misleading, only the console doesn't support UTF-8, all of the other preinstalled virtual terminals (and most virtual terminals in general) do support UTF-8.The format of the output file is determined by the output, if the output contains UTF-8 characters the output file's encoding is set to UTF-8.Finally there's no incompatibility, because even in the console where UTF-8 characters are not printed they're still outputted correctly to the file.– kosDec 9, 2015 at 16:58
In short, script
command captures more than just text, and on a different level.
For instance ls
command. To produce coloured output, ls adds special characters to each entry(read more about it here). If you were to call ls
while script
is capturing output, those special chars will be captured. It will also capture escape characters you may have pressed with the keyboard.
script
also captures everything on that invisible, lower, system level.
With manual selecting text and copying, you are doing what ? Selecting text inside the X graphical server, right ? So where does the text come from and go ? It comes already rendered, already post processed,colorized, so it doesn't necessarily contain the special characters. It also goes into the clipboard ( which by the way is one of 3 in X server system ), then when you paste gets released from the clipboard.
script
is good for when you want to record lengthy session, and pass it on to someone. The special characters are no problem when you just run default commands, not the colorized ones (by default ls is aliased to ls --color=auto
). So you either can use backslash to escape aliases\ls
or use this solution from stackoverflow site.
As for copy-paste method, it's good for short output that you just want to pass on and forget about
Additions
I've also noticed you are more interested in history
vs script
for recoding list of commands that you enter in terminal. Difference between them is that history only keeps records of what you tell the terminal to run. script
is like recording of your terminal, where everything is captured.
They are storing data differently too. While for bash the .bash_history
it's text, other shell may choose a data file. For instance here's comparison of my mksh
history file, vs .bash_history
, vs typescript
xieerqi@eagle:~$ file MKSHHISTFILE
MKSHHISTFILE: data
xieerqi@eagle:~$ file .bash_history
.bash_history: UTF-8 Unicode text
xieerqi@eagle:~$ file typescript
typescript: ASCII text, with CRLF, LF line terminators
With history
, it's different from shell to shell. bash
by default keeps everything in .bash_history
, while with shells like ksh
or mksh
and dash
, history file has to be set by the user. script
,by default stores everything in typescript
file, but user can specify another file,too.
Finally, history is one of builtins to a shell, which will always be present, but may or may not need to be configured. script
is a utility, which may or may not be present, but needs no config.