PATH অনুসন্ধানে প্রতিলিঙ্কগুলি অন্তর্ভুক্ত রয়েছে?


9

পসিক্স শেল স্ট্যান্ডার্ড এই সাইটে বলে

http://pubs.opengroup.org/onlinepubs/9699919799/

শেলগুলি কীভাবে PATHএক্সিকিউটেবলের সন্ধানের জন্য ব্যবহার করে:

"তালিকাটি শুরু থেকে শেষ অবধি অনুসন্ধান করা হবে, নির্দিষ্ট নাম এবং যথাযথ এক্সিকিউশন অনুমতি সহ একটি এক্সিকিউটেবল ফাইল না পাওয়া পর্যন্ত প্রতিটি উপসর্গের সাথে ফাইলের নাম প্রয়োগ করা হবে।"

ঠিক আছে, বাস্তব পসিক্স বাস্তবায়নে এটি কীভাবে এটি প্রদর্শিত হচ্ছে তা নয়:

man which বলেছেন:

"বর্তমান পরিবেশে যে ফাইলগুলি (বা লিঙ্কগুলি) কার্যকর করা হবে তার পাথের নামগুলি ফেরত দেয়, যদি তার যুক্তিগুলি কঠোরভাবে পসিক্স-কনফর্মেন্ট শেল-এ কমান্ড হিসাবে দেওয়া হত It যুক্তিগুলি It এটি প্রতীকী লিঙ্কগুলি অনুসরণ করে না ""

ঠিক আছে, আসুন এই পরিস্থিতিটি দেখুন:

$ pwd /home/mark

$ echo $PATH /home/mark/bin:...

$ ls -l bin/foobar
lrwxrwxrwx 1 mark mark 18 Dec 12 22:51 bin/foobar -> /home/mark/foobar1
$ touch foobar1
$ which foobar
$ chmod a+x foobar1
$ which foobar
/home/mark/bin/foobar

ঠিক আছে, এখানে PATHসঠিক নামের সাথে একটি প্রতীকী লিঙ্ক রয়েছে এবং এটি lsসম্পাদনযোগ্য বলে প্রতিবেদন করা হয়েছে।

which এটি মোটেও দেখায় না, তবে এটি কী দেখায় তাতে কেবল আগ্রহী।

এটি উভয়টি man whichস্পষ্টতই বলেছে যে এটি প্রতীকী লিঙ্কগুলি অনুসরণ করে না (এবং প্রকৃতপক্ষে আমরা এটি দেখতে পাই না, কারণ which foobarএটি মুদ্রণ করে না foobar1), এবং উপরে যে পসিক্স শেল ডকুমেন্টেশন উপরে উল্লিখিত হয়েছে তা কখনই PATHঅ্যালগরিদমে নিম্নলিখিত চিহ্নগুলি কখনও উল্লেখ করে না ।

সুতরাং, whichএবং বিদ্যমান শাঁসগুলি ভুল, বা আমি কী ডকুমেন্টেশন বুঝতে পারছি না?

স্পষ্ট করা:

আমি জানি এবং বিদ্যমান আচরণটি ব্যাখ্যা করতে পারি। আমার প্রশ্ন "এটি কীভাবে কাজ করে?" নয়। আমি জানি যে.

আমার প্রশ্নটি ডকুমেন্টেশন সম্পর্কে: আমি যে দস্তাবেজগুলি উদ্ধৃত করেছি তা অনুসরণ করার ক্ষেত্রে আমার ভুল কোথায়। নাকি ডকুমেন্টেশন ভুল?

প্রচার: আমি কেন যত্ন করব?

ঠিক আছে, আমি একজন প্রয়োগকারী। বিভিন্ন প্রয়োগকারীদের বিভিন্ন প্রয়োজনীয়তা থাকে। আমার জন্য, প্রয়োজনটি হ'ল বর্তমান পসিএক্স স্ট্যান্ডার্ডের শব্দটি অবশ্যই অনুসরণ করা উচিত (বা, আরও স্পষ্টভাবে, এটি সর্বোত্তম হতে পারে, কারণ, মানটি নিজেই কিছুটা বগিযুক্ত)। এটি Godশ্বরের শব্দ ছিল যেমন।

