사용자 입력을 안전하게 받기: Bash read 명령어의 필수 기술

Bash read 명령어는 수집한 값이 파일 경로, 명령어 인수 또는 비밀번호 프롬프트에 사용될 때까지는 무해해 보입니다. 대부분의 문제는 read 자체에서 발생하지 않습니다. 텍스트를 너무 일찍 신뢰하거나, 공백과 셸 메타문자가 일반적인 사용자 입력이라는 것을 잊거나, 아무도 프롬프트에 응답하지 않아 스크립트가 영원히 멈추도록 내버려 두는 데서 발생합니다.

좋은 대화형 Bash 스크립트는 입력을 신뢰할 수 없는 텍스트로 취급합니다. 명확하게 묻고, 주의 깊게 읽고, 실행하기 전에 검증하고, 비밀을 로그에서 숨깁니다. 공식적으로 들리지만, 일상적인 버전은 간단합니다: 변수를 인용하고, 기본적으로 IFS= read -r을 사용하고, 반환 상태를 확인하고, 처리 방법을 모르는 값은 거부합니다.

가장 안전한 기본값으로 시작하기

대부분의 한 줄 프롬프트의 경우, 제가 사용하는 패턴은 다음과 같습니다:

printf '프로젝트 이름: '
IFS= read -r project_name

if [[ -z $project_name ]]; then
  printf '프로젝트 이름이 필요합니다.\n' >&2
  exit 1
fi

기억해야 할 두 가지 세부 사항이 있습니다. IFS=는 Bash가 읽는 동안 앞뒤 공백을 자르는 것을 방지합니다. -r은 read가 백슬래시를 이스케이프 문자로 처리하지 않도록 지시합니다. -r이 없으면, C:\Users\me 또는 \n을 포함하는 문자열을 입력하는 사람이 입력한 정확한 텍스트를 돌려받지 못할 수 있습니다.

프롬프트에 -p를 사용할 수도 있습니다:

IFS= read -r -p '환경 [dev/staging/prod]: ' env_name

대화형 터미널에서는 괜찮습니다. 저는 프롬프트와 읽기를 별도로 테스트하기 더 쉽게 하거나, 출력 형식에 대해 더 엄격한 이식성 습관이 필요할 때 여전히 printf를 사용합니다.

read가 실제로 성공했는지 확인하기

read는 상태를 반환합니다. 그것을 사용하세요. 읽기 실패는 파일 끝, 타임아웃 또는 중단된 터미널을 의미할 수 있습니다. 스크립트의 다음 줄이 변수가 의미 있다고 가정하면, 실수로 이전 값이나 빈 문자열로 실행될 수 있습니다.

if ! IFS= read -r -p '배포 태그: ' tag; then
  printf '입력을 받지 못했습니다. 중단합니다.\n' >&2
  exit 1
fi

이것은 사람이 실행하기도 하고 CI에서 실행되기도 하는 스크립트에서 중요합니다. 비대화형 작업에서는 read가 즉시 EOF에 도달할 수 있습니다. 빈 태그로 배포 명령이 실행되는 것보다 명확한 오류가 훨씬 낫습니다.

영원히 차단되어서는 안 되는 프롬프트에 타임아웃 사용하기

확인을 기다리는 유지 관리 스크립트는 조용히 배포나 cron 작업을 보류할 수 있습니다. read -t는 초 단위로 타임아웃을 설정합니다:

if IFS= read -r -t 15 -p '지금 서비스를 다시 시작하시겠습니까? [y/N] ' answer; then
  case $answer in
    y|Y|yes|YES) systemctl restart myapp ;;
    *) printf '재시작을 건너뛰었습니다.\n' ;;
  esac
else
  printf '\n15초 후 응답 없음; 재시작 건너뜀.\n' >&2
fi

타임아웃 지원은 Bash 기능이며 POSIX sh 기능이 아닙니다. Bash 기사에서는 일반적으로 괜찮지만, 작은 기본 이미지에서 /bin/sh로 스크립트가 실행될 수 있다면 기억할 가치가 있습니다.

비밀번호 숨기기, 하지만 영원히 보호된다고 가장하지 않기

read -s는 입력된 문자가 터미널에 표시되는 것을 방지합니다:

IFS= read -r -s -p '비밀번호: ' password
printf '\n'
IFS= read -r -s -p '비밀번호 확인: ' confirm_password
printf '\n'

