Quick Syntax

command > out.txt
command >> out.txt
command 2> error.txt
command > out.txt 2>&1
set -o pipefail # Bash, zsh 등에서 pipeline 중간 실패도 실패로 처리
cat app.log | grep "ERROR" | less
echo $?

입출력 흐름

Linux 프로세스는 기본적으로 stdin, stdout, stderr 세 흐름을 가집니다. stdout은 정상 출력, stderr는 오류 출력입니다. >는 stdout만 바꾸므로 오류 메시지는 터미널에 그대로 보일 수 있습니다. 오류까지 파일로 남겨야 하면 2> 또는 2>&1을 함께 써야 합니다.

node server.js > app.log 2> app.err
node server.js > app.log 2>&1

redirection은 왼쪽에서 오른쪽 순서로 적용됩니다. command > out.txt 2>&1은 stdout을 파일로 바꾼 뒤 stderr도 그 stdout으로 복제하지만, command 2>&1 > out.txt는 먼저 stderr를 기존 stdout(보통 터미널)으로 보냅니다. 결과가 한 파일에 모여야 한다면 순서를 바꾸지 않습니다.

pipe는 앞 명령의 stdout을 뒤 명령의 stdin으로 넘깁니다. 로그에서 특정 문자열만 보고, 그 결과를 다시 정렬하거나 페이지 단위로 읽는 식으로 작은 도구를 연결할 수 있습니다.

grep "ERROR" app.log | sort | uniq -c | sort -nr

Bash의 기본 pipeline exit status는 마지막 명령의 결과입니다. 앞의 grep이 실패해도 마지막 sort가 성공하면 pipeline 전체가 성공처럼 보일 수 있습니다. Bash·zsh 등에서 중간 실패도 실패로 처리하려면 script 초반에 set -o pipefail을 켜고, 개별 결과가 필요하면 Bash의 PIPESTATUS를 봅니다. pipefail은 POSIX shell 공통 기능이 아니므로 script의 실행 shell을 명시합니다.

exit status는 명령 성공 여부를 숫자로 남긴다

일반적으로 exit status 0은 성공이고, 0이 아닌 값은 실패입니다. 셸 스크립트와 CI는 이 값을 기준으로 다음 단계를 계속할지 중단할지 결정합니다. 명령이 출력은 했지만 실패했을 수도 있고, 출력이 없어도 성공했을 수 있으므로 stdout만 보고 성공을 판단하지 않는 편이 안전합니다.

grep "READY" app.log
echo $?

변수 확장과 command substitution 뒤에는 word splitting과 glob expansion이 명령 실행 전에 일어날 수 있습니다. 공백이나 *가 들어갈 수 있는 변수는 "$file"처럼 인용하고, 파일명이 option처럼 시작할 수 있는 명령에는 -- 뒤에 둡니다.

grep -F -- "$pattern" "$file"
rm -- "$file"

체크포인트

주의할 점

# 기존 app.log를 덮어씀
command > app.log

# 기존 app.log 뒤에 추가
command >> app.log