Saya punya masalah shell yang tampak aneh, dengan perintah di $ PATH bahwa shell (ksh, berjalan di Linux) tampaknya pengecut menolak untuk memohon. Tanpa sepenuhnya memenuhi syarat perintah, saya mendapatkan:

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

tetapi file tersebut dapat ditemukan dimana:

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

Saya juga secara eksplisit melihat direktori itu di $ PATH:

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

Exe di lokasi itu tampak normal:

#  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

dan jika saya menjalankannya secara eksplisit menggunakan jalur yang sepenuhnya memenuhi syarat:

#  /home/me/mydir/admbin/mycommand

Saya melihat output yang diharapkan. Pasti ada sesuatu yang membingungkan shell di sini, tapi aku bingung apa yang bisa terjadi?

EDIT: menemukan apa yang tampak seperti pertanyaan serupa: Biner tidak akan mengeksekusi ketika dijalankan dengan path. Misalnya> ./ Program tidak akan berfungsi tetapi> program bekerja dengan baik

Saya juga menguji lebih dari satu perintah seperti itu di $ PATH saya, tetapi hanya menemukan satu:

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

EDIT2:

Sampai pagi ini, masalahnya telah hilang , dan saya sekarang dapat mengeksekusi dieksekusi.

Itu bisa dianggap sebagai memvalidasi saran untuk logout dan login, tetapi saya telah melakukan itu tadi malam tanpa hasil. Logout / login itu juga harus melakukan yang setara dengan menjalankan perintah 'hash -r' yang disarankan (yang fwiw juga tampaknya menjadi ksh builtin, dan bukan hanya bash builtin).

Menanggapi beberapa jawaban:

• Ini adalah executable bukan skrip (lihat referensi ELF di output perintah file).

• Saya tidak berpikir bahwa suatu langkah akan membantu. Itu akhirnya memaksa perintah untuk menjalankan sepenuhnya memenuhi syarat. Saya kira saya bisa melakukan strace menempel pada shell saat ini, tetapi karena saya tidak bisa lagi menegur tidak ada gunanya mencoba itu.

• tidak ada titik koma di $ PATH. Karena saya tidak dapat lagi menegur, saya tidak akan mengacaukan pertanyaan ini dengan $ PATH lengkap.

• mencoba shell lain (yaitu bash) akan menjadi sesuatu yang juga telah saya coba, seperti yang disarankan. Dengan masalah yang hilang, saya sekarang tidak akan tahu apakah itu akan membantu.

Saya juga menyarankan agar saya memeriksa izin direktori. Melakukannya, untuk masing-masing direktori hingga yang ini saya melihat:

# 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

Kepemilikan direktori $ HOME kacau (tidak boleh root grup). Itu bisa menyebabkan masalah lain, tapi saya tidak melihat bagaimana ini menyebabkan hal ini.

Anda mungkin perlu memperbarui cache item Anda di shell $PATHmenggunakan Anda hash -r.

Juga, dalam kasus seperti itu, periksa apa yang terjadi ketika program dipanggil dengan melewatkan executable sebagai argumen ke dynamic linker (mungkin menolak untuk melakukannya saat setuid / setgid pada beberapa sistem).

