/usr/share/fonts일부 글꼴 파일을 AWS(Amazon Linux 실행)에 업로드하고 .ebextensions 의 명령을 사용하여 해당 디렉터리로 이동했습니다 cp.
Mac에서 SSH를 사용하여 사용할 때 ls -a일부 파일의 색상이 다르게 표시됩니다. 글꼴 파일 중 한 세트는 검은색이고 다른 파일은 녹색입니다. 원인이 무엇인지 궁금합니다.내 코드에 문제가 발생할 경우.
~에서AskUbuntu에 대한 또 다른 답변이 색상을 어떻게 해석할지에 대한 열쇠를 찾았습니다..ttfs가 실행 가능한 이유나 .ttfs 세트 중 한 세트는 인식되지만 다른 세트는 인식되지 않는 이유를 이해할 수 없습니다.
파란색: 디렉토리
녹색: 실행 가능하거나 인식된 데이터 파일
하늘색: 링크된 파일
노란색과 검정색 배경: 장비
분홍색: 그래픽 이미지 파일
빨간색: 보관된 파일
이러한 파일은 업로드되기 전에 다양한 글꼴 웹사이트에서 Mac으로 다운로드되었습니다.
답변1
ls -l파일이 실행 가능한지 명시적으로 알려줍니다. 여기에는 큰 비밀은 없는 것 같아요. 다양한 소스에서 파일을 다운로드했는데, 각 소스에는 어떤 이유로든 서로 다른 권한 비트가 설정되어 있을 수 있습니다. * 일부 색상이 마음에 들지 않고 일부는 시도하지 않는 경우 chmod -x *.ttf... 글꼴 파일에는 실행 비트를 설정할 필요가 없습니다.
* Matteo Italia의 찬성 의견(남아야 함)은 다음과 같이 말합니다.실행 가능한 비트를 저장하지 않는 FAT 또는 NTFS 볼륨에서 복사되었을 가능성이 높으므로모든 파일에 실행 비트가 설정되도록 기본적으로 설치됩니다..
답변2
ls실행 중인 명령이 별칭인 것 같습니다.ls --color
--color[=WHEN] 출력 색상은 "always"(생략된 경우 기본값), "auto" 또는 "never"일 수 있습니다.
Origin 을 실행하여 확인할 수 있습니다 ls:
따옴표 사용:
"ls"-a
전체 경로(예:
ls위치가/bin/ls)를 사용하고 색상이 표시되는지 확인합니다./bin/ls -a
참고: 실행하면 ls -la파일 세부 정보가 표시되고 각 파일의 전체 세부 정보를 볼 수 있습니다. 이를 통해 예상 출력을 확인할 수 있습니다.ls --color
답변3
색상은 파일이 "실행 가능"으로 표시되었음을 나타냅니다.*
실행 권한 비트(사용자용, 그룹용, 기타용)는 파일 이름이 exec 시스템 호출 중 하나로 전달되면 커널이 계속해서 해당 파일을 실행하려고 시도한다는 의미입니다.
실제로 실행되도록 의도된 파일에만 실행 가능 비트가 설정되어 있다는 것이 관례입니다. 그러나 특히 다중 플랫폼 환경에서 파일을 이동/복사할 때 실수로 실행 비트를 얻거나 잃기 쉽습니다.
Unix 권한(fat, ntfs 등)을 지원하지 않는 파일 시스템에 저장된 파일은 시스템에서 실행 파일로 나타날 수 있습니다. 권한 보존 도구를 사용하여 이러한 파일을 Unix 파일 시스템으로 이동하거나 복사하면 이러한 실행 가능 비트가 보존됩니다.
반면 도구를 사용하여 권한을 유지하지 못한 파일을 이동하거나 권한 유지 옵션을 선택 취소하면 원본 파일을 실행할 수 있더라도 복사본이 실행 파일로 표시되지 않을 수 있습니다.
따라서 다양한 도구를 사용하여 다양한 플랫폼에서 이동한 후 실행 권한 비트가 다소 임의적인 상태로 남을 수 있습니다.
* 실행 가능한 비트 중 전부가 아닌 일부가 설정된 경우를 ls가 어떻게 처리하는지 100% 확신할 수 없습니다.
답변4
이전 답변에서 말했듯이 색상은 파일이 실행 가능한 것으로 간주되는지 여부를 나타냅니다.
Linux 및 대부분의 기타 Unix에서 "실행" 권한(= 비트)은 파일에 대한 의미와 디렉터리에 대한 의미가 다릅니다.
디렉터리의 경우 실행 권한이 있으면 해당 내용을 볼 수 있습니다. 이렇게 하지 않으면 해당 디렉터리에 대한 읽기 및 쓰기 액세스 권한이 있어도 해당 디렉터리로 cd할 수 없고 그 안에 있는 파일을 나열할 수 없습니다.
일반 파일(장치 파일 및 기타 특수 Unix 파일 유형과 반대)의 경우 실행 비트는 명령줄에서 파일 이름을 사용하면 운영 체제(또는 더 정확하게는 셸)가 "실행"을 시도하거나 파일을 Order로 실행하세요. 반대로 파일에 대한 실행 권한이 없으면 명령줄에서 실행할 수 없습니다.
따라서 예를 들어 /bin/cat 파일(Unix 명령)에 대한 모든 사용자의 x 권한을 제거하면 "cat" 명령을 사용하려는 사용자나 다른 사람, 모든 프로그램이 실패하게 됩니다.
이는 "cat" 및 "grep"과 같은 운영 체제 명령으로, 일반적으로 /*/bin/ 디렉터리(/bin, /usr/bin, /sbin, /usr/sbin 등)에 실행 파일이 있습니다.
그런 다음 Python이나 쉘 스크립트와 같은 일부 프로그래밍 언어로 작성될 수 있는 컴파일되지 않은 해석된 스크립트가 있을 수 있습니다(기본적으로 명령줄에서 명령을 작성하는 것처럼 서버에 ssh를 사용합니다).
이제 스크립트 파일(예: foobar 파일)에 실행 비트를 설정하고 셸을 통해 실행하려고 하면: "./foobar", 셸은 파일을 구문 분석하고 스크립트를 전달할 올바른 프로그램을 찾습니다. .
쉘은 다음을 찾으려고 시도하여 파일의 첫 번째 줄을 읽습니다."셰뱅" 기호어떤 프로그램을 실행해야 할까요?
따라서 foobar가 다음 첫 줄이 포함된 텍스트 파일인 경우:
#!/usr/bin/python
그런 다음 쉘은 command: 실행을 시도하며 /usr/bin/python foobar, 기본적으로 Python 인터프리터를 호출하고 foobar 파일 이름을 Python 스크립트로 전달합니다.
쉘이 파일에서 그러한 첫 번째 줄을 찾지 못하면 마치 쉘 명령이 포함된 것처럼 foobar 자체를 실행하려고 시도합니다.
쉘은 실행 비트가 있는 파일에 유효한 쉘 명령이 포함되어 있지 않은 경우에만 불평합니다.
따라서 exec 비트가 설정된 TTF 파일이 있고 이를 명령줄에서 실행하려고 하면 다음과 같은 일이 발생합니다.
$./FreeMonoOblique.ttf
-bash: ./FreeMonoOblique.ttf: cannot execute binary file: Exec format error
$
따라서 글꼴의 경우 exec 비트가 설정되지 않으면 더 깔끔할 수 있지만 실제로는 아무 것도 변경되지 않습니다.
추신 : 관련없는 정보입니다. 일부 명령이나 스크립트에서 실행 비트를 제거하면 여전히 다른 프로그램에 인수로 전달될 수 있습니다. 다른 프로그램이 명령을 실행하는 방법을 알고 있다면 exec 비트를 제거해도 상관 없습니다. 예를 들어, 명령줄에서 다음을 수행하면 foobar Python 스크립트는 여전히 Python 인터프리터에 의해 실행됩니다.
$python foobar
바꾸다
$./foobar
"cat"과 같은 시스템 명령의 예와 동일합니다. "cat"에서 exec 비트를 제거해도 실행을 위해 이를 쉘의 새 인스턴스에 전달할 수 있습니다.
$sh -c 'cat myfile'
cat에서 exec 비트를 제거한 경우에도
$cat myfile
아니요.