Linux direct output to a file. Redirection of standard input/output streams. How to increase the scrollback buffer
If the output to the (graphical) console is not very voluminous, you can simply select a piece with the mouse and insert it into the message by clicking the middle button. Otherwise, you can use redirection of output to a file via a funnel, like this:
Some_command parameters > logfile.txt
To see the execution result on the screen and at the same time write to a file, you can use the tee command:
Some_command parameters | tee -a logfile.txt
The setterm -dump command creates a snapshot of the current virtual console buffer as a simple text file with the default name screen.dump. As its argument, you can use the number of the console for which you want to dump. And adding the -file filename option will redirect this dump to a file with the specified name. The -append option will append a new dump to an already existing file - the “default” screen.dump or named with the -file option.
Those. after using the command like
Setterm -dump -file /root/screenlog
respectively in the file /root/screenlog will be the contents of one console page.
I found another solution for copying/pasting text in a text console without a mouse. You can also copy text from the scroll buffer (i.e. everything on the screen and above the screen). To better understand, read about the console window manager screen. It may also be useful to increase the scroll buffer size.
1) Launch screen
2) Press Enter. All. We are in console window zero.
3) Execute the necessary commands, the output of which must be copied.
4) Ctrl+A, Ctrl+[ - we are in copy mode. Place the cursor at the beginning of the selection, press Spacebar, then place the cursor at the end of the selection, press Spacebar. The text has been copied to the clipboard.
5) Ctrl+A, c - we have created a new 1st window.
6) Ctrl+A, 1 - we went to the 1st window.
7) Open any (?) text editor(I tried it in mc), and press Ctrl+A, Ctrl+] - the text is inserted. Save.
8) Ctrl+A, Ctrl+0 - go back to the zero window.
How to increase the scrollback buffer?
The first solution would be to increase the default buffer size in the kernel sources and recompile it. Let me assume that you are as averse to this as I am and look for a more flexible solution.
And there is such a tool, and it’s called framebuffer console, fbcon for short. This device has a documentation file fbcon.txt; if you installed the kernel documentation, then you have it. Look for him somewhere in the area /usr/share branches (I can't specify the exact path due to differences in distributions).
At this point, I apologize: we must make a small digression and talk a little about the video buffer ( framebuffer ).
A video buffer is a buffer between the display and the video adapter. Its beauty is that it can be manipulated: it allows tricks that would not work if the adapter were connected directly to the display.
One such trick involves the scroll buffer; It turns out you can "ask" the video buffer to allocate more memory to the scroll buffer. This is achieved through kernel boot parameters. First you demand framebuffer(video buffer); Then you request a larger scroll buffer.
The following example is for GRUB, but can easily be adapted to LILO. In the GRUB configuration file - menu.lst- find the line corresponding to the kernel, and then: Remove the vga=xxx option, if present. Add the option video=vesabf or whatever matches your hardware. Add the fbcon=scrollback:128 option. After this procedure, the kernel parameter line should look something like this:
Kernel /vmlinuz root=/dev/sdb5 video=radeonfb fbcon=scrollback:128
The question is, why remove the vga=xxx option? Due to possible conflicts with the video option. On my ATI adapter, I can't change the scroll buffer if vga=xxx is in the list. This may not be the case in your case. If the above options work, good; but what if you want to increase the number of lines, or set a smaller font on the screen? You always did this using the vga=xxx option - and that's what disappeared. Don't worry - the same thing can be achieved by changing the fbcon parameters as described in the file fbcon.txt(but not described in this article).
With the fbcon=scrollback:128 option, my scroll buffer increased to 17 screens (35 times Shift+PgUp across half a screen). By the way, 128 is a kilobyte. The author of the article claims that nothing more can be established. I haven't tried it.
You can use script.
Script filename.log
when all the necessary commands are completed -
Everything is recorded in filename.log
FreeBSD has a wonderful watch utility that allows you to monitor terminals, but as it turns out, in Linux it performs completely different functions =\ If you google this topic, you will find something...
Redirection is usually accomplished by inserting the special character ">" between commands. Typically the syntax looks like this:
Command1 > file1
executes command1, writing standard output to file1.
Team1< файл1
executes command1 using file1 as the input source (instead of the keyboard).
Team1< файл1 >file2
combines the two previous options. Executes command1 with input from file1 and output to file2
Conveyors
Pipelines are the ability of multiple programs to work together, where the output of one program goes directly to the input of another without the use of intermediate temporary files. Syntax:
team1 | team2
Executes command1 using its output stream as the input stream when executing command2, which is equivalent to using two redirections and a temporary file:
Command1 > TemporaryFile command2< ВременныйФайл rm ВременныйФайл
A good example of command pipelines is combining echo with another command to achieve interactivity in non-interactive environments, for example:
echo -e "Username\nPassword" | ftp localhost
This starts a client that connects to localhost as UserName, presses Enter and then enters the password Password.
Redirection to/from standard file descriptors
In the UNIX command shell, which is derived from the Bourne shell, the previous two steps can be improved upon by specifying a number (file descriptor) immediately before the redirection character. This number indicates which stream is used for redirection. UNIX has the following standard input/output streams:
Eg:
Command1 2 > file1
In command shells derived from the C Shell, according to the rules of syntax, to indicate the stream to which the redirection is carried out, you need to add the & character after the redirection character.
Often the standard error stream is combined with the standard output stream so that errors and normal program output can be handled together. Eg:
Find / -name .profile> results.txt 2>&1
will try to find all files named .profile. If you run this command without redirections, it will direct search results to , and error messages (for example, about insufficient access rights when trying to search in protected directories) to . By default, these roles are performed by the console. If standard output is directed to the results file, then errors will still be sent to the console. To ensure that both errors and search results are sent to the results.txt file, the standard error and output streams are combined using 2>&1 .
Writing 2>&1 before > won't work because when the interpreter reads 2>&1 , it does not yet know where the standard output stream is redirected, so the error and output streams will not be merged.
If the combined result is to be piped to the input of another program, then the sequence 2>&1 must be in front of the conveyor sign. Eg:
Find / -name .profile 2>&1 | less
Simplified command form:
Command>file2>&1
looks like that:
Command &> file
Command>&file
Conveyor chain
Redirection and piping commands can be chained together to produce more complex commands, for example:
ls | grep ".sh" | sort>shlist
Gets a list of the contents of the current directory, which is filtered, leaving only lines containing ".sh", then this filtered list is lexically sorted and the final result is put into a file shlist. Constructs of this type are often found in UNIX shell scripts.
Redirection to multiple pins
A standard command can redirect command output to multiple places at once. Example:
Ls -lrt | tee file1
directs the standard output of the command ls -lrt(list of files) both in the console and in file1.
Redirect with append
In the command shell, you can redirect to a file and append it to the end. In this case, the information stored in the file will not be deleted, and all new information will be added to the end of this file. Syntax:
Command1>> file1
Embedded document
Some shells, and even applied languages (PHP), Perl, allow the syntax of built-in documents (see Heredoc syntax), which allows you to direct the input stream from the program file itself, for example: cat « EOF Any text is placed here, including Special symbols EOF
The final signature of the end of the embedded document EOF (an arbitrary value can be used, but EOF is often used - according to the meaning) must begin at the beginning of the line.
You are already familiar with two methods of working with what scripts output command line:
- Displaying the output data on the screen.
- Redirect output to a file.
Standard file descriptors
Everything in Linux is files, including input and output. operating system identifies files using descriptors.Each process is allowed to have up to nine open file handles. bash shell reserves the first three handles with IDs 0, 1 and 2. Here's what they mean.
- 0 , STDIN - standard input stream.
- 1, STDOUT - standard output stream.
- 2, STDERR - standard error stream.
You need to really understand standard streams. They can be compared to the foundation on which the interaction of scripts with the outside world is built. Let's look at the details about them.
STDIN
STDIN is the shell's standard input stream. For a terminal, standard input is the keyboard. When scripts use the input redirection character -< , Linux заменяет дескриптор файла стандартного ввода на тот, который указан в команде. Система читает файл и обрабатывает данные так, будто они введены с клавиатуры.Many bash commands accept input from STDIN unless the command line specifies a file from which to take the data. For example, this is true for the cat command.
When you enter the cat command at the command line without specifying any parameters, it accepts input from STDIN. After you enter the next line, cat simply displays it on the screen.
STDOUT
STDOUT is the shell's standard output stream. By default this is the screen. Most bash commands output data to STDOUT, which causes it to appear in the console. Data can be redirected to a file by appending it to its contents using the >> command.So we have a data file to which we can add more data using this command:
Pwd >> myfile
What pwd outputs will be added to the file myfile , but the data already in it will not go anywhere.
Redirecting command output to a file
So far so good, but what if you try to do something like the following by accessing a non-existent xfile, all designed to cause an error message to be sent to myfile.
Ls –l xfile > myfile
After executing this command, we will see error messages on the screen.
Attempting to access a non-existent file
An error is generated when attempting to access a non-existent file, but the shell did not redirect error messages to the file by printing them to the screen. But we wanted error messages to be included in the file. What to do? The answer is simple - use the third standard descriptor.
STDERR
STDERR is the shell's standard error stream. By default, this handle points to the same thing that STDOUT points to, which is why we see a message on the screen when an error occurs.So, let's say we want to redirect error messages to, say, a log file or somewhere else, instead of printing them to the screen.
▍Redirect error flow
As you already know, the file handle STDERR is 2. We can redirect errors by placing this handle before the redirect command:Ls -l xfile 2>myfile cat ./myfile
The error message will now go to myfile.
Redirecting an error message to a file
▍Redirect error and output streams
When writing command line scripts, there may be situations where you need to redirect both error messages and standard output. In order to achieve this, you need to use redirection commands for the appropriate descriptors, specifying the files where errors and standard output should go:Ls –l myfile xfile anotherfile 2> errorcontent 1> correctcontent
Redirecting errors and standard output
The shell will redirect what the ls command would normally send to STDOUT into the correctcontent file thanks to the 1> construct. Error messages that would go to STDERR end up in the errorcontent file due to the 2> redirect command.
If necessary, both STDERR and STDOUT can be redirected to the same file using the &> command:
Redirecting STDERR and STDOUT to the same file
After the command is executed, what is intended for STDERR and STDOUT ends up in the content file.
Redirecting output in scripts
There are two methods for redirecting output in command line scripts:- Temporary redirection, or single line output redirection.
- Permanent redirection, or redirection of all or part of a script's output.
▍Temporary output redirection
In a script, you can redirect the output of a single line to STDERR. In order to do this, just use the redirection command, specifying the STDERR descriptor, and precede the descriptor number with an ampersand character (&):#!/bin/bash echo "This is an error" >&2 echo "This is normal output"
If you run the script, both lines will appear on the screen, since, as you already know, by default errors are output in the same place as normal data.
Temporary redirection
Let's run the script so that the STDERR output goes to a file.
./myscript 2> myfile
As you can see, now normal output is sent to the console, and error messages go to a file.
Error messages are written to a file
▍Permanent output redirection
If your script needs to redirect a lot of output to the screen, it is inconvenient to add the appropriate command to each echo call. Instead, you can set the output to be redirected to a specific handle for the duration of the script using the exec command:#!/bin/bash exec 1>outfile echo "This is a test of redirecting all output" echo "from a shell script to another file." echo "without having to redirect every line"
Let's run the script.
Redirecting all output to a file
If you look at the file specified in the output redirection command, you will find that everything that was output by the echo commands ended up in that file.
The exec command can be used not only at the beginning of the script, but also in other places:
#!/bin/bash exec 2>myerror echo "This is the start of the script" echo "now redirecting all output to another location" exec 1>myfile echo "This should go to the myfile file" echo "and this should go to the myerror file" >&2
This is what you get after running the script and looking at the files to which we redirected the output.
Redirecting output to different files
The exec command first redirects output from STDERR to the file myerror . The output of several echo commands is then sent to STDOUT and printed to the screen. The exec command then causes whatever ends up in STDOUT to be sent to the file myfile , and finally we use the redirect command to STDERR in the echo command, which causes the corresponding line to be written to the file myerror.
Once you've mastered this, you'll be able to redirect output where you want it to go. Now let's talk about input redirection.
Redirecting input in scripts
To redirect input, you can use the same technique that we used to redirect output. For example, the exec command allows you to make a file the source of data for STDIN:Exec 0< myfile
This command tells the shell that the input source should be myfile rather than the normal STDIN. Let's see input redirection in action:
#!/bin/bash exec 0< testfile
count=1
while read line
do
echo "Line #$count: $line"
count=$(($count + 1))
done
This is what will appear on the screen after running the script.
Input redirection
In an earlier article, you learned how to use the read command to read user input from the keyboard. If you redirect input by making the data source a file, then the read command, when trying to read data from STDIN, will read it from the file, and not from the keyboard.
Some Linux administrators use this approach to read and then process log files.
Creating your own output redirection
By redirecting input and output in scripts, you are not limited to the three standard file descriptors. As already mentioned, you can have up to nine open handles. The remaining six, numbered 3 through 8, can be used to redirect input or output. Any of them can be assigned to a file and used in script code.You can assign a handle to output data using the exec command:
#!/bin/bash exec 3>myfile echo "This should display on the screen" echo "and this should be stored in the file" >&3 echo "And this should be back on the screen"
After running the script, part of the output will appear on the screen, part - in a file with descriptor 3.
Redirecting output using its own handle
Creating File Descriptors for Data Entry
You can redirect input in a script in the same way as you redirect output. Store STDIN in another handle before redirecting input.After finishing reading the file, you can restore STDIN and use it as usual:
#!/bin/bash exec 6<&0
exec 0< myfile
count=1
while read line
do
echo "Line #$count: $line"
count=$(($count + 1))
done
exec 0<&6
read -p "Are you done now? " answer
case $answer in
y) echo "Goodbye";;
n) echo "Sorry, this is the end.";;
esac
Let's try out the scenario.
Input redirection
In this example, file descriptor 6 was used to store a reference to STDIN. Then input redirection was done, the file became the data source for STDIN. The input to the read command then came from the redirected STDIN, that is, from the file.
After reading the file, we reset STDIN by redirecting it to handle 6. Now, in order to check that everything is working correctly, the script asks the user a question, waits for keyboard input, and processes what is entered.
Closing file handles
The shell automatically closes file handles after the script completes. However, in some cases it is necessary to close handles manually before the script finishes running. In order to close a handle, it must be redirected to &- . It looks like this:#!/bin/bash exec 3> myfile echo "This is a test line of data" >&3 exec 3>&- echo "This won't work" >&3
After executing the script, we will receive an error message.
Attempting to access a closed file descriptor
The thing is that we tried to access a non-existent descriptor.
Be careful when closing file handles in scripts. If you sent data to a file, then closed the handle, then opened it again, the shell will replace the existing file with a new one. That is, everything that was previously written to this file will be lost.
Getting information about open handles
To get a list of all handles open in Linux, you can use the lsof command. On many distributions, such as Fedora, the lsof utility is located in /usr/sbin. This command is quite useful because it displays information about each handle that is open on the system. This includes what is opened by processes running in the background and what is opened by logged-in users.This command has many keys, let's look at the most important ones.
- -p Allows you to specify the process ID.
- -d Allows you to specify the number of the descriptor about which you want to obtain information.
The -a switch is used to perform a logical AND operation on the results returned by using the other two switches:
Lsof -a -p $$ -d 0,1,2
Displaying information about open handles
The type of files associated with STDIN, STDOUT and STDERR is CHR (character mode). Since they all point to a terminal, the file name matches the name of the device assigned to the terminal. All three standard file available for both reading and writing.
Let's look at calling the lsof command from a script in which, in addition to the standard ones, other descriptors are open:
#!/bin/bash exec 3> myfile1 exec 6> myfile2 exec 7< myfile3
lsof -a -p $$ -d 0,1,2,3,6,7
This is what happens if you run this script.
View file handles opened by a script
The script opened two handles for output (3 and 6) and one for input (7). The paths to the files used to configure the descriptors are also shown.
Output Suppression
Sometimes you need to make sure that the commands in a script, which, for example, can be executed like background process, nothing was displayed on the screen. To do this, you can redirect the output to /dev/null . This is something like a “black hole”.Here's an example of how to suppress error messages:
Ls -al badfile anotherfile 2> /dev/null
The same approach is used if, for example, you need to clear a file without deleting it:
Cat /dev/null > myfile
Results
Today you learned about how input and output work in command line scripts. Now you know how to handle file descriptors, create, view and close them, and know about redirecting input, output and error streams. All this is very important in the development of bash scripts.Next time we'll talk about Linux signals, how to handle them in scripts, running scheduled jobs, and background tasks.
Dear readers! This material provides the basics of working with input, output, and error streams. We are sure that among you there are professionals who can tell you about all this what only comes with experience. If so, we pass the floor to you.
In the system, by default, three “files” are always open - (keyboard), (screen) and (displaying error messages on the screen). These, and any other open files, can be redirected. In this case, the term "redirection" means to take the output from a file, command, program, script, or even a single block in a script (see Example 3-1 and Example 3-2) and pass it as input to another file, command, program or script.
Each open file has a file descriptor associated with it. The file descriptors, and are 0, 1 and 2, respectively. When opening additional files, descriptors 3 to 9 remain unoccupied. Sometimes additional descriptors can do a good job, temporarily storing a link to, or. This makes it easier to return handles to their normal state after complex redirection and swap manipulations (see Example 16-1).
COMMAND_OUTPUT > # Redirect stdout (output) to a file. # If the file was missing, it will be created, otherwise it will be overwritten. ls -lR > dir-tree.list # Creates a file containing a list of a directory tree. : > filename # The operation > truncates the file "filename" to length zero. # If the file did not exist before the operation, # then a new file with zero length is created (the "touch" command has the same effect). # The symbol: acts as a placeholder here, without outputting anything. > filename # The operation > truncates the file "filename" to length zero. # If the file did not exist before the operation, # then a new file with zero length is created (the "touch" command has the same effect). # (same result as ":>" above, but this option does not work # in some shells.) COMMAND_OUTPUT >> # Redirect stdout (output) to a file. # Creates a new file if it was missing, otherwise appends it to the end of the file. # Single-line redirection commands # (affect only the line on which they appear): # ——————————————————————— 1>filename # Redirect output (stdout) to file "filename". 1>>filename # Redirect output (stdout) to file "filename", the file is opened in append mode. 2>filename # Redirect stderr to file "filename". 2>>filename # Redirect stderr to file "filename", the file is opened in append mode. &>filename # Redirect stdout and stderr to file "filename". #=================================================== ============================= # Redirect stdout, for one line only. LOGFILE=script.log echo "This line will be written to the file \"$LOGFILE\"." 1>$LOGFILE echo "This line will be added to the end of the \"$LOGFILE\" file." 1>>$LOGFILE echo "This line will also be added to the end of the \"$LOGFILE\" file." 1>>$LOGFILE echo "This line will be printed to the screen and will not end up in the \"$LOGFILE\" file." # After each line, the redirection made is automatically reset. # Redirect stderr, for one line only. ERRORFILE=script.errors bad_command1 2>$ERRORFILE # The error message will be written to $ERRORFILE. bad_command2 2>>$ERRORFILE # An error message will be added to the end of $ERRORFILE. bad_command3 # The error message will be printed to stderr, #+ and will not go to $ERRORFILE. # After each line, the redirection made is also automatically reset. #=================================================== ============================= 2>&1 # Redirects stderr to stdout. # Error messages are sent to the same place as standard output. i> i V j. # Output to file with descriptor i passed to file with descriptor j. >&j # File descriptor is redirected 1
(stdout) to a file with a descriptor j. # Output to stdout is sent to file descriptor j. 0< FILENAME < FILENAME # Ввод из файла. # Парная команде ">", often found in combination with it. # # grep search-word
Redirection operations and/or pipelines can be combined on the same command line.
command< input-file >output-file command1 | command2 | command3 > output-file See Example 12-23 and Example A-17.
It is possible to redirect multiple streams to one file.
ls -yz >> command.log 2>&1 # A message about an invalid "yz" option in the "ls" command will be written to the "command.log" file. # Because stderr is redirected to a file.
Closing file handles
Close the input file descriptor.
0<&-, <&-
Close the output file descriptor.
1>&-, >&-
Child processes inherit handles open files. This is why conveyors work. To prevent handles from being inherited, close them before starting the child process.
# Only stderr is passed into the pipeline. exec 3>&1 # Save the current "state" to stdout. ls -l 2>&1 >&3 3>&- | grep bad 3>&- # Close desc. 3 for "grep" (but not for "ls"). # ^^^^ ^^^^ exec 3>&- # Now close it for the rest of the script. # Thanks S.C.
For more information about I/O redirection, see Appendix D.
16.1. Using the command exec
Team exec
Example 16-1. Redirecting with exec
#!/bin/bash # Redirect stdin using "exec". exec 6<&0 # Связать дескр. #6 со стандартным вводом (stdin). # Сохраняя stdin. exec < data-file # stdin заменяется файлом "data-file" read a1 # Читается первая строка из "data-file". read a2 # Читается вторая строка из "data-file." echo echo "Следующие строки были прочитаны из файла." echo "——————————————" echo $a1 echo $a2 echo; echo; echo exec 0<&6 6<&- # Восстанавливается stdin из дескр. #6, где он был предварительно сохранен, #+ и дескр. #6 закрывается (6<&-) освобождая его для других процессов. # # <&6 6<&- дает тот же результат. echo -n "Введите строку " read b1 # Теперь функция "read", как и следовало ожидать, принимает данные с обычного stdin. echo "Строка, принятая со stdin." echo "—————————" echo "b1 = $b1" echo exit 0
Likewise, the design exec >filename redirects output to the specified file. After this, all output from commands that would normally be directed to is now output to this file.
Example 16-2. Redirecting with exec
#!/bin/bash # reassign-stdout.sh LOGFILE=logfile.txt exec 6>&1 # Link desc. #6 with stdout. # Storing stdout. exec > $LOGFILE # stdout is replaced by the file "logfile.txt". # ———————————————————— # # All output from the commands in this block is written to the $LOGFILE file. echo -n "Logfile: " date echo "————————————-" echo echo "Output of \"ls -al\"" echo ls -al echo; echo echo "Output of the command \"df\"" echo df # ———————————————————— # exec 1>&6 6>&- # Restore stdout and close the file. #6. echo echo "== stdout restored to default == " echo ls -al echo exit 0
Example 16-3. Simultaneous redirection of devices, and, using the exec command
#!/bin/bash # upperconv.sh # Convert characters in the input file to uppercase. E_FILE_ACCESS=70 E_WRONG_ARGS=71 if [ ! -r "$1" ] # Is the file readable? then echo "Unable to read due to of this file!" echo "Usage: $0 input-file output-file" exit $E_FILE_ACCESS fi # In case the input file ($1) is not specified #+ the exit code will be the same. if [ -z "$2" ] then echo " An output file must be specified." echo "Usage: $0 input-file output-file" exit $E_WRONG_ARGS fi exec 4<&0 exec < $1 # Назначить ввод из входного файла. exec 7>&1 exec > $2 # Assign output to an output file. # Assuming the output file is writable # (add check?). # ———————————————— cat — | tr a-z A-Z # Convert to uppercase # ^^^^^ # Read from stdin. # ^^^^^^^^^^ # Write to stdout. # However, both stdin and stdout were redirected. # ———————————————— exec 1>&7 7>&- # Restore stdout. exec 0<&4 4<&- # Восстановить stdin. # После восстановления, следующая строка выводится на stdout, чего и следовало ожидать. echo "Символы из \"$1\" преобразованы в верхний регистр, результат записан в \"$2\"." exit 0
Next: Redirecting errors to a file Up: I/O redirection Previous: Redirecting input from a file Contents Index
Redirecting output to a file
To redirect standard output to a file, use the `>' operator.
I/O redirection in Linux
Follow the command name with the > operator, followed by the name of the file that will serve as the destination for the output. For example, to write the output of a program to a file, enter:
If you redirect standard output to an already existing file, it will be overwritten from the beginning. To append standard output to the contents of an existing file, you must use the `"' operator. For example, to add the results of the work when running the program again to a file, enter:
Alex Otwagin 2002-12-16
A program is usually valuable because it can process data: accept one thing, produce another as output, and almost anything can act as data: text, numbers, sound, video... The input and output data streams for a command are called input And conclusion. Each program can have several input and output streams. Each process, when created, necessarily receives the so-called standard input(standard input, stdin) and standard output(standard output, stdout) and standard error output(standard error, stderr).
Standard input/output streams are intended primarily for exchanging text information. It doesn’t even matter who communicates via texts: a person with a program or programs between themselves - the main thing is that they have a data transmission channel and that they speak “the same language.”
The textual principle of working with a machine allows you to escape from specific parts of the computer, such as the system keyboard and video card with a monitor, looking at a single terminal device , through which the user enters text (commands) and transmits it to the system, and the system displays the data and messages required by the user (diagnostics and errors). Such a device is called terminal. In general, a terminal is a user's entry point into a system that has the ability to transmit text information. The terminal can be a separate external device, connected to a computer via a serial data port (in personal computer it is called "COM port"). A program (for example, xterm or ssh) can also work as a terminal (with some support from the system). Finally, virtual consoles - also terminals, only organized programmatically using suitable devices of a modern computer.
When working at the command line, the shell's standard input is associated with the keyboard, and standard output and error output are associated with the monitor screen (or terminal emulator window). Let's show with an example the simplest command-cat. Usually the team cat reads data from all files that are specified as its parameters and sends the read directly to standard output (stdout). Therefore the command
/home/larry/papers# cat history-final masters-thesis
will display the contents of the file first, and then the file.
However, if the file name is not specified, the program cat reads input from stdin and immediately returns it to stdout (without modifying it in any way). Data passes through cat like through a pipe. Let's give an example:
/home/larry/papers# cat Hello there. Hello there. Bye. Bye. Ctrl—D/home/larry/papers#
Every line entered from the keyboard is immediately returned to the screen by the cat program. When entering information from standard input, the end of the text is signaled by entering special combination keys, usually Ctrl—D.
Let's give another example. Team sort reads lines of input text (also from stdin if no file name is specified) and outputs a set of these lines in an ordered form on stdout. Let's check its action.
/home/larry/papers# sort bananas carrots apples Ctrl+D apples bananas carrots /home/larry/papers#
As you can see, after pressing Ctrl—D, sort Displayed the lines in alphabetical order.
Standard input and standard output
Let's say you want to pipe the output of the sort command to a file to store an alphabetically ordered list on disk. The command shell allows you to redirect the standard output of a command to a file using a symbol. Let's give an example:
/home/larry/papers# sort > shopping-list bananas carrots apples Ctrl—D/home/larry/papers#
You can see that the output of the sort command is not printed on the screen, but it is saved in a file named. Let's display the contents of this file:
/home/larry/papers# cat shopping-list apples bananas carrots /home/larry/papers#
Now let the original unordered list be in a file. This list can be sorted using the command sort, by telling it that it should read from a given file rather than from its standard input, and in addition redirecting the standard output to a file, as was done above. Example:
/home/larry/papers# sort items shopping-list /home/larry/papers# cat shopping-list apples bananas carrots /home/larry/papers#
However, you can do it differently by redirecting not only the standard output, but also standard input utilities from the file using the symbol:
/home/larry/papers# sort< items apples bananas carrots /home/larry/papers#
Command result sort< items equivalent to the command sort items, however the first one demonstrates the following: when issuing the command sort< items the system behaves as if the data contained in the file had been entered from standard input. Redirection is done by the command shell. Team sort the filename was not reported: this command read data from its standard input as if we had entered it from the keyboard.
Let's introduce the concept filter. A filter is a program that reads data from standard input, processes it in some way, and sends the result to standard output. When redirection is applied, files can be used as standard input and output. As stated above, by default, stdin and stdout refer to the keyboard and screen, respectively. The sort program is a simple filter - it sorts the input data and sends the result to standard output. A very simple filter is the program cat- it does nothing with the input data, but simply sends it to the output.
We've already demonstrated how to use the sort program as a filter above. These examples assumed that the source data was in some file or that the source data would be entered from the keyboard (standard input). However, what if you want to sort data that is the result of some other command, for example, ls?
We will sort the data in reverse alphabetical order; this is done by the command option sort. If you wanted to list the files in the current directory in reverse alphabetical order, one way to do it would be like this.
I/O redirection
Let's first use the command ls:
/home/larry/papers# ls english-list history-final masters-thesis notes /home/larry/papers#
Now we redirect the command output ls to a file named file-list
/home/larry/papers# ls > file-list /home/larry/papers# sort -r file-list notes masters-thesis history-final english-list /home/larry/papers#
Here is the command output ls saved in a file, and after that this file was processed by the command sort. However, this path is inelegant and requires the use of a temporary file to store the program output ls.
A solution to this situation could be to create docked commands(pipelines). The docking is carried out by the command shell, which directs the stdout of the first command to the stdin of the second command. In this case we want to send commands to stdout ls to stdin commands sort. A symbol is used for docking, as shown in the following example:
/home/larry/papers# ls | sort -r notes masters-thesis history-final english-list /home/larry/papers#
This command is shorter than a collection of commands and is easier to type.
Let's look at another useful example. Team
/home/larry/papers# ls /usr/bin
returns a long list of files. Most of this list flies across the screen too quickly for the contents of this list to be read. Let's try to use the more command to display this list in parts:
/home/larry/papers# ls /usr/bin | more
Now you can “turn through” this list.
You can go further and dock more than two teams. Consider the team head, which is a filter with the following property: it outputs the first lines from the input stream (in our case, the input will be the output from several concatenated commands). If we want to display the last alphabetical file name in the current directory, we can use the following long command:
/home/larry/papers# ls | sort -r | head -1 notes /home/larry/papers\#
where is the team head displays the first line of the input stream of lines it receives (in our case, the stream consists of data from the command ls), sorted in reverse alphabetical order.
Using stacked commands (pipeline)
The effect of using a symbol to redirect file output is destructive; in other words, the team
/home/larry/papers# ls > file-list
will destroy the contents of the file if the file previously existed and create a new file in its place.
If the redirection is done using symbols instead, the output will be appended to the end specified file, but the original contents of the file will not be destroyed. For example, the command
/home/larry/papers# ls >> file-list
attributes the output of the command ls to the end of the file.
Keep in mind that input and output redirection and command splicing are done by shells that support the use of symbols, and. The teams themselves are not able to perceive and interpret these symbols.
Non-destructive output redirection
Something like this should do what you need?
Check it out: wintee
No need for cygwin.
However, I have encountered and reported some issues.
Also you might want to check out http://unxutils.sourceforge.net/ because it contains tee (and doesn't need cygwin), but be careful that EOL output is UNIX-like.
Last but not least, if you have PowerShell, you can try Tee-Object. Type in PowerShell console for more information.
This works, although it's a little ugly:
It's a little more flexible than some other solutions in that it works in its own way so you can use it to add.
I use this quite a lot in batch files to log and display messages:
Yes, you could simply repeat the ECHO statement (once for the screen and a second time redirecting to the log file), but that looks just as bad and is a maintenance issue.
Redirecting input and output
At least this way you don't have to make changes to messages in two places.
Note that _ is just a short filename, so you'll need to remove it at the end of your batch file (if you're using batch file).
This will create a log file with the current time and time and you can use the console lines during the process
If you have cygwin in your path Windows environment, you can use:
A simple C# console application would do the trick:
To use this, you simply pass the source command to the program and specify the path to any files for which you want to duplicate the output. For example:
Will display search results and also save the results in files1.txt and files2.txt.
Note that there is not much in the way of error handling (nothing!) and support for multiple files may not be necessary.
I was also looking for the same solution, after a little try I was able to successfully do this on the command line. Here's my solution:
It even hijacks any PAUSE command.
An alternative is to tee stdout to stderr in your program:
Then in your dos batchfile:
Stdout will go to the log file and stderr (same data) will be shown on the console.
How to display and redirect output to a file. Suppose if I use the command dos, dir> test.txt, this command redirects the output to the file test.txt without displaying the results. how to write a command to print the output and redirect the output to a file using DOS i.e. command Windows strings, not UNIX/LINUX.
You may find these commands in biterscripting (http://www.biterscripting.com) useful.
This is a variation of MTS's previous answer, however it adds some features that may be useful to others. Here is the method I used:
- The command is set as a variable that can be used later in the code to be output to the command window and added to the log file using
- the command avoids redirection using the carrot symbol so that commands are not evaluated initially
- A temporary file is created with a file name similar to a batch file name that uses command line option extension syntax to obtain the name of the batch file.
- The result is added to separate file magazine
Here is the sequence of commands:
- Output and error messages are sent to a temporary file
- The contents of the temporary file are then:
- added to log file
- output to command window
- The temporary file with the message is deleted
Here's an example:
This way the command can simply be added after later commands in a batch file, which looks much cleaner:
This can be added at the end of other commands as well. As far as I can tell this will work when messages have multiple lines. For example, the following command prints two lines if there is an error message:
I agree with Brian Rasmussen, the unxutils port is the easiest way to do this. In the Batch Files section of his Scripting pages, Rob van der Woude provides a wealth of information about using MS-DOS and CMD commands. I thought it might have its own solution to your problem, and after TEE.BAT digging around there, I found TEE.BAT, which appears to be just that, a packaged MS-DOS language pack. This is a fairly complex batch file and I would be inclined to use the unxutils port.
I install perl on most of my machines, so the answer is using perl: tee.pl
dir | perl tee.pl or catalog | perl tee.pl dir.bat
raw and untested.
Very often, when working in a terminal, there is a need to save the result of commands (or some console application) in text file or more simply put log. There are many ways to implement this idea in Linux and in this article we will look at some of them.
Standard output stream ( StdOut) - This is all the information that is output as a result of the command execution, excluding errors.
Standard error output ( StdErr) - This is information about the error, if there was one.
command > logfile.txt
The standard output stream (StdOut) will be redirected to a file and will not be displayed in the terminal. If the file already exists, it will be overwritten.
Command >> logfile.txt
The standard output stream (StdOut) will be redirected to a file and will not be displayed in the terminal. If the file already exists, then the new data will be added to the end of the file.
Command 2>logfile.txt
The standard error output stream (StdErr) will be redirected to a file and will not be displayed in the terminal. If the file already exists, it will be overwritten.
Command 2 >> logfile.txt
The standard error output stream (StdErr) will be redirected to a file and will not be displayed in the terminal. If the file already exists, then the new data will be added to the end of the file.
Command &> logfile.txt
Standard Output (StdOut) and Standard Error Output (StdErr) will be redirected to a file and will not be displayed in the terminal. If the file already exists, it will be overwritten.
Command &>> logfile.txt
Standard Output (StdOut) and Standard Error Output (StdErr) will be redirected to a file and will not be displayed in the terminal. If the file already exists, then the new data will be added to the end of the file.
Team | tee logfile.txt
The standard output stream (StdOut) will be redirected to a file and simultaneously displayed in the terminal. If the file already exists, it will be overwritten.
Team | tee -a logfile.txt
The standard output stream (StdOut) will be redirected to a file and simultaneously displayed in the terminal. If the file already exists, then the new data will be added to the end of the file.
Examples
uname -r > logfile.txtThe output will be saved to logfile.txt in the current directory. Nothing will be displayed on the screen.
Uname -r | tee logfile.txt
The output will be saved to logfile.txt in the current directory. And also the result will be displayed on the screen.