ฉันมีปัญหาเกี่ยวกับเชลล์ที่แปลกประหลาดโดยมีคำสั่งใน $ PATH ว่าเชลล์ (ksh, ที่ทำงานบน Linux) ดูเหมือนจะขี้ขลาดปฏิเสธที่จะเรียกใช้ ฉันจะได้รับ:

#  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 ใดที่ดูเหมือนว่าจะเป็น ksh builtin และไม่ใช่แค่ bash builtin)

ในการตอบกลับบางคำตอบ:

• นี่เป็นไฟล์เรียกทำงานที่ไม่ใช่สคริปต์ (ดูการอ้างอิงของ ELF ในเอาต์พุตคำสั่งไฟล์)

• ฉันไม่คิดว่า strace จะช่วยได้ ที่จบลงด้วยการบังคับให้คำสั่งดำเนินการแบบเต็ม ฉันคิดว่าฉันสามารถทำ strace ที่แนบกับเชลล์ปัจจุบันได้ แต่เนื่องจากฉันไม่สามารถทำซ้ำได้อีกต่อไปจึงไม่มีจุดทดลองอีกต่อไป

• ไม่มีเครื่องหมายอัฒภาคใน $ PATH เนื่องจากฉันไม่สามารถพูดได้อีกต่อไปฉันจะไม่ส่งเสียงดังรบกวนคำถามนี้ด้วย $ PATH แบบเต็ม

• การลองเปลือกอีกอัน (เช่นทุบตี) จะเป็นสิ่งที่ฉันอยากลองตามที่แนะนำ ด้วยปัญหาที่หายไปตอนนี้ฉันก็ไม่รู้ว่าจะช่วยได้หรือไม่

มันก็แนะนำให้ฉันคือการตรวจสอบสิทธิ์ไดเรกทอรี ทำเช่นนั้นสำหรับแต่ละไดเรกทอรีถึงหนึ่งนี้ฉันเห็น:

# 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 ถูกทำให้ยุ่งเหยิง (ไม่ควรเป็นกลุ่มรูท) นั่นอาจทำให้เกิดปัญหาอื่น ๆ แต่ฉันไม่เห็นว่ามันจะทำให้เกิดปัญหานี้ได้อย่างไร

คุณอาจจำเป็นต้องปรับปรุงแคชเปลือกของคุณของรายการในของคุณโดยใช้$PATHhash -r

นอกจากนี้ในกรณีเช่นนี้ให้ตรวจสอบว่าเกิดอะไรขึ้นเมื่อโปรแกรมถูกเรียกใช้โดยส่งโปรแกรมปฏิบัติการเป็นอาร์กิวเมนต์ไปยังตัวเชื่อมโยงแบบไดนามิก (อาจปฏิเสธที่จะทำเช่นนั้นในขณะที่ setuid / setgid ในบางระบบ)

