যদি প্রক্রিয়াগুলি পিতামাতার পরিবেশের উত্তরাধিকারী হয় তবে কেন আমাদের রফতানি দরকার?

72

আমি এখানে পড়েছি যে exportশেলটির উদ্দেশ্য হ'ল শেল থেকে শুরু হওয়া উপ-প্রক্রিয়াগুলির জন্য চলকটি উপলব্ধ করা।

তবে, আমি এখানে এবং এখানেও পড়েছি যে "প্রক্রিয়াগুলি তাদের পিতামাতার কাছ থেকে তাদের পরিবেশের উত্তরাধিকারী হয় (প্রক্রিয়া যা তাদের শুরু করেছিল)"।

এটি যদি হয় তবে আমাদের কেন দরকার export? আমি কী মিস করছি?

শেল ভেরিয়েবলগুলি কি ডিফল্টরূপে পরিবেশের অংশ নয়? পার্থক্য কি?

shell process environment-variables

— আমেলিও ভাজকেজ-রেইনা
সূত্র

74

আপনার অনুমান যে শেল ভেরিয়েবলগুলি পরিবেশে রয়েছে । এটি ভুল। exportকমান্ড কি একটি নাম সংজ্ঞায়িত এ সব পরিবেশে হতে হয়। এভাবে:

a=1 b=2
export b

বর্তমান শেলটি$a 1 এবং $b2 তে প্রসারিত জেনে ফলাফল প্রকাশ করে তবে উপ-প্রক্রিয়াগুলি aপরিবেশের অংশ না হওয়ায় (এমনকি বর্তমান শেলের মধ্যেও) এ সম্পর্কে কিছুই জানতে পারবে না ।

কিছু দরকারী সরঞ্জাম:

set: বর্তমান শেলটির প্যারামিটারগুলি দেখার জন্য কার্যকর, রফতানি-না-করা
set -k: পরিবেশে বরাদ্দকৃত আর্গ সেট করে । বিবেচনাf() { set -k; env; }; f a=1
set -a: শেলটিকে পরিবেশের মধ্যে সেট করা যে কোনও নাম রাখতে বলুন। exportপ্রতিটি অ্যাসাইনমেন্টের আগে রাখার মতো । .envযেমন ফাইল হিসাবে দরকারী set -a; . .env; set +a।
export: শেলটিকে পরিবেশে একটি নাম রাখতে বলে। এক্সপোর্ট এবং অ্যাসাইনমেন্ট দুটি সম্পূর্ণ ভিন্ন অপারেশন।
env: বাহ্যিক আদেশ হিসাবে, উত্তরাধিকার সূত্রে প্রাপ্ত পরিবেশ envসম্পর্কে কেবল আপনাকে বলতে পারে, সুতরাং এটি স্যানিটি পরীক্ষা করার জন্য দরকারী।
env -i: সাব-প্রসেস শুরু করার আগে পরিবেশ সাফ করার জন্য দরকারী।

এর বিকল্পগুলি export:

name=val command কমান্ডের পূর্বে অ্যাসাইনমেন্ট নামটি কমান্ডে রফতানি করে।
declare/local -x name # রফতানির নাম, বিশেষত শেল ফাংশনে কার্যকর যখন আপনি নামটি বাইরের সুযোগে প্রকাশ করা এড়াতে চান।
set -a # প্রতিটি নিম্নলিখিত অ্যাসাইনমেন্ট রফতানি করে।

— kojiro
সূত্র

3

set -kএটির cmd ENVVAR=valueজায়গায় যাতে কেউ ব্যবহার করতে পারে ENVVAR=value cmd, set -kতা অনুরোধের আগে চালানো না হলে এটি আপনার উদাহরণে কাজ করবে না f। এছাড়াও, আজকাল অনেকগুলি শেল এটিকে সমর্থন করে না এবং কেবল বোর্ন শেলের সাথে পশ্চাদপটে সামঞ্জস্যের জন্য। বোর্ন (বা কর্ন) শেলের মধ্যে, এটি ফাংশনগুলির জন্য কাজ করবে না। এবং যেহেতু এটি শেল পার্সিংকে প্রভাবিত করে, শেলটি কোডটি পড়ার সময় কার্যকর হবে যখন সেখানে এটি ব্যবহার করে।

— স্টাফেন চেজেলাস

1

আপনি উল্লেখ করতেও পারেনset -a

— স্টাফেন চেজেলাস

24

শেল ভেরিয়েবল এবং এনভায়রনমেন্ট ভেরিয়েবলের মধ্যে পার্থক্য রয়েছে। আপনি যদি শেল ভেরিয়েবলটি exportইগ না করে সংজ্ঞায়িত করেন তবে এটি প্রক্রিয়াগুলির পরিবেশে যুক্ত হয় না এবং এর ফলে এটি তার বাচ্চাদের উত্তরাধিকার সূত্রে প্রাপ্ত হয় না।

exportআপনি ব্যবহার করে শেলটি পরিবেশে শেল পরিবর্তনশীল যুক্ত করতে বলুন। আপনি এটি ব্যবহার করে printenvএটি পরীক্ষা করতে পারেন (যা কেবল এটির পরিবেশকে প্রিন্ট করে stdout, যেহেতু এটি একটি শিশু-প্রক্রিয়া যা আপনি exportভেরিয়েবলগুলির প্রভাব দেখতে পান ):

#!/bin/sh

MYVAR="my cool variable"

echo "Without export:"
printenv | grep MYVAR

echo "With export:"
export MYVAR
printenv | grep MYVAR

— আন্ড্রেস উইস
সূত্র

6

একটি পরিবর্তনশীল, একবার রফতানি করা, পরিবেশের অংশ। PATHশেল নিজেই রফতানি করা হয়, যখন কাস্টম ভেরিয়েবলগুলি প্রয়োজনমতো রফতানি করা যায়। কিছু সেটআপ কোড ব্যবহার করে:

$ cat subshell.sh 
#!/usr/bin/env bash
declare | grep -e '^PATH=' -e '^foo='

তুলনা করা

$ cat test.sh 
#!/usr/bin/env bash
export PATH=/bin
export foo=bar
declare | grep -e '^PATH=' -e '^foo='
./subshell.sh
$ ./test.sh 
PATH=/bin
foo=bar
PATH=/bin
foo=bar

সঙ্গে

$ cat test2.sh 
#!/usr/bin/env bash
PATH=/bin
foo=bar
declare | grep -e '^PATH=' -e '^foo='
./subshell.sh
$ ./test2.sh 
PATH=/bin
foo=bar
PATH=/bin

যেহেতু fooশেল দ্বারা রফতানি করা হয় না এবং test2.shএটি কখনও রফতানি হয় না, এটি subshell.shশেষ রানের পরিবেশের অংশ ছিল না ।

— l0b0
সূত্র