Data is entered into the computer via stdin (usually the keyboard), and the resulting output goes to stdout (usually the shell). These pathways are called streams. However, it's possible to alter these input and output locations, causing the computer to get information from somewhere other than stdin or send the results somewhere other than stdout. This functionality is referred to as redirection.
In this article, you'll learn five redirect operators, including one for stderr. I've provided examples of each and presented the material in a way that you can duplicate on your own Linux system.
Regular output > operator
The output redirector is probably the most recognized of the operators. The standard output (stdout) is usually to the terminal window. For example, when you type the date
command, the resulting time and date output is displayed on the screen.
[damon@localhost ~]$ date
Tue Dec 29 04:07:37 PM MST 2020
[damon@localhost ~]$
It is possible, however, to redirect this output from stdout to somewhere else. In this case, I'm going to redirect the results to a file named specifications.txt
. I'll confirm it worked by using the cat
command to view the file contents.
[damon@localhost ~]$ date > specifications.txt
[damon@localhost ~]$ cat specifications.txt
Tue Dec 29 04:08:44 PM MST 2020
[damon@localhost ~]$
The problem with the >
redirector is that it overwrites any existing data in the file. At this stage, you now have date
information in the specifications.txt
file, right? If you type hostname > specifications.txt
, the output will be sent to the text file, but it will overwrite the existing time and date information from the earlier steps.
[damon@localhost ~]$ hostname > specifications.txt
[damon@localhost ~]$ cat specifications.txt
localhost.localdomain
[damon@localhost ~]$
It is easy to get in trouble with the >
redirector by accidentally overwriting existing information.
[ Readers also enjoyed: 10 basic Linux commands you need to know ]
Regular output append >> operator
The append >>
operator adds the output to the existing content instead of overwriting it. This allows you to redirect the output from multiple commands to a single file. For example, I could redirect the output of date
by using the >
operator and then redirect hostname
and uname -r
to the specifications.txt
file by using >>
operator.
[damon@localhost ~]$ date > specifications.txt
[damon@localhost ~]$ hostname >> specifications.txt
[damon@localhost ~]$ uname -r >> specifications.txt
[damon@localhost ~]$ cat specifications.txt
Tue Dec 29 04:11:51 PM MST 2020
localhost.localdomain
5.9.16-200.fc33.x86_64
[damon@localhost ~]$
Note: The >>
redirector even works on an empty file. That means that you could conceivably
ignore the regular >
redirector to alleviate the potential to overwrite data, and always rely on the >>
redirector instead. It's not a bad habit to get into.
Regular input < operator
The input redirector pulls data in a stream from a given source. Usually, programs receive their input from the keyboard. However, data can be pulled in from another source, such as a file.
It's time to build an example by using the sort
command. First, create a text file named mylist.txt
that contains the following lines:
cat
dog
horse
cow
Observe that the animals are not listed in alphabetical order.
What if you need to list them in order? You can pull the contents of the file into the sort
command by using the <
operator.
[damon@localhost ~]$ sort < mylist.txt
cat
cow
dog
horse
[damon@localhost ~]$
You could even get a little fancier and redirect the sorted results to a new file:
[damon@localhost ~]$ sort < mylist.txt > alphabetical-file.txt
[damon@localhost ~]$ cat alphabetical-file.txt
cat
cow
dog
horse
[damon@localhost ~]$
Regular error 2> operator
The stdout displays expected results. If errors appear, they are managed differently. Errors are labeled as file descriptor 2 (standard output is file descriptor 1). When a program or script does not generate the expected results, it throws an error. The error is usually sent to the stdout, but it can be redirected elsewhere. The stderr operator is 2>
(for file descriptor 2).
Here is a simple example, using the misspelled ping
command:
[damon@localhost ~]$ png
bash: png: command not found...
[damon@localhost ~]$
Here is the same misspelled command with the error output redirected to /dev/null
:
[damon@localhost ~]$ png 2> /dev/null
[damon@localhost ~]$
The resulting error message is redirected to /dev/null
instead of the stdout, so no result or error message is displayed on the screen.
Note: /dev/null
, or the bit bucket, is used as a garbage can for the command line. Unwanted output can be redirected to this location to simply make it disappear. For example, perhaps you're writing a script, and you want to test some of its functionality, but you know it will throw errors that you don't care about at this stage of development. You can run the script and tell it to redirect errors to /dev/null
for convenience.
Pipe | operator
Ken Hess already has a solid article on using the pipe |
operator, so I'm only going to show a very quick demonstration here.
The pipe takes the output of the first command and makes it the input of the second command. You might want to see a list of all directories and files in the /etc
directory. You know that's going to be a long list and that most of the output will scroll off the top of the screen. The less
command will break the output into pages, and you can then scroll upward or downward through the pages to display the results. The syntax is to issue the ls
command to list the contents of /etc
, and then use pipe to send that list into less
so that it can be broken into pages.
[damon@localhost ~]$ ls /etc | less
Ken's article has many more great examples. Personally, I find myself using command | less
and command | grep string
the most often.
[ Download now: A sysadmin's guide to Bash scripting. ]
Wrap up
Redirect operators are very handy, and I hope this brief summary has provided you with some tricks for manipulating input and output. The key is to remember that the >
operator will overwrite existing data.
저자 소개
Damon Garn owns Cogspinner Coaction, LLC, a technical writing, editing, and IT project company based in Colorado Springs, CO. Damon authored many CompTIA Official Instructor and Student Guides (Linux+, Cloud+, Cloud Essentials+, Server+) and developed a broad library of interactive, scored labs. He regularly contributes to Enable Sysadmin, SearchNetworking, and CompTIA article repositories. Damon has 20 years of experience as a technical trainer covering Linux, Windows Server, and security content. He is a former sysadmin for US Figure Skating. He lives in Colorado Springs with his family and is a writer, musician, and amateur genealogist.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.