tr "\n" "\n"`을 통해 파이핑할 때 `ls`의 출력이 다르게 보이는 이유는 무엇입니까?

tr "\n" "\n"`을 통해 파이핑할 때 `ls`의 출력이 다르게 보이는 이유는 무엇입니까?

매뉴얼 페이지에는 다음과 tr(1)같이 나와 있습니다.

       tr - translate or delete characters

SYNOPSIS
       tr [OPTION]... SET1 [SET2]

DESCRIPTION
       Translate, squeeze, and/or delete characters from standard input, writing to standard output.

내가 아는 한, 이는 "\n"을 취하고 "\n"으로 대체한다는 의미입니다(즉, 아무것도 변경되지 않음을 의미함).

그러나 이것이 왜 ls | tr '\n' '\n'다음과 같은 효과를 가져오는지는 설명하지 않습니다.

 $ ls 
 Documents   Downloads   Git   Music   Pictures  '#recycle'   Videos
2019-Dec-24 07:28:44 PM modernNeo:modernNeo-debian/home/modernNeo
 $ ls | tr "\n" "\n"
Documents
Downloads
Git
Music
Pictures
#recycle
Videos

답변1

이 유틸리티의 출력은 ls출력이 터미널에 직접 기록되는지 아니면 파이프에 기록되는지에 따라 달라질 수 있습니다.

tr '\n' \n'다음 명령을 사용하면 동일한 동작이 발생합니다 cat.

$ ls
file-00 file-01 file-02 file-03 file-04 file-05 file-06 file-07 file-08 file-09
$ ls | cat
file-00
file-01
file-02
file-03
file-04
file-05
file-06
file-07
file-08
file-09

ls이 줄은 한 줄에 하나의 파일을 나열하며 아래에 설명된 기본 출력입니다.이 유틸리티의 POSIX 표준:

기본 형식은 표준 출력에 한 줄에 하나의 항목을 나열해야 합니다.; 단말기 또는 옵션 중 하나를 지정 -C하는 -m경우는 제외합니다 . -x터미널로 출력하는 경우 형식은 구현에 따라 정의됩니다.

#recycle또한 파이프를 통해 출력을 필터링할 때 파일 이름 주위의 작은따옴표가 "사라지는" 것을 알 수 있습니다 . 실제로 이것은 파일 이름의 일부가 아니었지만 lsGNU가 터미널에 출력할 때 이름을 렌더링하기로 결정한 방식이었습니다(이름에 포함된 문자를 기반으로 하며 #"특수"로 간주됨). 출력이 터미널에 도달하면 작은따옴표로 묶인 이름과 열의 출력은 표준에서 허용하는 "구현 정의 형식"입니다.

파일로 리디렉션하여 파이프를 바꾸면(또는 이를 지원하는 셸에서 프로세스 대체) ls출력 형식이 "기본 형식"으로 지정되며 각 파일 이름은 개행으로 구분됩니다.

관련 정보