ldd (1) output dari kedua kasus mungkin juga mengungkapkan. "tidak ada file atau direktori" pada file yang dapat dieksekusi benar-benar berarti bahwa penghubung dinamis yang ditentukan dalam file yang dapat dieksekusi tidak dapat ditemukan (bayangkan file yang dapat dieksekusi memiliki ELFin dari #! / lib / ld-linux.what.so.ever di dalam)

Perilaku ini membuat orang-orang tercengang yang ada di sana untuk menyaksikan akhir era libc5, dan sekarang kadang-kadang membuat orang-orang tercengang di era campuran i386 / amd64 dengan berbagai cara mendukung dua set perpustakaan di alam liar.

RPATH relatif dalam executable vs $ PWD?

PS pertanyaan lain terkait dengan MacOSX, yang mungkin menggunakan dyld dan bukan linker yang disediakan libc. Jenis binatang yang sangat berbeda.

Baiklah, saya tidak punya jawaban. Saya memang membuktikan beberapa hal dan berpikir saya dapat menambahkan ini nanti:

• Dibuat testfile - izin Anda menunjukkan itu setuid dan dapat dieksekusi.
• Mencoba mengaturnya pada titik pemasangan dengan nosuid: masih berjalan
• Mencoba mengaturnya pada titik mount dengan noexec: memberikan kesalahan yang berbeda

Jadi, dari semua akun, saya masih bingung. Hanya untuk menyeringai dan jika ini adalah bug yang berhubungan dengan shell, dapatkah Anda mencobanya dengan shell yang berbeda?

Saya menduga bahwa skrip Anda tidak memiliki shell yang valid setelah # !. Misalnya, pada beberapa sistem SCO yang lebih lama, skrip dengan #! / Bin / bash tidak berfungsi karena bash BENAR-BENAR hidup di / usr / bin / bash. Bodoh, tapi hei SCO hampir mati karena suatu alasan, bukan?

Periksa shell Anda dan pastikan itu menunjuk ke biner / skrip nyata.

Sunting: Tidak tahu apakah ini skrip atau biner, tetapi dengan asumsi output 'ls-l' Anda benar, maka Anda mungkin tidak memiliki skrip 93kbyte ... jadi ini mungkin biner yang artinya jawaban saya adalah sama sekali tidak benar.

Sudahkah Anda mencoba keluar dan kembali? Saya tahu jika saya menggunakan biner yang ada di / usr / bin kemudian menginstal versi / usr / local / bin dari sumber, sistem masih mencoba untuk mengeksekusi yang asli sampai saya logout dan kembali.

Tebakan saya:

• Anda memiliki alias yang bernama mycommand. Sebagai contoh:

  alias mycommand=something
  

• Anda memiliki fungsi bernama mycommand. Sebagai contoh:

  mycommand() { something; }
  

Lain kali jika Anda memiliki masalah ini, coba jalankan command -V mycommanduntuk melihat perintah seperti apa yang diyakini shell mycommand.

Tidak ada jawaban, hanya sekelompok pemikiran:

1. Periksa apakah nama file mengandung spasi putih; ini diabaikan secara diam-diam saat menggunakan penyelesaian tab dan digunakan sebagai parameter.
2. Coba skrip / program lain di direktori.
3. Coba kencangkan shell yang mencoba mengeksekusi skrip dan lihat di mana skrip itu pecah.

Saya memiliki masalah yang persis sama, dan gagal menemukan jawaban karena masalah poster asli terselesaikan dengan sendirinya. Tetapi ini tidak berhasil untuk saya, dan saya akhirnya berhasil melacak masalahnya. Jadi saya menambahkan yang berikut sebagai jawaban untuk posting asli.

Gejala yang saya hadapi adalah sebagai berikut. Ada skrip (myscript.pl) di direktori / my / home. Sekarang mencoba menjalankannya:

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

Izin file yang terverifikasi (flag eksekusi sudah diatur). Terverifikasi $ PATH (meskipun seharusnya tidak ada masalah).

Jadi saya coba (setelah memverifikasi flag yang dapat dieksekusi diatur pada skrip):

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

Hmmm ... Jadi mungkin skrip tidak memanggil bahasa skrip yang tepat (perl, dalam hal ini). Bagian atas skrip memiliki sihir yang benar:

#!/usr/bin/perl

dan memang / usr / bin / perl ada dan berfungsi. Jadi panggilan berikut berfungsi dengan benar.

/usr/bin/perl myscript.pl

tab lengkapi-otomatis tidak akan menampilkan file (baik dalam tcshmaupun dalam bash).

Ini benar-benar membuat saya marah. Kemudian teringat bahwa beberapa bulan yang lalu hard disk saya rusak, dan administrator sistem muda di lab saya menginstal ulang sistem. Kupikir dia mungkin telah mengacaukan izin pada partisi. Dan memang, di /etc/fstab, izin eksekutif itu hilang!

/dev/sda1    /my     /ext4      rw,user

Dari pada

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

Memperbaiki ini dengan mengubah /etc/fstabdan mengirim ulang:

mount -v -o remount /my

Ini menyelesaikan masalah sepenuhnya. Dugaan saya adalah bahwa hal serupa mungkin terjadi dengan masalah poster asli, kecuali bahwa ada masalah izin yang terputus-putus (misalnya, ada perubahan sementara yang mungkin telah diselesaikan dengan reboot, jika terjadi).

Bukan jawaban lengkap, tetapi ingin melaporkan pengalaman saya karena saya memiliki masalah yang sama persis dengan si penanya, dan berpikir itu mungkin membantu pengguna di masa depan yang mengalami masalah menjengkelkan yang sama. Saya dapat file yang mana, dan melihatnya di jalur saya, dan bahkan menjalankannya dengan memberikan path lengkap, tetapi tidak bisa menjalankannya sebaliknya. Namun, dalam kasus saya, itu hanya terjadi di dalam sub-shell (yaitu ketika dieksekusi dari skrip, dalam kasus ini ada beberapa sub-shell bersarang). Saya bisa menjalankannya dari baris perintah dengan baik.

Tepat sebelum perintah dalam skrip bersarang, saya mencetak perintah, misalnya echo $ (yang perintah saya)

mycommand: / home / me / bin / mycommand

Maka saya akan mencoba menjalankannya dari skrip induk:

/ home / me / bin / some_parent_script [72]: mycommand: not found [Tidak ada file atau direktori]

Sama seperti si penanya, saya tidak dapat mendiagnosis sumber masalahnya. PATH saya tampak benar, itu mana yang bisa, dan hash tidak mengungkapkan entri perintah saya sebelumnya. Hari berikutnya ketika saya masuk, semuanya secara ajaib bekerja lagi. Sekarang, saya akan perhatikan di sini bahwa ada masalah sistem yang diketahui terjadi sebelum saya melihat masalah ini di mana mount dipasang kembali. Mungkin itu sebuah petunjuk?

Jika saya tidak memiliki file log setelah file log yang menunjukkan bahwa ini terjadi, saya tidak akan percaya itu mungkin! Berkat si penanya, saya tidak lagi merasa gila!

PS Saya tidak berpikir user226160 memiliki masalah yang sama PERSIS dengan reporter, tapi kedengarannya terkait, dan meminjamkan kepercayaan kepada teori mount.