중첩된 구분 기호의 이상한 동작

중첩된 구분 기호의 이상한 동작

중복이라면 죄송합니다. 그러나 여기서는 비슷한 질문을 찾을 수 없습니다. 나는이 이상한 행동을 우연히 발견했습니다. 이 논리를 설명할 수 있는 사람이 있나요? 왜 "ABC"로 확인되나요?

$ cat repro.sh
bash -s <<-EOS1
        bash -s <<EOS2 &
        #ABC
        EOS2
echo "" | wc
#1234567
EOS1

$ . ./repro.sh
      1       0       1
bash: line 5: ABC: command not found
bash: line 6: EOS2: command not found
      1       0       1

답변1

이것은 bash의 버그입니다. 다음 주소로 버그 보고서를 제출해야 합니다.[이메일 보호됨].

더 멋진 예 - 보시다시피 "stdin의 스크립트", "검색 가능한 파일로서의 stdin" 및 "백그라운드 명령의 heredoc"이 조합되어 있으므로 중첩된 heredoc는 충분하지 않거나 필요하지 않습니다.

$ cat a.sh
true <<EOF &
#ABC
EOF
seq 1 3
true | true
#1234567
$ bash <a.sh
1
2
3
bash: line 5: rue: command not found
1
2
3
bash: line 9: rue: command not found
1
...
<same nonsense repeated hundred of times with increasing line numbers>

bash 외부에서 cat "쓸데없이"를 사용하면 이 문제를 해결할 수 있습니다(사이트에서 탭이 깨지기 때문에 탭은 예제에서 생략되었습니다).

cat <<-EOS1 | bash -s

bash -s <<EOS2 &
#ABC
EOS2

echo "" | wc
#1234567
EOS1

스크립트는 파이프에서 읽기 때문에 bash는 입력에서 앞뒤로 살펴보며 모서리를 자르려고 하는 대신 바이트 단위(바이트당 시스템 호출)로 읽도록 설득할 수 있습니다. ;-)

관련 정보