বাশের মধ্যে "।" এবং "উত্স" এর মধ্যে কোনও পার্থক্য আছে কি?

Question

আমি "" এর মধ্যে পার্থক্যটি খুঁজছিলাম। এবং "উত্স" বিল্টিন কমান্ড এবং কয়েকটি উত্স (উদাহরণস্বরূপ, এই আলোচনায়, এবং ব্যাশ ম্যানপেজ) সুপারিশ করে যে এগুলি কেবল একই।

যাইহোক, পরিবেশের ভেরিয়েবলগুলির সাথে একটি সমস্যা অনুসরণ করে, আমি একটি পরীক্ষা চালিয়েছি। আমি একটি ফাইল তৈরি করেছি testenv.shযাতে এতে রয়েছে:

#!/bin/bash
echo $MY_VAR

কমান্ড প্রম্পটে, আমি নিম্নলিখিতগুলি সম্পাদন করেছি:

> chmod +x testenv.sh
> MY_VAR=12345
> ./testenv.sh

> source testenv.sh
12345
> MY_VAR=12345 ./testenv.sh
12345

[নোট করুন যে 1 ম ফর্মটি একটি খালি স্ট্রিং ফিরিয়ে দিয়েছে]

সুতরাং, এই সামান্য পরীক্ষা প্রস্তাব দেওয়া যে হয় সব পরে একটি পার্থক্য, যেখানে "উৎস" কমান্ড জন্য, সন্তানের পরিবেশ উত্তরাধিকারী পিতা বা মাতা এক, যেখানে থেকে সব ভেরিয়েবল "।" এটা না.

আমি কি কিছু অনুপস্থিত, কিংবা এই একটি অনথিভুক্ত / এর অসমর্থিত বৈশিষ্ট্য হয় ব্যাশ ?

[জিএনইউ বাশ, সংস্করণ 4.1.5 (1) -রিলিজ (x86_64-pc-linux-gnu)]

Answer 1

সংক্ষিপ্ত উত্তর

আপনার প্রশ্নে, দ্বিতীয় কমান্ড .শেল বিল্টিন বা বিল্টিন না ব্যবহার করে source। পরিবর্তে, আপনি অন্য কোনও এক্সিকিউটেবল ফাইলের সাথে যেমন নাম দিয়ে অনুরোধ করে প্রকৃতপক্ষে একটি পৃথক শেলের মধ্যে স্ক্রিপ্টটি চালাচ্ছেন । এটি এটিকে একটি পৃথক ভেরিয়েবলের সেট দেয় (যদিও আপনি যদি তার প্যারেন্ট শেলটিতে কোনও ভেরিয়েবল রফতানি করেন তবে এটি যে কোনও শিশু প্রক্রিয়ার জন্য পরিবেশগত পরিবর্তনশীল হবে , এবং তাই শিশু শেলের ভেরিয়েবলগুলিতে অন্তর্ভুক্ত করা হবে )। আপনি যদি /কোনও স্থানটিতে পরিবর্তন করেন , তবে এটি এটি .বিল্ট-ইন দিয়ে চালিত করবে , যা সমান source।

বর্ধিত ব্যাখ্যা

এটি হ'ল sourceবিল্ট-ইন শেলটির বাক্য গঠন , যা বর্তমান শেলের একটি স্ক্রিপ্টের বিষয়বস্তু সম্পাদন করে (এবং এটি বর্তমান শেলের ভেরিয়েবলগুলির সাহায্যে):

source testenv.sh

এটি .অন্তর্নির্মিত বাক্য গঠন যা এই একই কাজ করে source:

. testenv.sh

তবে, এই সিনট্যাক্সটি এক্সিকিউটেবল ফাইল হিসাবে স্ক্রিপ্টটি চালায়, এটি চালানোর জন্য একটি নতুন শেল চালু করে:

./testenv.sh

এটি .বিল্ট-ইন ব্যবহার করছে না। বরং .আপনি যে ফাইলটি চালাচ্ছেন তার পথে যাওয়ার অংশ। সাধারণভাবে বলতে গেলে, আপনি কোনও শেকলে কোনও এক্সিকিউটেবল ফাইল চালাতে পারবেন এমন নাম দিয়ে কমপক্ষে একটি /অক্ষর রয়েছে run বর্তমান ডিরেক্টরিতে একটি ফাইল চালনা করা, এটির আগে আগে করা ./সহজতম উপায়। বর্তমান ডিরেক্টরিটি আপনার PATHনা থাকলে আপনি কমান্ডটি দিয়ে স্ক্রিপ্টটি চালাতে পারবেন না testenv.sh। এটি হ'ল বর্তমান ডিরেক্টরিতে লোকজন দুর্ঘটনাক্রমে ফাইল চালানো থেকে বিরত রাখা যখন তারা যখন PATHপরিবেশের ভেরিয়েবলের তালিকাভুক্ত কোনও ডিরেক্টরিতে উপস্থিত কোনও সিস্টেম কমান্ড বা অন্য কোনও ফাইল কার্যকর করতে চায় ।