এখন, স্ট্যান্ডার্ড শব্দটি বেশ পরিষ্কার - নিম্নলিখিত চিহ্নগুলি উল্লেখ করা হয়নি, যেখানে অন্যান্য অনেক জায়গায় এটি করা উচিত যেখানে এটি উল্লেখ করা হয়েছে। সুতরাং এই ক্ষেত্রে, না।

তবে, আমি সর্বদা ডাবল চেক করি কীভাবে dashএবং কী bashআচরণ করে, তা নিশ্চিত করার জন্য। অবশ্যই, এখানেও একটি সামান্য সমস্যা রয়েছে, dashযদিও এটি পসিক্স হিসাবে বিল করা হয়েছে, পসিক্সের সাথে সামঞ্জস্য সহ প্রচুর ছোট ছোট বাগ রয়েছে। bash, আমি পসিক্সের সাথে এখনও কোনও বাগ খুঁজে পাইনি, কিন্তু ... ব্যাশ আসলে পসিক্স নয়, এটি এর চেয়ে অনেক বেশি।

তাই সেখানে যদি আপনি এটি আছে। এজন্য আমি যত্ন করি।


আপনি বুঝতে পারবেন না: যা ফাইলগুলিতে সিমলিঙ্কগুলি অনুসরণ করে না । $PATHsymlinks থাকতে পারে। ব্যবহার করে দেখুন which sh
ইপোর সিরসর

ঠিক আছে তবে, আমার ক্ষেত্রে $PATHকোনও প্রতিলিপি নেই।
ব্যবহারকারী322908

প্রায় সমস্ত পরিস্থিতিতে, স্বাক্ষরিতভাবে স্বতন্ত্রভাবে অনুসরণ করা হয়। যেসব ক্ষেত্রে এগুলি হয় না সেগুলি সাধারণত স্পষ্টভাবে উল্লেখ করা হয় (যেমন সিস্টেম কলগুলির মতো lstat(2)), তাদের অনুসরণ করা সাধারণত বলা হয় না। উদাহরণস্বরূপ, open(2)এর আচরণ সম্পর্কে কথা বলার সময় কেবল বর্ণ বর্ণের উল্লেখ রয়েছে O_CREAT | O_EXCL। লক্ষ্য ফাইলটি খোলার কথা বলা দরকার নেই need
বর্মার

উত্তর:


10

সিমলিংকের অনুমতিগুলি অপ্রাসঙ্গিক। আপনি চেষ্টা করেও এগুলি পরিবর্তন করতে পারবেন না।

কোন বিষয়টি অন্তর্নিহিত ফাইলের অনুমতি।

আপনার PATH ডিরেক্টরিতে এক্সিকিউটেবলের সাথে সিমলিংক অন্তর্ভুক্ত রাখা ভাল। প্রকৃতপক্ষে, সম্ভবত আপনার PATH- তে অনেক এক্সিকিউটেবলগুলি প্রতীকযুক্ত। উদাহরণস্বরূপ, ডেবিয়ান / উবুন্টু-জাতীয় সিস্টেমে:

$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Jan 23  2017 /bin/sh -> dash

নথিপত্র

থেকে man chmod:

chmod কখনই প্রতীকী লিঙ্কের অনুমতি পরিবর্তন করে না; chmod সিস্টেম কল তাদের অনুমতিগুলি পরিবর্তন করতে পারে না। প্রতীকী লিঙ্কগুলির অনুমতিগুলি কখনই ব্যবহার করা হয় না বলে এটি কোনও সমস্যা নয় তবে, কমান্ড লাইনে তালিকাভুক্ত প্রতিটি প্রতীকী লিঙ্কের জন্য, chmod পয়েন্ট-টু ফাইলের অনুমতিগুলি পরিবর্তন করে। বিপরীতে, chmod পুনরাবৃত্ত ডিরেক্টরি ডিরেক্টরি ট্র্যাভারসাল সময় সম্মুখীন প্রতীকী লিঙ্ক উপেক্ষা করে। [সামনে জোর দাও.]

উদাহরণ

-xকোনও ফাইল নির্বাহযোগ্য কিনা তা নির্ধারণের জন্য শেলের একটি পরীক্ষা রয়েছে । এর চেষ্টা করুন:

$ ls -l
total 0
lrwxrwxrwx 1 john1024 john1024 7 Dec 12 23:36 foo -> foobar1
-rw-rw---- 1 john1024 john1024 0 Dec 12 23:36 foobar1
$ [ -x foo ] && echo foo is executable
$ chmod +x foobar1
$ [ -x foo ] && echo foo is executable
foo is executable

সুতরাং, যেমনটি আপনি পেয়েছেন ঠিক whichতেমনই শেলটি অন্তর্ভুক্ত ফাইলটি সম্পাদনযোগ্য না হলে একটি সফটলিঙ্ক নির্বাহযোগ্য হিসাবে বিবেচনা করে না।

কীভাবে কাজ করে

একটি ডেবিয়ান সিস্টেমে whichশেল স্ক্রিপ্ট। কোডের সম্পর্কিত বিভাগটি হ'ল:

 case $PROGRAM in
  */*)
   if [ -f "$PROGRAM" ] && [ -x "$PROGRAM" ]; then
    puts "$PROGRAM"
    RET=0
   fi
   ;;
  *)
   for ELEMENT in $PATH; do
    if [ -z "$ELEMENT" ]; then
     ELEMENT=.
    fi
    if [ -f "$ELEMENT/$PROGRAM" ] && [ -x "$ELEMENT/$PROGRAM" ]; then
     puts "$ELEMENT/$PROGRAM"
     RET=0
     [ "$ALLMATCHES" -eq 1 ] || break
    fi
   done
   ;;
 esac

আপনি দেখতে পাচ্ছেন, এটি -xপরীক্ষাটি ব্যবহার করে এটি নির্ধারণ করে যে কোনও ফাইল কার্যকর হয়।

POSIX -xপরীক্ষা নীচে হিসাবে নির্দিষ্ট করে:

-x পাথনাম
সত্য যদি প্যাথনামটি কোনও ফাইলের জন্য কোনও ডিরেক্টরি ডিরেক্টরি এন্ট্রি থেকে সমাধান করে যার জন্য ফাইলটি পড়ার অনুমতি দেওয়া হয় (বা এটি ডিরেক্টরি হয় তবে এটি অনুসন্ধান করুন) ফাইল রিড, রাইটিং এবং ক্রিয়েশনে সংজ্ঞায়িত করা হবে। মিথ্যা যদি পথের নামটি সমাধান করা যায় না, বা যদি পথের নামটি কোনও ফাইলের জন্য একটি ডিরেক্টরি ডিরেক্টরি প্রবেশের সমাধান করে তবে যার জন্য ফাইলটি কার্যকর করার (বা অনুসন্ধান) অনুমতি দেওয়া হবে না। [সামনে জোর দাও.]

সুতরাং, পসইমেক্স পরীক্ষা করে যে প্যাথনামটি কী সমাধান করে। অন্য কথায়, এটি প্রতীক গ্রহণ করে।

পজিক এক্সিকিউট ফাংশন

POSIX Exec ফাংশন symlinks অনুসরণ করে। সিমলিংকগুলি বিজ্ঞপ্তিযুক্ত বা খুব গভীর, যেমন:

[ELOOP]
পথ বা ফাইল আর্গুমেন্টের সমাধানের সময় প্রতীকী লিঙ্কগুলিতে একটি লুপ উপস্থিত রয়েছে।

[ELOOP]
পথ বা ফাইল আর্গুমেন্টের সমাধানের সময় {SYMLOOP_MAX than এর চেয়েও বেশি প্রতীকী লিঙ্কগুলির মুখোমুখি হয়েছিল।
[ENAMETOOLONG]
পাথ আর্গুমেন্টের সমাধানের ক্ষেত্রে একটি প্রতীকী লিঙ্কের মুখোমুখি হওয়ার ফলে, পরিবর্তিত পথের নামের স্ট্রিংয়ের দৈর্ঘ্য {PATH_MAX exceed অতিক্রম করেছে}


আপনার উত্তরে আপনি যা লিখেছিলেন তা আমি জানি। আমি জানি জিনিসগুলি কীভাবে "কাজ করে"। এটা আমার প্রশ্ন নয়। আমার প্রশ্ন ডকুমেন্টেশন সম্পর্কে। আমি যেখানে ডকুমেন্টেশন বুঝতে পারি না সেখানে আমাকে নির্দেশ করুন অথবা আমাকে বলুন যে ডকুমেন্টেশনটি ভুল।
ব্যবহারকারী322908

@ user322908 বেশিরভাগ সিস্টেমে whichশেল স্ক্রিপ্ট। সুতরাং, এটি সম্ভবত -xআমি প্রদর্শিত পরীক্ষাটি ব্যবহার করছি। পসিক্সের মতে, -xকোনও ফাইল এক্সিকিউটেবলের কাছে "সমাধান" করে কিনা পরীক্ষা করে। আপনি যদি কিছু অন্যরকম দেখছেন তবে আপনি কোথায় খুঁজছেন?
1024

আপনাকে ধন্যবাদ এবং আমি এ জাতীয় ব্যথা হওয়ার জন্য দুঃখিত ... আমি বুঝতে পারি যে আমার প্রশ্নটি 99% প্রশ্নের চেয়ে আলাদা, সুতরাং আমি কী করছি তা বুঝতে অসুবিধা হয়। আবার, "কীভাবে" whichকাজ করে, বা তা হোক -xবা অন্য কিছুতে আমি আগ্রহী নই । আমি জানতে আগ্রহী যে আমি কোথায় উদ্ধৃত ডকুমেন্টেশন সঠিকভাবে অনুসরণ করছি না।
ব্যবহারকারী322908

4
@ user322908 দ্য POSIX execফাংশন symlinks অনুসরণ করে। এটি বেশ পরিষ্কার করে মনে হচ্ছে যে সিমলিঙ্কযুক্ত ফাইলগুলি পসিক্সের অধীনে এক্সিকিউটেবল হতে পারে।
1024

2
আমি উবুন্টু 17.10 man which কেও যাচাই করেছিলাম যা বলে যে "এটি পথের নামকে প্রথাগত করে না" " এর অর্থ এই নয় যে এটি লিঙ্কগুলি অনুসরণ করে না। এর অর্থ কেবলমাত্র, যেমন আপনি পর্যবেক্ষণ করেছেন, এটি নামগুলি "ক্যানোনিকালাইজড" করে না।
1024

3

সেক্ষেত্রে চূড়ান্ত পথে চূড়ান্তভাবে চিহ্ন ছাড়াই প্রতীকগুলি স্বচ্ছভাবে অনুসরণ করা হয় । অন্য কথায়, একটি সিমিলিংক whichকিনা তা নিয়ে চিন্তা করে /home/mark/binনা। এটি কীসের জন্য যত্নশীল তা হ'ল ফাইলটি /home/mark/bin/foobarবিদ্যমান কিনা । এটা তোলে দরকার নেই পাথ বরাবর নিজে চেপ্টা symlinks করুন - অপারেটিং সিস্টেম তার নিজের উপর যে শুধু জরিমানা করতে পারেন।

এবং প্রকৃতপক্ষে, যখন whichফাইলের তথ্য সম্পর্কে জিজ্ঞাসা করা হয় /home/mark/bin/foobar, তখন ওএস বিজ্ঞপ্তিগুলি /home/mark/binএকটি সিমিলিংক হয়, এটি অনুসরণ করে এবং সফলভাবে foobarলক্ষ্য ডিরেক্টরিতে সন্ধান করে।

প্রোগ্রামটি ব্যবহার না করা open(…, O_NOFOLLOW)বা fstatat(…, AT_SYMLINK_NOFOLLOW)ফাইল অ্যাক্সেস না করা পর্যন্ত এটি ডিফল্ট আচরণ ।

[মন্তব্যগুলিতে একত্রীকরণ]

আপনি বলতে করেন যে শেল ইউটিলিটি একটি কেস বাই কেস ভিত্তিতে এটা করতে, এটি কার্নেল syscalls সঙ্গে একই নয়: যে সব ফাইল-সংশ্লিষ্ট কল না , ডিফল্ট অনুসারে symlinks অনুসরণ যদি না "nofollow" ফ্ল্যাগ দেওয়া হয়। (এমনকি lstat সর্বশেষ ব্যতীত সমস্ত পাথ উপাদানগুলিতে প্রতীকগুলি অনুসরণ করে))

যখন স্পেসিফিকেশন স্পষ্টভাবে সিমলিঙ্কগুলির সাথে কী করবেন তা উল্লেখ না করে, এটি বোঝায় যে ডিফল্ট আচরণ ব্যবহার করা হবে। অর্থাৎ একটি শেল পথ অ্যালগরিদম neithers সমাধানে symlinks ম্যানুয়ালি নিম্নলিখিত কিংবা এটা স্পষ্টভাবে আউট ওএস একই করছেন অপ্ট নেই। (এটি কেবল এক্সিকিউটেবল নামের সাথে প্রতিটি $ PATH উপাদানকে সম্মিলিত করে))

যখন (1) ম্যানুয়াল পৃষ্ঠাটি বলে যে এটি প্রতিলিঙ্কগুলি অনুসরণ করে না, এর অর্থ কয়েকটি বিষয় হতে পারে তবে জিএনইউ কোর্টিলস সংস্করণটি এটিকে এভাবে বর্ণনা করে:

যার মধ্যে দুটি সমতুল্য ডিরেক্টরি পৃথক হিসাবে বিবেচনা করবে যখন তাদের মধ্যে একটিতে একটি প্রতীকী লিঙ্কযুক্ত একটি পথ রয়েছে।

এটি সুযোগের তুলনায় অনেক সংকীর্ণ - এর অর্থ হ'ল ডুপ্লিকেটগুলি আগাছা থেকে বের করার জন্য সমস্ত পাথ ম্যানুয়ালি প্রবর্তন whichকরার চেষ্টা করবে না , তবে এটি বোঝায় না যে সরঞ্জামটি সাধারণভাবে ওএসের দ্বারা অনুসরণ করা সিমলিংকটি বেছে নেবে। উদাহরণস্বরূপ, যদি এটির একটি সিমিলিংক হয় তবে দৌড়ানো দুটি এবং উভয়ই ফিরে আসবে/bin/usr/binwhich -a sh /bin/sh/usr/bin/sh


হ্যাঁ আপনাকে ধন্যবাদ, আমি এই সমস্ত জানি। আমার প্রশ্ন জিনিসগুলি কীভাবে "কাজ করে" তা নয়। আমি জানি তারা কীভাবে কাজ করে। এটা আমার বক্তব্য নয়। আমার বক্তব্য ডকুমেন্টেশন সম্পর্কে। আমি কোথায় ডকুমেন্টেশন ভুলভাবে অনুসরণ করছি। বা ডকুমেন্টেশন ভুল।
user322908

2
আপনি ডকুমেন্টেশনটি ভুলভাবে বুঝতে পেরেছেন - যদি এটি নিম্নলিখিত সিমলিংকের উল্লেখ না করে তবে এর অর্থ এটি ম্যানুয়ালি প্রতিলিঙ্কগুলি সমাধান করে না , তবে নিয়মিত ওএসের আচরণ এখনও প্রয়োগ হয় lies জিএনইউ whichম্যানুয়াল পৃষ্ঠাটি এটিকে অন্যভাবে বলেছে: "এটি দুটি সমতুল্য ডিরেক্টরিকে আলাদা হিসাবে বিবেচনা করবে যখন তাদের মধ্যে একটিতে একটি প্রতীকী লিঙ্কযুক্ত পথ রয়েছে" "
user1686

ঠিক আছে, এটি আরও ভাল আপনাকে ধন্যবাদ! আমি বোঝার চেষ্টা করছি ... তবে ... আমার ঘাড়ে ব্যথা হওয়ার জন্য ক্ষমা করুন: "নিয়মিত ওএস আচরণ" সর্বদা সুস্পষ্টভাবে প্রতিলিঙ্কগুলি অনুসরণ করা নয়। প্রচুর ইউটিলিটি রয়েছে যা না। এটি কেস-কেস-কেস ভিত্তিতে।
user322908

1
সমস্ত কার্নেল কল - chdir, ওপেন, chmod, এক্সিকিউট ... - আপনি AT_SYMLINK_NOFOLLOW বা অনুরূপ নির্দিষ্ট না করে পাথ এবং লেজের উভয় দিকেই প্রতীক অনুসরণ করবে । (lstat হ'ল একমাত্র যা লেজের দিকে প্রতীককে অবজ্ঞা করে না, তবে বাকি পথের জন্য এখনও তা করে)) সুতরাং ডিফল্ট আচরণটি প্রতিলিঙ্কগুলি অনুসরণ করা। উদাহরণস্বরূপ, যখন একটি শেল কল execve("/home/mark/bin/foobar", …)দেয় তখন এর ফলে সমস্ত সিমলিংক অনুসরণ করা হবে।
ব্যবহারকারী1686

ঠিক আছে আমি মনে করি আমি execveযুক্তিটি কিনছি , আসলে আমার বাস্তবায়নে এটি execl()একই জিনিস। আপনি যদি আপনার উত্তরে এটি অন্তর্ভুক্ত করেন তবে আমি গ্রহণ করব।
ব্যবহারকারী322908

1

শেলটি তার ডকুমেন্টেশনের সাথে সম্মতি দেয় যাতে এটি পথের নাম রেজোলিউশনের নিয়ম অনুসরণ করে। whichএর ডকুমেন্টেশন অনুসারে। দুজন কিছুটা আলাদা জিনিস করেন।

এর আউটপুট whichহ'ল লিঙ্কের ফাইলের নাম এবং পথ, সিমলিংকটি কী নির্দেশ করে তার পথে নয়। এটি ম্যান পৃষ্ঠাতে বানান।

যখন কোনও কমান্ড কার্যকর করা হয়, লিঙ্কটি একই অংশে 4.13 প্যাথনাম রেজোলিউশন অনুযায়ী "অনুসরণ করা" হবে । কোনও ফাইল কার্যকর করার জন্য সম্পর্কিত ধারাটি হ'ল:

অন্য সমস্ত ক্ষেত্রে সিস্টেমটি প্রতীকী লিঙ্কের বিষয়বস্তু সহ বাকী পথের নামটি উপসর্গ করবে, যদি প্রতীকী লিঙ্কের বিষয়বস্তু খালি স্ট্রিং থাকে তবে পাথনাম রেজোলিউশনটি একটি [এনওএনটি রিপোর্ট করার ফাংশন সহ ব্যর্থ হবে) ] ত্রুটি এবং ইউটিলিটিগুলি একটি সমতুল্য ডায়াগনস্টিক বার্তা লেখার জন্য, বা প্রতীকী লিঙ্কযুক্ত ডিরেক্টরিটির পথের নামটি প্রতীকী লিঙ্কের বিষয়বস্তুর জায়গায় ব্যবহার করা হবে। যদি প্রতীকী লিঙ্কের বিষয়বস্তুগুলি কেবলমাত্র অক্ষর দ্বারা গঠিত থাকে, তবে অবশিষ্ট পথনামের সমস্ত নেতৃস্থানীয় অক্ষরগুলি ফলাফলের সম্মিলিত পথের নাম থেকে বাদ দেওয়া হবে, কেবল প্রতীকী লিঙ্কের বিষয়বস্তু থেকে শীর্ষস্থানীয় অক্ষরগুলি রেখে। যে ক্ষেত্রে প্রিফিক্সিং ঘটে, যদি সম্মিলিত দৈর্ঘ্য {PATH_MAX ex অতিক্রম করে এবং বাস্তবায়ন এটিকে একটি ত্রুটি হিসাবে বিবেচনা করে, একটি [ENAMETOOLONG] ত্রুটি এবং সমতুল্য ডায়াগনস্টিক বার্তা লেখার জন্য প্রয়োজনীয়তাগুলি প্রতিবেদন করার ফাংশনগুলির সাথে পাথনাম রেজোলিউশন ব্যর্থ হবে। অন্যথায়, সমাধান করা পথের নামটি সদ্য তৈরি হওয়া পথের নামটি হবে। যদি ফলাফলগত পাথের নামটি একটি দিয়ে শুরু না হয় তবে পাথনামের প্রথম ফাইলনামের পূর্বসূরীটি প্রতীকী লিঙ্কযুক্ত ডিরেক্টরি হিসাবে নেওয়া হয়।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.