ldd (1) เอาต์พุตของทั้งสองกรณีอาจถูกเปิดเผยเช่นกัน "ไม่มีไฟล์หรือไดเรกทอรีดังกล่าว" ในไฟล์ที่ปฏิบัติการได้จริง ๆ แล้วหมายความว่าไม่สามารถหาตัวเชื่อมโยงแบบไดนามิกที่ระบุในไฟล์ปฏิบัติการได้ (ลองนึกถึงไฟล์ปฏิบัติการที่มีรูปแบบ ELFin ของ #! / lib / ld-linux.what.so.ever ภายใน)

พฤติกรรมนี้ทำให้ผู้คนตะลึงที่นั่นเป็นพยานถึงจุดจบของยุค libc5 และตอนนี้บางครั้งก็ทำให้ผู้คนตะลึงในยุคของการผสม i386 / amd64 ด้วยวิธีที่แตกต่างกันในการสนับสนุนห้องสมุดสองชุดในป่า

สัมพัทธ์ RPATH ในการดำเนินการเทียบกับ $ PWD?

ป.ล. คำถามอื่น ๆ ที่เกี่ยวข้องกับ MacOSX ซึ่งอาจใช้ dyld ไม่ใช่ libc ที่มีให้ linker สัตว์ต่างชนิดกันมาก

เอาล่ะฉันไม่มีคำตอบ ฉันพิสูจน์บางสิ่งและคิดว่าฉันจะเพิ่มสิ่งนี้ในภายหลัง:

• สร้างไฟล์ทดสอบ - การอนุญาตของคุณแสดงว่าตั้งค่าได้และสามารถเรียกใช้งานได้
• พยายามตั้งค่าบนจุดเมานท์ด้วย nosuid: ยังคงทำงานอยู่
• พยายามตั้งค่าบนจุดเชื่อมต่อด้วย noexec: ให้ข้อผิดพลาดที่แตกต่างกัน

ดังนั้นโดยบัญชีทั้งหมดฉันยังคงสับสน สำหรับรอยยิ้มและโอกาสที่จะเกิดขึ้นนี่เป็นข้อผิดพลาดเกี่ยวกับเชลล์คุณสามารถลองใช้เชลล์อื่นได้หรือไม่?

ฉันเดาว่าสคริปต์ของคุณไม่มีเชลล์ที่ถูกต้องหลังจาก #! ตัวอย่างเช่นในบางระบบ SCO ที่เก่ากว่าสคริปต์ที่มี #! / bin / bash ไม่ทำงานเนื่องจาก bash ใช้งานได้จริงใน / usr / bin / bash โง่ แต่เฮ้ SCO เกือบตายแล้วด้วยเหตุผลใช่ไหม?

ตรวจสอบเชลล์ของคุณและตรวจสอบให้แน่ใจว่ามันชี้ไปที่ไบนารี / สคริปต์จริง

แก้ไข: มันไม่ได้บอกว่ามันเป็นสคริปต์หรือไบนารี แต่สมมติว่าเอาต์พุต 'ls -l' ของคุณถูกต้องแล้วคุณอาจไม่มีสคริปต์ 93kbyte ... ดังนั้นนี่อาจเป็นความหมายไบนารีที่คำตอบของฉันคือ ไม่ถูกต้องทั้งหมด

คุณลองออกจากระบบและกลับเข้ามาใหม่? ฉันรู้ว่าถ้าฉันใช้ไบนารีที่อยู่ใน / usr / bin แล้วติดตั้งรุ่น / usr / local / bin จากแหล่งที่มาระบบยังคงพยายามที่จะดำเนินการตามเดิมจนกว่าฉันจะออกจากระบบและกลับเข้ามา

ฉันเดา:

• mycommandคุณได้รับการตั้งชื่อนามแฝง ตัวอย่างเช่น:

  alias mycommand=something
  

• mycommandคุณมีฟังก์ชั่นการตั้งชื่อ ตัวอย่างเช่น:

  mycommand() { something; }
  

ครั้งต่อไปที่คุณมีปัญหานี้ลองใช้command -V mycommandเพื่อดูสิ่งที่ชนิดของคำสั่งเชลล์เชื่อว่าmycommandเป็น

ไม่มีคำตอบเป็นเพียงความคิด:

1. ตรวจสอบว่าชื่อไฟล์มีช่องว่างหรือไม่ สิ่งนี้จะถูกละเว้นอย่างเงียบ ๆ เมื่อใช้การเติมแท็บและใช้เป็นพารามิเตอร์
2. ลองใช้สคริปต์ / โปรแกรมอื่นในไดเรกทอรี
3. ลอง strace-ing เชลล์ที่พยายามเรียกใช้งานสคริปต์และดูว่ามีการหยุดทำงาน

ฉันมีปัญหาเดียวกันทั้งหมดและไม่สามารถหาคำตอบได้เนื่องจากปัญหาของโปสเตอร์ต้นฉบับแก้ไขได้เอง แต่สิ่งนี้ไม่ได้ผลสำหรับฉันและในที่สุดฉันก็สามารถติดตามปัญหาได้ ดังนั้นฉันเพิ่มต่อไปนี้เป็นคำตอบสำหรับโพสต์ต้นฉบับ

อาการที่ฉันต้องเผชิญมีดังต่อไปนี้ มีสคริปต์ (myscript.pl) ในไดเรกทอรี / my / home ตอนนี้พยายามเรียกใช้:

> /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/fstabการอนุญาตจากผู้บริหารหายไป!

/dev/sda1    /my     /ext4      rw,user

แทน

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

แก้ไขปัญหานี้โดยการเปลี่ยน/etc/fstabและประกอบใหม่:

mount -v -o remount /my

วิธีนี้ช่วยแก้ไขปัญหาได้อย่างสมบูรณ์ ฉันเดาว่าสิ่งที่คล้ายกันอาจเกิดขึ้นกับปัญหาของผู้โพสต์ดั้งเดิมยกเว้นว่ามีปัญหาการอนุญาตเป็นระยะ ๆ (เช่นมีการเปลี่ยนแปลงชั่วคราวที่อาจได้รับการแก้ไขด้วยรีบูตหากเกิดขึ้น)

ไม่ใช่คำตอบเต็มรูปแบบ แต่ต้องการรายงานประสบการณ์ของฉันเนื่องจากฉันมีปัญหาเดียวกันกับผู้ถามและคิดว่ามันอาจช่วยให้ผู้ใช้ในอนาคตประสบปัญหาการคลั่งไคล้เช่นเดียวกัน ฉันสามารถที่ไฟล์และเห็นมันในเส้นทางของฉันและแม้กระทั่งรันโดยให้เส้นทางเต็ม แต่ไม่สามารถดำเนินการเป็นอย่างอื่น อย่างไรก็ตามในกรณีของฉันมันเกิดขึ้นภายใน sub-shell เท่านั้น (เช่นเมื่อถูกเรียกใช้งานจากสคริปต์ในกรณีนี้มี sub-shell ที่ซ้อนกันสองสามตัว) ฉันสามารถเรียกใช้จากบรรทัดคำสั่งได้ดี

ก่อนคำสั่งในสคริปต์ที่ซ้อนกันฉันพิมพ์คำสั่งเช่น echo $ (ซึ่งคำสั่งของฉัน)

mycommand: / home / me / bin / mycommand

จากนั้นฉันจะพยายามเรียกใช้จากสคริปต์หลัก:

/ home / me / bin / some_parent_script [72]: mycommand: ไม่พบ [ไม่พบไฟล์หรือไดเรกทอรี]

ฉันไม่สามารถวิเคราะห์สาเหตุของปัญหาได้เช่นเดียวกับผู้ถาม PATH ของฉันดูถูกต้องมันสามารถใช้งานได้และแฮชไม่ได้เปิดเผยรายการคำสั่งก่อนหน้าของฉัน วันรุ่งขึ้นเมื่อฉันเข้าสู่ระบบทุกอย่างทำงานได้อย่างน่าอัศจรรย์อีกครั้ง ตอนนี้ฉันจะทราบที่นี่ว่ามีปัญหาของระบบที่ทราบซึ่งเกิดขึ้นก่อนที่ฉันจะเห็นปัญหานี้ซึ่งการติดตั้งถูกประกอบใหม่ อาจเป็นเบาะแสหรือไม่

หากฉันไม่มีไฟล์บันทึกหลังจากที่ไฟล์บันทึกแสดงว่าสิ่งนี้เกิดขึ้นฉันจะไม่เชื่อว่ามันจะเป็นไปได้! ขอบคุณผู้ถามฉันไม่รู้สึกบ้าอีกต่อไป!

PS ฉันไม่คิดว่าผู้ใช้ 226160 มีปัญหาเดียวกันกับนักข่าว แต่มันฟังดูเกี่ยวข้องและให้ความเชื่อถือกับทฤษฎีเมานต์