যেহেতু নাম দিয়ে কোনও ফাইল চালানো ( এটি sourceবা এর পরিবর্তে .) এটি একটি নতুন শেলের মধ্যে চালায়, এতে শেলের ভেরিয়েবলগুলির নিজস্ব সেট থাকবে। নতুন শেলটি কলিং প্রক্রিয়া থেকে পরিবেশের পরিবর্তনশীলগুলির উত্তরাধিকারী হয় (যা এই ক্ষেত্রে আপনার ইন্টারেক্টিভ শেল) এবং সেই পরিবেশের ভেরিয়েবলগুলি নতুন শেলের শেল ভেরিয়েবল হয়ে যায়। তবে নতুন শেলটিতে শেল ভেরিয়েবলটি পাঠানোর জন্য, নিম্নলিখিতগুলির মধ্যে একটি অবশ্যই হওয়া উচিত:

1. শেল ভেরিয়েবলটি রফতানি করা হয়েছে, যার ফলে এটি পরিবেশের পরিবর্তনশীল হতে পারে। exportএর জন্য অন্তর্নির্মিত শেলটি ব্যবহার করুন । আপনার উদাহরণে, আপনি ব্যবহার করতে পারেন export MY_VAR=12345সেটে এবং এক ধাপে পরিবর্তনশীল রপ্তানি, অথবা যদি এটি ইতিমধ্যেই সেট করা হয় আপনি কেবল ব্যবহার করতে পারেন export MY_VAR।

2. শেল ভেরিয়েবলটি আপনি যে কমান্ডটি চালাচ্ছেন তার জন্য স্পষ্টভাবে সেট এবং পাস করা হয়েছে, কারণ এটি কমান্ডটি চালিত হওয়ার সময়কালীন পরিবেশের পরিবর্তনশীল হতে পারে। এটি সাধারণত এটি সম্পাদন করে:

   MY_VAR=12345 ./testenv.sh

   যদি MY_VARএকটি শেল পরিবর্তনশীল করেছে যে রপ্তানি করা হয় নি হয়, আপনি এমনকি চালাতে পারেন testenv.shসঙ্গে MY_VARদ্বারা একটি এনভায়রনমেন্ট ভেরিয়েবল হিসাবে পাস নিজেই এটা সেটিং :

   MY_VAR="$MY_VAR" ./testenv.sh

./ স্ক্রিপ্টগুলির সিনট্যাক্সের জন্য কাজ করার জন্য একটি হ্যাশবাং লাইন প্রয়োজন (সঠিকভাবে)

উপায় দ্বারা, দয়া করে মনে রাখবেন, যখন আপনি নামে একটি এক্সিকিউটেবল উপরে হিসাবে (এবং সঙ্গে ডাকা .বা sourceশেল বিল্ট-ইন), কি প্রোগ্রাম শেল চালানোর জন্য এটা করা হয় ব্যবহার করা হয় না সাধারণত কি শেল তা থেকে চালাচ্ছেন দ্বারা নির্ধারিত । পরিবর্তে:

• বাইনারি ফাইলগুলির জন্য, কার্নেলটি নির্দিষ্ট ধরণের ফাইল চালানোর জন্য কনফিগার করা যেতে পারে। এটি "ম্যাজিক নম্বর" এর জন্য ফাইলের প্রথম দুটি বাইট পরীক্ষা করে যা এটি নির্দেশ করে যে এটি কোন ধরণের বাইনারি কার্যকর হতে পারে। এক্সিকিউটেবল বাইনারিগুলি এভাবে চালাতে সক্ষম হয়।

  এটি অবশ্যই অত্যন্ত গুরুত্বপূর্ণ, কারণ একটি স্ক্রিপ্ট শেল বা অন্যান্য দোভাষী ছাড়া চালানো যায় না, যা এক্সিকিউটেবল বাইনারি! এছাড়াও, অনেক কমান্ড এবং অ্যাপ্লিকেশনগুলি স্ক্রিপ্টগুলির পরিবর্তে বাইনারিগুলি সংকলিত হয়।

  ( #!এটি "ম্যাজিক নম্বর" এর পাঠ্য উপস্থাপনা যা কোনও পাঠ্য কার্যকর হতে পারে তা নির্দেশ করে))

• যে ফাইলগুলি শেল বা অন্য ব্যাখ্যামূলক ভাষায় চালিত হওয়ার কথা, তাদের জন্য প্রথম লাইনটি দেখতে পাওয়া যায়:

  #!/bin/sh

  /bin/shপ্রোগ্রামটি চালানোর উদ্দেশ্যে অন্যান্য শেল বা দোভাষীর সাথে প্রতিস্থাপন করা যেতে পারে। উদাহরণস্বরূপ, পাইথন প্রোগ্রামটি লাইন দিয়ে শুরু হতে পারে:

  #!/usr/bin/python

  এই রেখাগুলি হ্যাশবাং, শেবাং এবং অন্যান্য বেশ কয়েকটি অনুরূপ নাম বলে। এই فولডোক এন্ট্রিটি দেখুন , এই উইকিপিডিয়া নিবন্ধ এবং দোভাষী দ্বারা পড়া #! / বিন / শ দেখুন? আরও তথ্যের জন্য.

• যদি কোনও পাঠ্য ফাইল এক্সিকিউটেবল হিসাবে চিহ্নিত হয় এবং আপনি এটি আপনার শেল (যেমন ./filename) থেকে চালনা করেন তবে এটি দিয়ে শুরু হয় না#! , কার্নেল এটি কার্যকর করতে ব্যর্থ হয়। যাইহোক, এটি ঘটেছে তা দেখে, আপনার শেলটি এর নামটি কয়েকটি শেলের কাছে দিয়ে এটি চালানোর চেষ্টা করবে । আছে কয়েক প্রয়োজনীয়তা উপর স্থাপন করা কি শেল যে ( "শেল শেল হচ্ছে কমান্ড সমতুল্য সিদ্ধান্ত নেবে | প্রার্থনা ..." )। অনুশীলনে , কিছু শাঁস - ^* সহ নিজের একটি অন্য উদাহরণ চালায়, অন্যরা ব্যবহার করেbash/bin/sh। আমি আপনাকে এড়াতে এবং পরিবর্তে একটি হ্যাশবাং লাইন ব্যবহার করার পরামর্শ দিচ্ছি (বা স্ক্রিপ্টটি এটি পছন্দসই দোভাষী হিসাবে প্রেরণ করে, যেমন, bash filename)।

  ^* _{জিএনইউ বাশ ম্যানুয়াল , ৩.7.২ কমান্ড সন্ধান এবং এক্সিকিউশন : "যদি এই এক্সিকিউশন ব্যর্থ হয় কারণ ফাইলটি এক্সিকিউটেবল ফর্ম্যাটে নেই এবং ফাইলটি ডিরেক্টরি নয়, তবে এটি শেল স্ক্রিপ্ট হিসাবে ধরে নেওয়া হয় এবং শেলটি বর্ণিত হিসাবে এটি কার্যকর করে" মধ্যে শেল স্ক্রিপ্ট । "}

Comments

আমি যেটিতে দরকারী sourceবলে মনে করি তা হ'ল ফাংশনগুলি আবার লোড বা প্রবর্তন না করে বাশ থেকে পাওয়া যায়। উদাহরণ #!/bin/bash function olakease {echo olakease;}। একবার আপনি এটি লোড করার সাথে source file.shসরাসরি olakeaseব্যাশ থেকে কল করতে পারেন । আমি সত্যিই এটি পছন্দ। উত্স কার্যকর করে তখন প্রচুর পরিমাণে লোড হয়, বিন্দুটি .কেবল মৃত্যুদন্ড কার্যকর করার জন্য এবং ব্যবহারের মতো কিছুbash file.sh

— erm3nda

@ erm3nda এরও .এই আচরণ রয়েছে: . file.shএবং source file.shসংজ্ঞায়িত ফাংশন বজায় রাখা সহ ঠিক একই জিনিসটি করুন file.sh। (সম্ভবত আপনি চিন্তা করা হয় ./file.sh, যা ভিন্ন কিন্তু যে নেই। না ব্যবহার ., বরং builtin .পথ অংশ।)

— Eliah মধ্যে Kagan

ওহ, আমি সাবধানে পড়েনি। [স্পেস] ফাইল। আপনাকে অনেক ধন্যবাদ।

— erm3nda

Answer 2

হ্যাঁ, আপনি কিছু মিস করছেন।

আমি মনে করি আপনি 'বিভ্রান্ত করছেন।' তার অর্থ বর্তমান ডিরেক্টরি যেমন ./testenv.shএবং ''। এর অর্থ source(যা একটি অন্তর্নির্মিত কমান্ড)। সুতরাং ক্ষেত্রে যখন '। মানে sourceহবে . ./testenv.sh। ধারণা তৈরী কর?

সুতরাং এটি চেষ্টা করুন:

MY_VAR=12345 
. ./testenv.sh

Comments

./বলা হয়েছে যে সব ঠিক যেখানে ফাইল এটা তা ছাড়া, ব্যাশ পাথ মাধ্যমে প্রথম দেখবে, তারপর বর্তমান Dir চেষ্টা যদি এটা খুঁজে পাইনি। যদি ব্যাশটি পসিক্স মোডে চলমান থাকে এবং আপনি ফাইলটির (যেমন ./) কোনও পথ সরবরাহ না করেন তবে এটি কেবলমাত্র PATH এ অনুসন্ধান করবে এবং বর্তমান দির প্যাথ-এ না থাকলে ফাইলটি খুঁজে পেতে ব্যর্থ হবে।

— 12 'গিরিহা

@ গিরিহা হ্যাঁ, আপনি ঠিক বলেছেন, source(এবং .) প্রকৃতপক্ষে সাধারণ অর্থে স্ক্রিপ্টটি চালাচ্ছেন না তা সত্ত্বেও তারা প্রথমে AT PATH চেক করবে । আমার (প্রাক্তন) মন্তব্যটি ভুল ছিল।

— এলিয়াহ কাগন

সংক্ষিপ্ত এবং বিন্দুতে +1

— ডেভিড মোরালেস