Windows에서는 파일 확장자를 프로그램과 연결할 수 있습니다. 예를 들어, 확장자로 인해 설치된 인터프리터에서
파일을 실행할 수 있습니다. test.pl
Linux에서는 첫 번째 줄에 있어야 합니다. Linux에서는 파일 확장자와 프로그램 사이에 상관 관계가 없기 때문입니까?Perl
pl
#!/usr/bin/perl
답변1
아니요, 그런 뜻이 아닙니다. 실행 권한이 설정된 텍스트 파일(예: )이 있고 chmod a+x somefile
파일의 첫 번째 줄이 다음과 같은 경우
"#!/path/to/executable"
단지 스크립트를 실행하는 데 사용할 프로그램을 Unix에 알려줄 뿐입니다. 텍스트 파일이 실행 가능(예: 스크립트)으로 표시되면 Unix는 이 방식으로 지정된 모든 프로그램을 시작하고 텍스트 파일(스크립트)의 나머지 부분을 해당 프로그램으로 보냅니다. 일반적으로 지정된 프로그램은 셸( /bin/sh
또는 ), 일부 프로그래밍 언어(Perl, Python 또는 Ruby)에 대한 인터프리터 또는 스크립트를 실행하는 다른 프로그램(예: 텍스트 조작기 Awk 또는 Sed)입니다 /bin/csh
./bin/bash
일반적으로 "#"은 다음과 같은 경우에만 여러 언어로 주석을 지정합니다.첫 번째이 줄은 특별한 "#!"으로 시작됩니다. 파일이 실행 파일로 표시되었지만 "#!"으로 시작하지 않는 경우 Unix는 해당 파일이 일종의 바이너리 파일(예: C 컴파일러 및 링커에 의해 생성된 ELF 실행 파일)이라고 가정합니다.
일반적으로 Unix는 파일 접미사에 의존하지 않습니다. 많은 프로그램은 일반적인 접미사를 요구하지도 않고 자동으로 추가하지도 않습니다. 한 가지 예외는 프로그램 중 하나(잘못된 접미사에 대해 불평하는 프로그램 중 하나) gzip
와bzip2
대신, 파일은 "마법의 숫자" 및 기타 식별자를 찾는 일련의 테스트를 통해 해당 내용으로 식별됩니다( file
이를 테스트하기 위해 일부 파일에서 명령을 시도할 수 있음). 또한 GNOME 및 KDE의 파일 브라우저에서 파일 열기/편집을 위한 아이콘과 프로그램 목록을 선택하는 데 사용됩니다. 여기서는 이러한 테스트를 통해 파일의 MIME 유형을 식별하고 Windows의 접미사 대신 MIME 유형과 관련된 목록에서 보기 및 편집에 적합한 프로그램을 찾습니다.
테스트 중 하나는 텍스트 파일의 첫 번째 줄이 "#!/something"인지 확인한 다음 "something"이 무엇인지 확인하는 것이므로 #!/usr/bin/perl
파일을 Perl 스크립트로 식별한다고 말할 수 있습니다. 부작용. 테스트에서는 "#!"으로 시작하지 않더라도 파일을 올바르게 식별해야 합니다. 그럼에도 불구하고 파일을 식별하는 데 사용되는 것은 임의의 접미사가 아닌 파일 내용입니다. 따라서 .pl(Perl) 및 .awk(Awk)와 같은 끝부분은 순전히 사용자가 파일 유형을 식별하는 데 도움이 되며 Unix에서는 유형을 제한하기 위해(Windows의 접미사처럼) 사용되지 않습니다.
실제로 "#!/something" 없이 "스크립트"를 만들 수 있지만 Unix는 이를 자동으로 실행 파일로 실행할 수 없습니다(어떤 프로그램에서 스크립트를 실행할지 알 수 없음). 대신 perl myscript
, 또는 같은 것을 사용하여 "수동으로" 시작 해야 합니다 python myscript
. 대규모 Python 및 Perl 응용 프로그램의 많은 스크립트는 "내부적으로 사용되는" 스크립트이고 사용자가 직접 호출할 수 없기 때문에 실제로 "#!/something"으로 시작하지 않습니다.
대신, 기본 스크립트("#!/something"으로 시작)를 시작한 다음 해당 스크립트가 실행되는 동안 이러한 다른 스크립트를 인터프리터에 전달합니다.
답변2
Windows에서는 파일 확장자를 프로그램과 연결할 수 있습니다. 예를 들어 test.pl 파일은 pl 확장자 때문에 설치된 Perl 해석기에 의해 실행될 수 있습니다.
예, 하지만 확장자는 파일 형식에 대한 힌트일 뿐입니다. Perl 구문 스크립트는 이름이 ".pl", ".exe" 또는 ".doc"인지 여부에 관계없이 여전히 Perl 구문 스크립트입니다. 예를 들어, 인터프리터를 직접 호출하여 계속 실행할 수 있습니다. perl.exe thisfile.doc
파일이 Perl 구문 파일이면 작동합니다. 원하는 경우 ".blah"를 Perl 파일과 연결할 수도 있습니다.
Linux에서는 첫 번째 줄에 #!/usr/bin/perl이 필요합니다.
다시 한번 말씀드리지만 이것은 단지 팁일 뿐입니다. 명령에 대한 인수로 스크립트를 직접 호출하여 Shebang 없이도 Perl 파일을 호출할 수 있습니다 perl
.
Linux에서는 파일 확장자와 프로그램 사이에 상관 관계가 없기 때문입니까?
기술적으로는 그렇습니다.
Linux에는 실제로 실행 파일 형식을 식별하는 여러 가지 방법이 있습니다. 이 file
명령은 이에 대한 지침을 제공합니다. 여기에는 특정 파일의 유형을 결정하는 데 사용되는 "마법"(특정 오프셋에서 특정 길이의 문자열) 데이터베이스가 포함되어 있습니다. 이는 파일의 내용을 검사하여 그것이 무엇인지 결정함으로써 이를 수행합니다. 또 다른 방법은 파일 확장자를 사용하는 것입니다. 실제로 "binfmt_misc"라는 시스템을 사용하여 원하는 동작을 등록할 수 있습니다.위키피디아작동 방식을 설명합니다("마법" 및 파일 확장자 사용).
Linux에서는 파일 권한에 대한 "실행 가능" 비트 개념을 통해 파일이 임의로 "실행 가능"으로 간주됩니다. 실행 가능 비트를 사용하여 응용 프로그램을 실행하려고 하면 커널은 파일의 처음 몇 바이트를 읽어 무엇을 할지 결정합니다.
- 파일이 다음으로 시작하는 경우
#!
제공된 경로의 명령은 다음 파일을 명령의 마지막 인수로 사용하여 호출됩니다. - 파일이 ELF로 시작하는 경우 실행하고
/lib{64}/ld-linux.so
(실제로 ELF 바이너리의 섹션 헤더에서 가져오며 방금 사용한 정적 경로가 아님) 명령을 실행합니다(일련의 라이브러리 정적 로드를 수행함). - binfmt_misc에 적용되는 규칙을 확인하세요.
a.out 형식 나는 그들의 호출에 그다지 익숙하지 않습니다. 나는 ld-linux.so 로더가 여전히 그것을 처리할 수 있다고 가정합니다.
답변3
아니요, 그렇지 않습니다. Shebang( #!
) 및 파일 형식과 애플리케이션 간의 연결은 서로 다른 목적으로 사용되며 데스크톱 Linux 배포판에서 둘 다 찾을 수 있습니다.
명령줄이나 다른 스크립트에서 호출되는 실행 가능한 스크립트에서는 전자를 사용하는 것이 일반적이며 파일 확장자에 의존하지 않습니다. Windows에서는 파일 확장자에 의존하는 PATHEXT 환경 변수를 통해 유사한 기능을 사용할 수 있습니다.
후자는 데스크탑 인터페이스에서 아이콘이나 파일 이름을 클릭하는 사용자에게 서비스를 제공합니다. Linux 세계에서는 이것이 다음에서 유래합니다.MIME 유형을 애플리케이션과 연결물론 이는 특정 도구에 의해 처리되며 일반적인 데스크톱 사용자의 사양을 읽을 필요는 없습니다.
답변4
GNU/Linux가 파일 확장자와 프로그램 사이에 상관관계가 없다는 것이 아니라 GNU/Linux가 실제로 상관관계를 신경쓰지 않기 때문에 그러한 비교를 할 수 없습니다.
파일 권한이 있으며 파일이 실행 가능한 경우 항상 스크립트의 첫 번째 줄에서 shebang을 검색하여 실행 방법을 확인합니다.
반면, Linux용 ELF 바이너리에는 Windows 바이너리와 같은 exe 확장자가 없으며, 확장자가 없어도 항상 실행 가능합니다.