$ PATH içinde bir komutla kabuğun (ksh, Linux üzerinde çalışıyor) çağırmak için korkakca reddetmeyi reddettiği tuhaf bir kabuk sorunu var. Komutu tam olarak nitelendirmeden:

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

ancak dosya şu şekilde bulunabilir:

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

Ayrıca açıkça bu dizin $ PATH bakın:

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

Bu konumdaki exe normal görünüyor:

#  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

ve ben tamamen nitelikli bir yol kullanarak açıkça çalıştırmak:

#  /home/me/mydir/admbin/mycommand

Beklenen çıktıyı görüyorum. Burada bir şey kesinlikle kafa karıştırıyor, ama ne olabilirim?

EDIT: benzer bir soru neye benzediğini bulma: İkili bir yol ile çalıştırıldığında yürütülmez. Örn.> ./ program çalışmaz ama> program iyi çalışıyor

Ayrıca benim $ PATH birden fazla böyle bir komut için test, ama sadece bir tane bulmak:

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

EDIT2:

Bu sabah itibariyle sorun ortadan kalktı ve şimdi çalıştırılabilir dosyayı yürütebiliyorum.

Bu durum, çıkış ve giriş önerisini doğrulamak olarak düşünülebilir, ancak bunu dün gece başarı olmadan yaptım. Bu oturum kapatma / oturum açma işlemi, önerilen 'hash -r' komutunu çalıştırmaya eşdeğer olmalıdır (ki bu da sadece bir bash yerleşimi değil, bir ksh yerleşimi gibi görünüyor).

Bazı cevaplara yanıt olarak:

• Bu bir komut dosyası değil yürütülebilir bir dosyadır (dosya komut çıkışındaki ELF referansına bakın).

• Bir askerin yardımcı olacağını düşünmüyorum. Bu, komutu tam nitelikli yürütmeye zorlar. Mevcut kabuk üzerinde bir strace eki yapabileceğimi düşünüyorum, ama artık üreyemediğim için bunu denemenin bir anlamı yok.

• $ PATH içinde noktalı virgül yoktu. Artık üreme yapamayacağım için, bu soruyu $ PATH ile doldurmayacağım.

• başka bir kabuk (yani bash) denemek, önerildiği gibi, ben de denedim bir şey olurdu. Sorun ortadan kalktığında, bunun yardımcı olup olmayacağını artık bilemeyeceğim.

Ayrıca bana dizin izinlerini kontrol etmek önerildi. Bunu yaparak, buna kadar olan dizinlerin her biri için şunu görüyorum:

# 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 dizini sahipliği bozuldu (kök grup olmamalı). Bu başka sorunlara neden olabilir, ama buna nasıl sebep olacağını görmüyorum.

Muhtemelen senin öğelerin kullandığınız kabuğun önbelleğini güncellemeniz gerekir $PATHkullanarak hash -r.

Ayrıca, bu gibi durumlarda, programı dinamik bağlayıcıya argüman olarak geçirerek program çağrıldığında ne olacağını kontrol edin (bazı sistemlerde setuid / setgid yaparken bunu yapmayı reddedebilir).