if [[ $password != "$confirm_password" ]]; then
  printf '비밀번호가 일치하지 않습니다.\n' >&2
  exit 1
fi

이것은 어깨 너머로 보는 것과 터미널 스크롤백으로부터 보호합니다. Bash를 안전한 비밀 관리자로 바꾸지는 않습니다. 값은 스크립트가 실행되는 동안 여전히 셸 변수에 존재합니다. set -x가 활성화된 상태에서 출력하지 말고, 프로세스 목록에 나타나는 명령줄을 통해 전달하지 말고, 임시 파일에 쓰지 마십시오. 비밀이 심각한 프로덕션 워크플로우를 위한 것이라면, 비밀 저장소, 엄격한 권한이 있는 토큰 파일, 또는 대상 도구의 기본 비밀번호 프롬프트를 선호하십시오.

한 가지 실용적인 규칙: 주변 스크립트가 추적을 사용하는 경우 비밀 처리 주변에서 xtrace를 비활성화하십시오.

set +x
IFS= read -r -s -p 'API 토큰: ' api_token
printf '\n'
set -x

더 나은 방법은 토큰이 명령에서 더 이상 참조되지 않을 때까지 xtrace를 다시 켜지 않는 것입니다.

허용 목록으로 검증하고, 소망적인 이스케이프로 검증하지 않기

입력 검증은 작업과 일치해야 합니다. 브랜치 이름, 사용자 이름, 포트 번호 및 자유 형식 설명은 다른 종류의 텍스트입니다. 하나의 모호한 함수로 모든 것을 정화하지 마십시오.

간단한 배포 환경의 경우, 알려진 값만 허용하십시오:

IFS= read -r -p '환경 [dev/staging/prod]: ' env_name

case $env_name in
  dev|staging|prod) ;;
  *)
    printf '잘못된 환경: %s\n' "$env_name" >&2
    exit 1
    ;;
esac

TCP 포트의 경우, 형태와 범위를 모두 확인하십시오:

IFS= read -r -p '포트: ' port

if ! [[ $port =~ ^[0-9]+$ ]] || (( port < 1 || port > 65535 )); then
  printf '1에서 65535 사이의 포트를 입력하세요.\n' >&2
  exit 1
fi

로컬 파일 이름의 경우, 실제로 허용하는 것을 결정하십시오. 스크립트가 현재 디렉토리의 일반 파일 이름만 지원하는 경우, 그렇게 말하고 슬래시를 거부하십시오:

IFS= read -r -p '출력 파일 이름: ' filename

if ! [[ $filename =~ ^[A-Za-z0-9._-]+$ ]]; then
  printf '문자, 숫자, 점, 밑줄 및 대시만 사용하세요.\n' >&2
  exit 1
fi

printf '%s에 쓰는 중\n' "$filename"

명령 문자열을 만든 다음 eval로 실행하는 패턴을 피하십시오. printf %q는 셸 이스케이프된 표현을 표시할 수 있지만, 신뢰할 수 없는 명령을 조립할 수 있는 권한은 아닙니다. 셸이 각 인수를 분리하여 유지하도록 배열을 선호하십시오:

cmd=(tar -czf "$filename.tar.gz" "$filename")
"${cmd[@]}"

분할이 의도적인 경우에만 여러 값 읽기

read first last는 IFS에서 분할합니다. 사용자가 변수보다 더 많은 단어를 입력하면 마지막 변수가 나머지를 받습니다. 이것은 이름에 유용할 수 있지만, 당신을 놀라게 할 수도 있습니다.

IFS= read -r -p '이름과 성: ' first_name last_name

입력이 Mary Jane Watson인 경우, first_name은 Mary가 되고 last_name은 Jane Watson이 됩니다. 전체 줄이 필요하면 하나의 변수로 읽으십시오. 구조화된 입력이 필요하면 구분자를 선택하고 의도적으로 구문 분석하십시오.

콜론으로 구분된 값의 경우:

IFS=: read -r host port <<<"$target"

그런 다음 두 필드를 모두 검증하십시오. 구분자가 나타났다고 가정하지 마십시오.

실수를 숨기지 않고 기본값 처리하기

기본값은 표시될 때 유용합니다:

IFS= read -r -p '로그 수준 [INFO]: ' log_level
log_level=${log_level:-INFO}

