Mam dziwnie pozorny problem z powłoką, z poleceniem w $ PATH, które wydaje się, że powłoka (ksh, działająca na Linuksie) odmawia wywołania. Bez pełnego kwalifikowania polecenia otrzymuję:

#  mycommand
/bin/ksh: mycommand: not found [No such file or directory]

ale plik można znaleźć, za pomocą którego:

#  which mycommand
/home/me/mydir/admbin/mycommand

Widzę też wyraźnie ten katalog w $ PATH:

#  echo $PATH | tr : '\n' | grep adm
/home/me/mydir/admbin

Exe w tej lokalizacji wydaje się normalny:

#  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

a jeśli uruchomię go jawnie, używając w pełni kwalifikowanej ścieżki:

#  /home/me/mydir/admbin/mycommand

Widzę oczekiwany wynik. Coś tutaj zdecydowanie myli powłokę, ale nie wiem, co to może być?

EDYCJA: znajdowanie czegoś, co wyglądało na podobne pytanie: Plik binarny nie zostanie wykonany po uruchomieniu ze ścieżką. Np.> ./ program nie działa, ale> program działa dobrze

Przetestowałem także więcej niż jedną taką komendę w mojej $ PATH, ale znajduję tylko jedną:

# for i in `echo $PATH | tr : '\n'` ; do test -e $i/mycommand && echo $i/mycommand ; done
/home/me/mydir/admbin/mycommand

EDYCJA 2:

Od rana problem zniknął , a teraz jestem w stanie wykonać plik wykonywalny.

Można to uznać za potwierdzenie sugestii wylogowania i zalogowania, ale zrobiłem to ostatniej nocy bez powodzenia. To wylogowanie / logowanie powinno również wykonać równoważne działanie polecenia „hash -r”, które zostało zasugerowane (który fwiw wydaje się być wbudowanym ksh, a nie tylko wbudowanym bash).

W odpowiedzi na niektóre odpowiedzi:

• Jest to plik wykonywalny, a nie skrypt (patrz odwołanie do ELF w danych wyjściowych polecenia file).

• Nie sądzę, że strata pomogłaby. To ostatecznie wymusza wykonanie polecenia w pełni kwalifikowanego. Przypuszczam, że mógłbym wykonać przyczepność strace do bieżącej powłoki, ale skoro nie mogę już repro, nie warto próbować tego.

• w zmiennej PATH nie było średników. Ponieważ nie mogę już repro, nie będę zaśmiecać tego pytania pełną ścieżką $ PATH.

• próba użycia innej powłoki (tj. bash) byłaby czymś, czego próbowałem, jak sugerowano. Po rozwiązaniu problemu nie będę wiedział, czy to by pomogło.

Zasugerowano mi również sprawdzenie uprawnień do katalogu. Robię to, dla każdego z katalogów do tego widzę:

# 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

Własność katalogu $ HOME jest pomieszana (nie powinna to być grupa główna). Może to powodować inne problemy, ale nie wiem, jak by to spowodowało.

Prawdopodobnie trzeba zaktualizować pamięć podręczną powłoki z elementów w $PATHużyciu hash -r.

Ponadto w takich przypadkach sprawdź, co się dzieje, gdy program jest wywoływany, przekazując jego plik wykonywalny jako argument do dynamicznego linkera (może odmówić wykonania, gdy setuid / setgid w niektórych systemach).