Her iki vakanın ldd (1) çıktısı da açıklayıcı olabilir. Yürütülebilir bir dosyadaki "böyle bir dosya veya dizin yok", yürütülebilir dosyada belirtilen dinamik bağlayıcının bulunamadığını gösterir (çalıştırılabilir dosyanın #! / lib / ld-linux.what.so.ever dosyasında ELFin biçimine sahip olduğunu hayal edin)

Bu davranış, libc5 döneminin sonuna tanıklık etmek için orada olan insanları şaşkına çevirdi ve şimdi zaman zaman karışık i386 / amd64 çağındaki insanları vahşi doğada iki kütüphane setini desteklemek için farklı araçlarla şaşkına çevirdi.

$ PWD vs yürütülebilir RPATH göreceli?

PS, diğer soru muhtemelen libc tarafından sağlanan linker değil dyld kullanan MacOSX ile ilgilidir. Çok farklı bir hayvan türü.

Pekala, bir cevabım yok. Birkaç şeyi kanıtladım ve buna daha sonra ekleyebileceğimi düşünüyorum:

• Bir test dosyası oluşturuldu - izinleriniz bunun setuid ve yürütülebilir olduğunu gösteriyor.
• Nosuid ile bir montaj noktasına kurmaya çalıştım: hala çalışıyor
• Noexec ile bir bağlama noktasında ayarlanmaya çalışıldı: farklı bir hata veriyor

Yani, tüm hesaplara göre, hala kafam karıştı. Sadece sırıtarak ve kapalı şansla bu kabukla ilgili bir hata, farklı bir kabukla deneyebilir misiniz?

#! 'Dan sonra betiğinizin geçerli bir kabuğu olmadığını tahmin ediyorum. Örneğin, bazı eski SCO sistemlerinde #! / Bin / bash içeren komut dosyaları çalışmaz, çünkü bash GERÇEKTEN / usr / bin / bash içinde yaşar. Aptal, ama hey SCO bir sebepten ötürü neredeyse öldü, değil mi?

Kabuğunuzu kontrol edin ve gerçek bir ikiliye / betiğe işaret ettiğinden emin olun.

Düzenleme: Bir komut dosyası veya ikili olup olmadığını söylemez, ancak 'ls -l' çıktısının doğru olduğunu varsayarsak, muhtemelen 93kbaytlık bir komut dosyanız yoktur ... bu yüzden bu muhtemelen benim cevabım ikili bir anlamdır tamamen yanlış.

Oturumu kapatıp tekrar açmayı denediniz mi? Ben / usr / bin içinde bir ikili kullanmak ve sonra kaynağından bir / usr / local / bin sürümünü yüklemek eğer biliyorum, sistem hala çıkış ve tekrar giriş kadar orijinal bir yürütmek çalışır.

Tahminlerim:

• Adlı bir takma adınız vardı mycommand. Örneğin:

  alias mycommand=something
  

• Adlı bir fonksiyonunuz vardı mycommand. Örneğin:

  mycommand() { something; }
  

Bir dahaki sefere bu sorunla karşılaştığınızda, command -V mycommandkabuğun ne tür bir komut olduğuna inandığını görmek için koşmayı deneyin mycommand.

Cevap yok, sadece birkaç düşünce:

1. Dosya adının boşluk içerip içermediğini kontrol edin; sekme tamamlama kullanılırken ve parametre olarak kullanıldığında sessizce yok sayılır.
2. Dizindeki başka bir komut dosyasını / programı deneyin.
3. Komut dosyasını yürütmeye çalışırken kabuğunu dizmeyi deneyin ve nerede kırıldığını görün.

Tamamen aynı problemi yaşadım ve orijinal posterin problemi kendiliğinden çözüldüğü için bir cevap bulamadım. Ama bu benim için işe yaramadı ve sonunda sorunu izlemeyi başardım. Bu yüzden orijinal gönderinin cevabı olarak aşağıdakileri ekliyorum.

Karşılaştığım belirtiler şunlardı. / My / home dizininde bir komut dosyası (myscript.pl) var. Şimdi çalıştırmayı deniyorum:

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

Dosyanın onaylanmış izni (yürütme bayrağı ayarlanmıştır). Doğrulanmış $ PATH (bir sorun olmamasına rağmen).

Bu yüzden sonra denemek (çalıştırılabilir bayrak doğruladıktan sonra komut dosyası ayarlanır):

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

Hmmm ... Belki de senaryo doğru kodlama dilini (bu durumda perl) çağırmıyor olabilir. Senaryonun üst kısmı doğru büyüye sahiptir:

#!/usr/bin/perl

ve / usr / bin / perl vardır ve çalışır. Bu nedenle aşağıdaki çağrı düzgün çalışıyor.

/usr/bin/perl myscript.pl

otomatik tamamlama sekmesi dosyayı göstermez (ne içeri ne de tcshiçeri bash).

Bu gerçekten beni attı. Sonra birkaç ay önce sabit diskimin çöktüğünü ve laboratuvarımdaki genç sistem yöneticisinin sistemi yeniden yüklediğini hatırladım. Bölümlerdeki izinleri bertaraf etmiş olabileceğini düşündüm. Ve aslında, /etc/fstabicra izni eksikti!

/dev/sda1    /my     /ext4      rw,user

Onun yerine

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

Bunu değiştirerek /etc/fstabve yeniden monte ederek düzeltildi :

mount -v -o remount /my

Bu sorunu tamamen çözdü. Benim tahminim, orijinal posterin probleminde de benzer bir şey olmuş olabilir, ancak izin sorunu aralıklıydı (örneğin, bir yeniden başlatma ile çözülmüş olabilecek geçici bir değişiklik vardı).

Tam bir cevap değil, ancak sorgulayanla aynı problemi yaşadığımı ve aynı kullanıcıların gelecekteki kullanıcılara aynı çılgınlık problemini yaşamalarına yardımcı olabileceğini düşündüğüm için deneyimimi bildirmek istedim. Ben hangi dosyayı, benim yolumda görmek ve hatta tam yol vererek yürütmek olabilir, ancak aksi takdirde yürütülemedi. Ancak, benim durumumda, sadece bir alt kabuk içinde oldu (yani bir komut dosyasından yürütüldüğünde, bu durumda birkaç iç içe alt kabuk vardı). Sadece komut satırından çalıştırabilirim.

Yuvalanmış komut dosyasındaki komuttan hemen önce, komutu yazdırdım, örneğin echo $ (hangi mycommand)

mycommand: / ev / ben / bin / mycommand

Sonra üst komut dosyasından yürütmek çalışacağız:

/ home / me / bin / some_parent_script [72]: mycommand: bulunamadı [Böyle bir dosya veya dizin yok]

Aynı soru soran gibi, sorunun kaynağını teşhis edemedim. PATH'm doğru görünüyordu, bu mümkün ve hash myommand'ın önceki girişlerini ortaya koymadı. Ertesi gün giriş yaptığımda, her şey sihirli bir şekilde tekrar çalıştı. Şimdi, burada bir bağın yeniden takıldığı bu sorunu görmeden hemen önce meydana gelen bilinen bir sistem sorunu olduğunu not edeceğim. Belki de bir ipucu?

Bunun olduğunu gösteren günlük dosyasından sonra günlük dosyasına sahip olmasaydım, bunun mümkün olduğuna inanmazdım! Sorgulayan sayesinde artık deli hissetmiyorum!

PS Ben user226160 muhabir ile aynı problemi olduğunu sanmıyorum, ama ilgili geliyor ve mount teorisine güven veriyor.