파괴적인 작업의 경우, 위험한 작업을 수행하는 기본값을 피하십시오. 데이터를 삭제하시겠습니까? [y/N]와 같은 프롬프트는 Enter를 '아니요'로 처리해야 하며 '예'로 처리하지 않아야 합니다.

IFS= read -r -p '로컬 캐시를 삭제하시겠습니까? [y/N] ' answer
case $answer in
  y|Y|yes|YES) rm -rf -- "$cache_dir" ;;
  *) printf '캐시를 그대로 둡니다.\n' ;;
esac

경로 앞의 --에 주목하십시오. 이것은 -로 시작하는 파일 이름이 rm에 의해 옵션으로 해석되는 것을 방지합니다.

파이프라인과 스크립트에서 프롬프트 작동하게 만들기

스크립트가 표준 입력에서 데이터를 읽는 경우, 대화형 프롬프트가 터미널에서 읽는 대신 실수로 파이프된 데이터를 소비할 수 있습니다. 이 경우, /dev/tty에서 프롬프트를 읽으십시오:

printf '계속하시겠습니까? [y/N] ' > /dev/tty
IFS= read -r answer < /dev/tty

이 패턴은 다음과 같은 도구에 유용합니다:

generate-list | ./review-and-delete.sh

스크립트는 제어 터미널에서 운영자에게 확인을 요청하면서 stdin에서 파이프된 레코드를 처리할 수 있습니다.

작은 재사용 가능한 프롬프트 함수

여러 프롬프트가 있는 스크립트의 경우, 작은 도우미가 동작을 일관되게 유지합니다:

prompt_required() {
  local label=$1 value

  while true; do
    IFS= read -r -p "$label: " value || return 1
    if [[ -n $value ]]; then
      printf '%s\n' "$value"
      return 0
    fi
    printf '%s이(가) 필요합니다.\n' "$label" >&2
  done
}

project_name=$(prompt_required '프로젝트 이름') || exit 1

함수는 허용된 값을 stdout에 출력하므로 호출자가 캡처할 수 있습니다. 오류는 stderr로 이동합니다. 이것은 프롬프트와 결과를 혼합하지 않고 명령 대체에서 사용할 수 있게 합니다.

짧은 버전: 텍스트를 데이터로 유지하는 한 read는 충분히 안전합니다. IFS= read -r을 사용하고, 실패를 확인하고, 현실적인 기대로 비밀을 숨기고, 정확히 수행하려는 작업에 대해 검증하고, 값을 인용된 인수 또는 배열 요소로 전달하십시오. 이러한 습관이 자동화되면 대부분의 입력 관련 Bash 버그가 사라집니다.

너무 많이 받아들이는 예/아니오 프롬프트 피하기

확인 프롬프트는 지루하고 엄격해야 합니다. 비어 있지 않은 답변을 승인으로 취급하지 마십시오. 스크립트에서 이 패턴을 사용하는 것을 본 적이 있습니다:

read -r -p '계속하시겠습니까? ' answer
if [[ $answer ]]; then
  deploy_to_production
fi

이는 no, wait 및 이것은 무엇을 합니까? 모두 예로 간주된다는 것을 의미합니다. case 문을 사용하고 기본값을 안전하게 만드십시오:

IFS= read -r -p '프로덕션에 배포하시겠습니까? 계속하려면 yes를 입력하세요: ' answer
case $answer in
  yes) deploy_to_production ;;
  *)
    printf '배포가 취소되었습니다.\n' >&2
    exit 1
    ;;
esac

특히 위험한 작업의 경우, 예/아니오 프롬프트보다 정확한 리소스 이름을 요구하는 것이 더 좋습니다:

printf '이 네임스페이스를 삭제하려면 %s을(를) 입력하세요: ' "$namespace"
IFS= read -r confirmation

if [[ $confirmation != "$namespace" ]]; then
  printf '이름이 일치하지 않습니다. 삭제된 것이 없습니다.\n' >&2
  exit 1
fi

이것은 읽지 않은 프롬프트에서 Enter를 누르는 사람을 보호합니다.

터미널 전용 옵션에 주의하기

일부 read 옵션은 터미널을 가정합니다. 자동 입력, 프롬프트 및 타임아웃은 대화형 사용을 위해 설계되었습니다. 스크립트가 CI, Docker 진입점 또는 cron에서 실행될 수 있는 경우, stdin이 터미널인지 확인하십시오:

if [[ -t 0 ]]; then
  IFS= read -r -p '릴리스 이름: ' release_name
else
  release_name=${RELEASE_NAME:?비대화형 모드에서는 RELEASE_NAME이 필요합니다}
fi

이것은 인간에게 프롬프트를 제공하고 자동화에 명확한 환경 변수 계약을 제공합니다. 또한 플랫폼이 빌드 작업을 죽일 때까지 빌드 작업이 중단되는 것을 방지합니다.

파서가 있을 때 구조화된 형식에 read를 사용하지 않기

사람에게서 간단한 값을 읽는 것은 괜찮습니다. 형식이 진정으로 간단하지 않는 한, JSON, YAML, CSV 또는 셸 구문을 간단한 read 루프로 구문 분석하는 것은 덜 괜찮습니다. CSV 필드 내의 쉼표나 JSON 내의 따옴표는 수동 구문 분석을 빠르게 깨뜨릴 수 있습니다.

JSON의 경우 jq를 사용하십시오. .env 파일의 경우, 의도적으로 작은 형식을 선택하고 문서화하십시오. 줄 기반 구성을 읽는 경우, 줄을 보존하고 명시적으로 주석을 건너뛰십시오:

while IFS= read -r line; do
  [[ -z $line || $line == \#* ]] && continue
  printf '구성 줄: %s\n' "$line"
done < settings.conf

이 루프는 모든 구성 형식을 마술처럼 구문 분석하지 않습니다. 단지 줄을 충실히 읽을 뿐이며, 이것이 올바른 시작점입니다.

출시 전 실제 리뷰 패스

스크립트나 컨테이너 설정을 완료했다고 부르기 전에, 다음 사람이 오전 2시에 디버깅해야 하는 사람인 것처럼 한 번 읽으십시오. 그러면 눈에 띄는 것이 달라집니다. 스크립트를 작성하는 동안 이해가 되었던 프롬프트가 CI 로그에 나타날 때는 모호할 수 있습니다. 명백해 보였던 Docker 서비스 이름이 애플리케이션의 변수 이름과 일치하지 않을 수 있습니다. 개발에는 안전했던 Bash 기본값이 프로덕션에는 위험할 수 있습니다.

의도적으로 어색한 값으로 짧은 드라이 런을 하는 것을 좋아합니다. 공백이 있는 경로를 사용하십시오. 빈 선택적 값을 사용하십시오. 대시로 시작하는 파일 이름을 시도하십시오. 다른 작업 디렉토리에서 스크립트를 실행하십시오. 하나의 예상 환경 변수 없이 컨테이너를 시작하십시오. 이러한 테스트는 화려하지 않지만, 일반적으로 먼저 깨지는 가정을 잡아냅니다.

또한 실패 메시지를 확인하십시오. 유일한 출력이 실패인 경우, 기사의 조언이 구현에 반영되지 않은 것입니다. 유용한 실패는 어떤 값이 사용되었는지, 어떤 검사가 실패했는지, 운영자가 무엇을 변경할 수 있는지 알려줍니다. 이것은 모든 환경 변수를 덤프하거나 비밀을 인쇄하는 것을 의미하지 않습니다. 특정성이 도움이 되는 곳에서 구체적이어야 함을 의미합니다: 구성 경로, 누락된 명령 이름, 네트워크 이름, 서비스 호스트 이름 또는 프로세스가 바인딩하려고 시도한 포트.

마지막 습관은 예제를 시스템이 실제로 실행되는 방식에 가깝게 유지하는 것입니다. 프로덕션이 Compose를 사용하는 경우 Compose로 테스트하십시오. 스크립트가 systemd에 의해 실행되는 경우 systemd 또는 유사하게 최소한의 환경으로 테스트하십시오. 명령이 복사하여 붙여넣기에 안전해야 하는 경우 예제 자체에 인용, -- 구분 기호 및 검증을 포함하십시오. 독자는 경고보다 작업 패턴을 더 자주 복사합니다.

그 리뷰 패스는 관료주의가 아닙니다. 작은 자동화를 지루하게 유지하는 방법입니다. 지루함은 셸 프롬프트, 구성 로더, 변수 확장, 컨테이너 진단 및 Docker 네트워킹에서 원하는 것입니다. 동작이 덜 놀라울수록 다음 운영자가 신뢰하기가 더 쉽습니다.