Wyjście ldd (1) obu przypadków może również ujawniać. „brak takiego pliku lub katalogu” w pliku wykonywalnym naprawdę oznacza, że ​​nie można znaleźć dynamicznego linkera określonego w pliku wykonywalnym (wyobraź sobie, że plik wykonywalny ma postać ELFin #! / lib / ld-linux.what.so.ever wewnątrz)

Zachowanie to wprawiało w osłupienie ludzi, którzy byli świadkami końca ery libc5, a od czasu do czasu ogłuszają ludzi w erze mieszanego i386 / amd64 za pomocą różnych sposobów wspierania dwóch zestawów bibliotek na wolności.

Względna RPATH w pliku wykonywalnym vs $ PWD?

PS drugie pytanie dotyczy MacOSX-a, który prawdopodobnie używa dyld a nie linkera dostarczonego przez libc. Zupełnie inny rodzaj zwierząt.

W porządku, nie mam odpowiedzi. Udowodniłem kilka rzeczy i myślę, że mogę dodać do tego później:

• Utworzono plik testowy - twoje uprawnienia pokazują, że jest on konfigurowalny i wykonywalny.
• Próbowałem ustawić go w punkcie montowania za pomocą nosuid: nadal działa
• Próbowałem ustawić go w punkcie montowania z noexec: daje inny błąd

Tak więc, według wszystkich kont, nadal jestem tak zdezorientowany. Tylko na uśmiech i przy okazji jest to błąd związany z powłoką, czy możesz spróbować z inną powłoką?

Zgaduję, że twój skrypt nie ma prawidłowej powłoki po # !. Na przykład w niektórych starszych systemach SCO skrypty z #! / Bin / bash nie działają, ponieważ bash NAPRAWDĘ mieszka w / usr / bin / bash. Głupi, ale hej SCO jest prawie martwy z jakiegoś powodu, nie?

Sprawdź swoją powłokę i upewnij się, że wskazuje ona na prawdziwy plik binarny / skrypt.

Edycja: Nie mówi, czy jest to skrypt, czy plik binarny, ale zakładając, że twój wynik 'ls -l' jest poprawny, prawdopodobnie nie masz skryptu 93kbyte ... więc to prawdopodobnie binarne, co oznacza, że ​​moja odpowiedź brzmi: całkowicie niepoprawne.

Czy próbowałeś się wylogować i ponownie zalogować? Wiem, że jeśli użyję pliku binarnego, który znajduje się w / usr / bin, a następnie zainstaluję wersję / usr / local / bin ze źródła, system nadal próbuje wykonać oryginalny, dopóki się nie wyloguję i nie zaloguję ponownie.

Moje domysły:

• Miałeś alias o nazwie mycommand. Na przykład:

  alias mycommand=something
  

• Miałeś funkcję o nazwie mycommand. Na przykład:

  mycommand() { something; }
  

Następnym razem, gdy wystąpi ten problem, spróbuj uruchomić, command -V mycommandaby zobaczyć, jakie polecenie uważa za shellowe mycommand.

Brak odpowiedzi, tylko kilka myśli:

1. Sprawdź, czy nazwa pliku zawiera białe znaki; jest to dyskretnie ignorowane podczas korzystania z uzupełniania tabulatorów i używania jako parametru.
2. Wypróbuj inny skrypt / program w katalogu.
3. Spróbuj prześledzić powłokę, próbując wykonać skrypt i zobaczyć, gdzie się psuje.

Miałem dokładnie ten sam problem i nie udało mi się znaleźć odpowiedzi, ponieważ problem oryginalnego plakatu rozwiązał się sam. Ale to nie zadziałało i w końcu udało mi się wyśledzić problem. Więc dodam następujące jako odpowiedź na oryginalny post.

Objawy, z którymi się spotkałem, były następujące. W katalogu / my / home znajduje się skrypt (myscript.pl). Teraz próbuję go uruchomić:

> /my/home/myscript.pl
myscript.pl:  permission denied.

Zweryfikowano uprawnienia do pliku (ustawiona jest flaga wykonania). Zweryfikowano $ PATH (chociaż nie powinno być problemu).

Więc próbuję (po sprawdzeniu, czy w skrypcie ustawiono flagę wykonywalną):

> cd /my/home/
> ./myscript.pl:  permission denied.

Hmmm ... Może więc skrypt nie wywołuje odpowiedniego języka skryptowego (w tym przypadku perl). Góra skryptu ma właściwą magię:

#!/usr/bin/perl

i rzeczywiście / usr / bin / perl istnieje i działa. Tak więc poniższe połączenie działa poprawnie.

/usr/bin/perl myscript.pl

autouzupełnianie z kartami nie wyświetla pliku (ani w, tcshani w bash).

To naprawdę mnie odrzuciło. Potem przypomniałem sobie, że kilka miesięcy temu mój dysk twardy się zawiesił, a młody administrator systemu w moim laboratorium ponownie zainstalował system. Pomyślał, że mógł zepsuć uprawnienia do partycji. I rzeczywiście, /etc/fstabbrakowało pozwolenia na wykonanie!

/dev/sda1    /my     /ext4      rw,user

Zamiast

/dev/sda1    /my     /ext4      rw,user,exec

Naprawiono to poprzez zmianę /etc/fstabi ponowne zamontowanie:

mount -v -o remount /my

To całkowicie rozwiązało problem. Domyślam się, że podobna sytuacja mogła się wydarzyć w przypadku problemu z oryginalnym plakatem, z tym wyjątkiem, że problem z pozwoleniem był sporadyczny (np. Nastąpiła tymczasowa zmiana, która mogłaby zostać rozwiązana przy ponownym uruchomieniu komputera, gdyby taki miał miejsce).

Nie jest to pełna odpowiedź, ale chciałem zgłosić moje doświadczenie, ponieważ miałem dokładnie ten sam problem co pytający, i pomyślałem, że może to pomóc przyszłym użytkownikom, którzy doświadczają tego samego irytującego problemu. Mógłbym, który plik, i zobaczyć go na mojej ścieżce, a nawet wykonać go, podając pełną ścieżkę, ale nie mogłem go wykonać inaczej. Jednak w moim przypadku zdarzyło się to tylko w podpowłoce (tzn. Kiedy zostało wykonane ze skryptu, w tym przypadku było kilka zagnieżdżonych podpowłok). Mógłbym dobrze uruchomić z linii poleceń.

Tuż przed poleceniem w skrypcie zagnieżdżonym wydrukowałem polecenie, np. Echo $ (która moja komenda)

mycommand: / home / me / bin / mycommand

Następnie spróbuję wykonać go ze skryptu nadrzędnego:

/ home / me / bin / some_parent_script [72]: mycommand: not found [Brak takiego pliku lub katalogu]

Podobnie jak pytający, nie byłem w stanie zdiagnozować źródła problemu. Moja ŚCIEŻKA wyglądała dobrze, była w stanie, a hash nie ujawnił żadnych wcześniejszych wpisów mycommand. Następnego dnia, kiedy się zalogowałem, wszystko magicznie znów zadziałało. Teraz zauważę, że był znany problem z systemem, który wystąpił tuż przed tym, jak zobaczyłem ten problem, w którym zamontowano ponownie mount. Być może to jest wskazówka?

Gdybym nie miał pliku dziennika za plikiem dziennika wykazującym, że tak się stało, nie uwierzyłbym, że to możliwe! Dzięki pytającemu nie czuję się już szalony!

PS Nie sądzę, aby użytkownik user226160 miał DOKŁADNIE taki sam problem jak reporter, ale wydaje się, że jest on powiązany i nadaje wiarygodność teorii montowania.