উত্তর:
সম্ভবত কার্নেলটি সহজ রাখার জন্য। আমি মনে করি না কোনও কার্যনির্বাহী খুঁজে পেতে কার্নেল কখনও আপনার পথ অনুসন্ধান করে। এটি সি লাইব্রেরি দ্বারা পরিচালিত। #!প্রসেসিং কার্নেলে করা হয়, যা স্ট্যান্ডার্ড সি লাইব্রেরি ব্যবহার করে না।
এছাড়াও, আমি মনে করি না যে আপনার পাথ কী তা কার্নেলের কোনও ধারণা আছে। $PATHপরিবেশগত পরিবর্তনশীল, এবং কেবলমাত্র প্রক্রিয়াগুলির একটি পরিবেশ থাকে। কার্নেল দেয় না। আমি মনে করি এটি কার্য সম্পাদনকারী প্রক্রিয়াটির পরিবেশে অ্যাক্সেস করতে পারে তবে আমি মনে করি না কার্নেলটিতে বর্তমানে এমন কোনও কিছু যেমন পরিবেশের ভেরিয়েবলগুলি অ্যাক্সেস করে।
আপনি PATHব্যবহার করে শব্দার্থ আবিষ্কার করতে পারেন env, সুতরাং:
#!/usr/bin/env ruby
আপনি চাইলে শব্দার্থবিজ্ঞান রয়েছে
#!ruby
যে কারণে নির্ভর করে PATHভাল অনুশীলন হিসাবে বিবেচনা করা হয় না তা হ'ল স্ক্রিপ্টটি প্যাথ পরিবেশ পরিবর্তনশীলের বিষয়বস্তু সম্পর্কে কোনও অনুমান করতে পারে না, যেখানে বাইনারিগুলির "অনুক্রম নির্ভর নির্ভরতা মডেল" ভেঙে দেয়
/bin বুট সময়ে প্রয়োজনীয় এক্সিকিউটেবল রয়েছে;/usr/bin ওএস ইনস্টলেশন দ্বারা ব্যবহৃত অন্যান্য এক্সিকিউটেবল রয়েছে;/usr/local/bin সিস্টেম প্রশাসক দ্বারা ইনস্টল করা এক্সিকিউটেবল রয়েছে যা বেস ওএসের অংশ নয়।~/bin ব্যবহারকারীর নিজস্ব নির্বাহযোগ্য রয়েছে।প্রতিটি স্তরের পরে ধারাবাহিকভাবে বাইনারিগুলির অস্তিত্ব অনুমান করা উচিত নয়, যা আরও "অ্যাপ্লিকেশন" তবে এর আগে বাইনারিগুলির উপর নির্ভর করতে পারে যা আরও "ভিত্তি" হয়। এবং PATH ভেরিয়েবল প্রয়োগযোগ্য থেকে মৌলিক দিকে চালিত হয় যা উপরের প্রাকৃতিক নির্ভরতার বিপরীত দিক।
সমস্যাটি চিত্রিত করার জন্য, নিজেকে জিজ্ঞাসা করুন যে কোনও স্ক্রিপ্ট যদি কোনও স্ক্রিপ্টে রুবিকে ~/binডাকে তবে কী ঘটে /usr/local/bin? সেই স্ক্রিপ্টটি ওএস ইনস্টলড সংস্করণে নির্ভর করা উচিত /usr/bin/ruby, বা ব্যক্তিগত কপির উপর ব্যবহারকারীর কাছে ঘটেছিল ~/bin/ruby? PATHপূর্ববর্তীটি ~/bin/rubyদেওয়ার পথে বেকিংয়ের সময় অনুসন্ধানটি পরবর্তীকালের (সম্ভবত একটি ভাঙা প্রতীকী লিঙ্ক) সাথে সম্পর্কিত অভাবিত শব্দার্থকে #!দেয়।
সত্যিই অন্য কোনও প্ল্যাটফর্ম-স্বতন্ত্র "অপারেটিং সিস্টেম নেই ... একটি নিবন্ধিত কমান্ডের পথ সম্পর্কিত তথ্য", তাই সবচেয়ে সহজ বিষয়টি হল যে পথটিতে সরবরাহ করা হচ্ছে তাতে জোর দেওয়া #!।
আমি বিশ্বাস করি এটি তাই আপনার প্রয়োজন বা চাইলে আপনি বিকল্প বিকল্প ব্যাখ্যা করতে পারেন। উদাহরণ স্বরূপ:
#!/home/user/myrubyinterpreter
শেল স্ক্রিপ্টগুলির সাথে প্রায়শই দেখা যায়:
#!/bin/bash
#!/bin/sh
#!/bin/dash
#!/bin/csh
থেকে ক্লাসিক শেল স্ক্রিপ্টিং বই:
শেল স্ক্রিপ্টগুলি সাধারণত শুরু হয়
#! /bin/sh। যদি আপনার/bin/shপসিক্স অনুগত না হয় তবে একটি পসিক্স-সম্মতিযুক্ত শেলের পথটি ব্যবহার করুন । এখানে নজর রাখার জন্য কয়েকটি নিম্ন-স্তরের "গ্যাটাচস" রয়েছে:
- আপনাকে দোভাষীর চালানোর জন্য পুরো পথের নামটি জানতে হবে। এটি ক্রস-বিক্রেতার বহনযোগ্যতা রোধ করতে পারে, যেহেতু বিভিন্ন বিক্রেতারা বিভিন্ন জায়গায় জিনিস রাখে (যেমন,
/bin/awkবনাম/usr/bin/awk)।
অন্যান্য কারণ রয়েছে, তবে সুরক্ষা দৃষ্টিকোণ থেকে আমি কখনই কোনও স্ক্রিপ্ট চাইব না যে সঠিক পথটি সম্পর্কে অনুমান করা যায়। যদি এটি ভুল হয় এবং এটি ভুল শেল বা দোভাষী চালায়? এটি একটি দূষিত ব্যবহারকারীর দ্বারা beenোকানো হয়েছে? অথবা যদি এটি কোনও নির্দিষ্ট শেলের উপর নির্ভর করে এবং যদি ভুল শেল ব্যবহার করা হয় তবে ক্রাশ হবে?
ব্যবহারকারীরা তাদের পথটি নিয়ে গোলমাল করতে পারে এবং স্টাফ ভেঙে ফেলতে পারে - ব্যবহারকারীর উপর বিশ্বাস করবেন না :-) আমি প্রচুর আক্রমণ চালিয়েছি যা ব্যবহারকারীর উপর নির্ভর করে তাদের পথ দিয়ে ভুল কাজ করে - সাধারণত ভুল ক্রমে জিনিস পেয়ে যায় - তাই আমি বিকৃত করতে পারি একটি সাধারণ স্ক্রিপ্ট কল।
হ্যাঁ, আমি জানি আপনি যদি স্ক্রিপ্টটি নিজে লিখে থাকেন তবে আপনি সঠিকভাবে দাবি করতে পারেন যে আপনি নিজের পথটি সাজিয়েছেন, কিন্তু কোনও দোভাষী সে সিদ্ধান্ত নিতে পারবেন না।
$PATH। । উন্নত সুযোগ সুবিধাগুলি ছাড়াই যদি LD_PRELOADব্যবহার করা হয়? পিএস ডাউনভোটেড কারণ সুরক্ষা সম্পর্কে একটি মিথ্যা সতর্কতা দেওয়া সুরক্ষার পক্ষে ক্ষতিকারক।
PATHঅ্যাটাক ভেক্টর এমন কোনও মামলার উদাহরণ দিতে পারেন , এবং আরও অনেক আক্রমণ আক্রমণকারী নেই যে পুরো পদ্ধতির পুনর্বিবেচনা করা উচিত?
ruby, কিন্তু যে নির্দিষ্ট থেকে থামবে না/home/user/myrubyinterpreterযদি তুমি চাও