쉘 (ksh, Linux에서 실행 중)이 겁쟁이 호출을 거부하는 $ PATH의 명령으로 기괴한 것처럼 보이는 쉘 문제가 있습니다. 명령을 완전히 규정하지 않으면 다음과 같은 이점이 있습니다.
# mycommand
/bin/ksh: mycommand: not found [No such file or directory]
그러나 파일은 다음으로 찾을 수 있습니다.
# which mycommand
/home/me/mydir/admbin/mycommand
또한 $ PATH에 해당 디렉토리가 명시 적으로 표시됩니다.
# echo $PATH | tr : '\n' | grep adm
/home/me/mydir/admbin
해당 위치의 exe는 정상적으로 보입니다.
# file /home/me/mydir/admbin/mycommand
/home/me/mydir/admbin/mycommand: setuid setgid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped
# ls -l mycommand
-r-sr-s--- 1 me mygroup 97892 2012-04-11 18:01 mycommand
그리고 완전한 경로를 사용하여 명시 적으로 실행하면 :
# /home/me/mydir/admbin/mycommand
예상 출력이 표시됩니다. 뭔가 분명히 여기 껍질을 혼란스럽게하지만, 나는 그것이 무엇인지 상실하고 있습니까?
편집 : 비슷한 질문처럼 보이는 것을 찾으십시오 : 경로로 실행할 때 바이너리가 실행되지 않습니다. 예 :> ./ 프로그램이 작동하지 않지만> 프로그램이 정상적으로 작동 함
또한 $ PATH에서 하나 이상의 이러한 명령을 테스트했지만 하나만 찾습니다.
# for i in `echo $PATH | tr : '\n'` ; do test -e $i/mycommand && echo $i/mycommand ; done
/home/me/mydir/admbin/mycommand
EDIT2 :
오늘 아침부터 문제가 사라졌으며 이제 실행 파일을 실행할 수 있습니다.
로그 아웃 및 로그인 제안을 확인하는 것으로 생각할 수 있지만 지난 밤에 성공하지 못했습니다. 이 로그 아웃 / 로그인은 제안 된 ‘hash -r’명령을 실행하는 것과 동등한 작업을 수행해야합니다 (fwiw는 bash 내장이 아닌 ksh 내장으로 나타남).
일부 답변에 대한 답변 :
-
스크립트가 아닌 실행 파일입니다 (파일 명령 출력의 ELF 참조 참조).
-
나는 strace가 도움이 될 것이라고 생각하지 않습니다. 결과적으로 명령이 정규화되어 실행됩니다. 현재 쉘에서 strace 연결을 수행 할 수 있다고 가정하지만 더 이상 재현 할 수 없으므로 시도 할 필요가 없습니다.
-
$ PATH에 세미콜론이 없습니다. 더 이상 재현 할 수 없으므로 전체 $ PATH 로이 질문을 어지럽히 지 않습니다.
-
다른 쉘 (예 : bash)을 시도하면 제안 된 것처럼 시도했을 수도 있습니다. 문제가 해결되면 도움이되는지 알 수 없습니다.
또한 디렉토리 권한을 확인하는 것이 좋습니다. 이렇게하면 각 디렉토리 마다이 디렉토리까지 볼 수 있습니다.
# ls -ld $HOME $HOME/mydir $HOME/mydir/admbin
drwxr-xr-x 10 me root 4096 2012-04-12 12:20 /home/me
drwxrwsr-t 22 me mygroup 4096 2012-04-12 12:04 /home/me/mydir
drwxr-sr-x 2 me mygroup 4096 2012-04-12 12:04 /home/me/mydir/admbin
$ HOME 디렉토리 소유권이 엉망입니다 (루트 그룹이 아니어야 함). 그로 인해 다른 문제가 발생할 수 있지만 이것이 어떻게 발생했는지 알 수 없습니다.
답변
$PATHusing 에서 쉘의 항목 캐시를 업데이트해야 할 수도 있습니다 hash -r.
답변
또한 이러한 경우 실행 파일을 동적 링커에 인수로 전달하여 프로그램을 호출 할 때 발생하는 상황을 확인하십시오 (일부 시스템에서는 setuid / setgid 중에는 거부 할 수 있음).
두 경우의 ldd (1) 출력도 공개 될 수 있습니다. 실행 파일에 “해당 파일이나 디렉토리가 없음”은 실제로 실행 파일에 지정된 동적 링커를 찾을 수 없음을 나타냅니다 (ELFin 형식이 #! / lib / ld-linux.what.so.ever 인 실행 파일을 상상하십시오).
이 행동은 사람들이 libc5 시대의 종말을 목격하기 위해 멍청한 짓을했으며, 때로는 때때로 i386 / amd64 혼합 시대의 사람들을 두 가지 라이브러리 세트를 야생에서 지원하는 다른 방법으로 멍청하게 만듭니다.
실행 파일의 상대 RPATH 대 $ PWD?
추신 : 다른 질문은 MacOSX와 관련이 있으며 libc 제공 링커가 아닌 dyld를 사용합니다. 매우 다른 종류의 동물.
답변
알겠습니다. 대답이 없습니다. 나는 몇 가지 사실을 입증했으며 나중에 이것에 추가 할 수 있다고 생각합니다.
- 테스트 파일을 만들었습니다. 권한은 setuid 및 실행 파일임을 보여줍니다.
- nosuid가있는 마운트 지점에서 설정을 시도했습니다 : 여전히 실행
- noexec를 사용하여 마운트 지점에서 설정을 시도했습니다. 다른 오류가 발생합니다.
모든 계정에 따르면 여전히 혼란 스러워요. 미소와 오프 기회에 대해서만 이것은 쉘 관련 버그입니다. 다른 쉘로 시도해 볼 수 있습니까?
답변
#! 다음에 스크립트에 유효한 셸이없는 것 같습니다. 예를 들어, 일부 구형 SCO 시스템에서는 bash REALLY가 / usr / bin / bash에 있기 때문에 #! / bin / bash가있는 스크립트가 작동하지 않습니다. 멍청하지만 SCO가 거의 죽었어.
쉘을 점검하고 실제 바이너리 / 스크립트를 가리키는 지 확인하십시오.
편집 : 그것은 스크립트 또는 바이너리인지 알려주지 않지만 ‘ls -l’출력이 정확하다고 가정하면 93kbyte 스크립트가 없을 것입니다. 그래서 이것은 아마도 내 대답은 바이너리입니다. 완전히 틀렸다.
로그 아웃했다가 다시 로그인 해 보셨습니까? / usr / bin에있는 바이너리를 사용하고 소스에서 / usr / local / bin 버전을 설치하면 시스템은 여전히 로그 아웃하고 다시 로그인 할 때까지 원래 버전을 실행하려고 시도합니다.
답변
내 추측 :
-
이라는 별칭이
mycommand있습니다. 예를 들면 다음과 같습니다.alias mycommand=something -
라는 함수가있었습니다
mycommand. 예를 들면 다음과 같습니다.mycommand() { something; }
다음에이 문제가 발생 command -V mycommand하면 셸이 어떤 종류의 명령을 믿는지 확인하십시오 mycommand.
답변
답이없고 단지 많은 생각 :
- 파일 이름에 공백이 있는지 확인하십시오. 이것은 탭 완성을 사용할 때 자동으로 무시되고 매개 변수로 사용됩니다.
- 디렉토리에서 다른 스크립트 / 프로그램을 시도하십시오.
- 스크립트를 실행하려고 시도하는 쉘을 strace-ing하고 그것이 부서지는 곳을보십시오.
답변
나는 정확히 같은 문제가 있었고 원래 포스터의 문제 자체가 해결 되었기 때문에 답을 찾지 못했습니다. 그러나 이것은 나에게 효과가 없었으며 마침내 문제를 추적 할 수있었습니다. 그래서 나는 원래 게시물에 대한 답변으로 다음을 추가하고 있습니다.
내가 직면 한 증상은 다음과 같습니다. / my / home 디렉토리에 스크립트 (myscript.pl)가 있습니다. 이제 실행하려고합니다.
> /my/home/myscript.pl
myscript.pl: permission denied.
파일의 확인 된 권한 (실행 플래그가 설정 됨) $ PATH 확인 (문제는 없어야 함)
그런 다음 스크립트에서 실행 가능 플래그가 설정되어 있는지 확인한 후 시도합니다.
> cd /my/home/
> ./myscript.pl: permission denied.
흠 … 그래서 아마도 스크립트가 올바른 스크립트 언어 (이 경우 perl)를 호출하지 않을 것입니다. 스크립트 상단에는 올바른 마법이 있습니다.
#!/usr/bin/perl
실제로 / usr / bin / perl이 존재하고 작동합니다. 따라서 다음 호출이 올바르게 작동합니다.
/usr/bin/perl myscript.pl
탭 자동 완성은 파일을 표시하지 않습니다 ( tcsh또는 안 bash).
이것은 정말로 나를 버렸다. 그런 다음 몇 달 전에 내 하드 디스크가 고장 나서 실험실의 젊은 시스템 관리자가 시스템을 다시 설치했음을 기억했습니다. 그는 파티션에 대한 권한을 망칠 수도 있다고 생각했습니다. 그리고 실제로, /etc/fstabexec 권한이 누락되었습니다!
/dev/sda1 /my /ext4 rw,user
대신에
/dev/sda1 /my /ext4 rw,user,exec
변경 /etc/fstab하고 다시 마운트 하여이 문제를 해결했습니다 .
mount -v -o remount /my
이것은 문제를 완전히 해결했습니다. 내 생각에 권한 문제가 간헐적으로 발생했다는 점을 제외하고는 원래 포스터의 문제와 비슷한 일이 발생했을 수 있습니다 (예 : 일시적인 변경으로 인해 재부팅으로 해결되었을 수 있음).