শেল স্ক্রিপ্টে পাথ ভেরিয়েবলের শেষে আমার একটি স্ল্যাশ ব্যবহার করা উচিত? [বন্ধ]

Question

আজ আমার শেল স্ক্রিপ্ট লেখার সময়।

হঠাৎ আমার মনে একটি প্রশ্ন আসে।

যেহেতু cd /target_dirএবং cd /target_dir/উভয়ই কাজ করে।
শেল স্ক্রিপ্টে আমার পাথের ভেরিয়েবলগুলির শেষে আমি একটি স্ল্যাশ যুক্ত করব?
যেমন LOG_PATH=/data/nginx/logsবনাম LOG_PATH=/data/nginx/logs/।

আমি গুগলে কিছু স্থূল অনুসন্ধান করেছি, কিন্তু এ সম্পর্কে আলোচনা খুঁজে পাইনি, সম্ভবত এটি খুব প্রাথমিক?

আপাতত, কোন স্টাইলটি বেছে নেব তা সিদ্ধান্ত নেওয়া আমার পক্ষে সত্যিই শক্ত।
তবে আমি LOG_PATH=/target_dir/স্টাইলকে কিছুটা বেশি প্রাধান্য দিয়েছি ।
কারণ যখন আমি ব্যাশের সাথে স্ব-সমাপ্তি করি, তখন এটি ফলাফলকে আমাকে স্ল্যাশ দিয়ে যায়।

এ সম্পর্কে আপনার মতামত, কেন?

Comments

প্রাসঙ্গিক: একটি ডিরেক্টরি পথ পরিবর্তনশীল কিছুটা কম দিয়ে একটি

— ট্রেলিং

কোনও নিয়ম নেই। উভয় কোডিং শৈলীর কিছু সুবিধা এবং কিছু অপূর্ণতা রয়েছে।

— andcoz

Answer 1

পসিক্স অনুসারে:

পথের সংজ্ঞা:

একটি স্ট্রিং যা কোনও ফাইল সনাক্ত করতে ব্যবহৃত হয়। এর al চ্ছিক শুরু <স্ল্যাশ> অক্ষর রয়েছে, তারপরে শূন্য বা আরও বেশি ফাইল নাম <স্ল্যাশ> অক্ষর দ্বারা পৃথক করা আছে । একটি পাথনামে oneচ্ছিকভাবে এক বা একাধিক পেছনের <স্ল্যাশ> অক্ষর থাকতে পারে । একাধিক ধারাবাহিক <স্ল্যাশ> অক্ষরকে ঠিক দুটি শীর্ষ <স্ল্যাশ> অক্ষরের ক্ষেত্রে বাদে এক <স্ল্যাশ> হিসাবে একই বলে মনে করা হয় ।

Comments

@ এটি আকর্ষণীয়, আমি বাশ প্রম্পটে তাদের নামটি আলাদাভাবে প্রদর্শন করতে //এবং এর /সাথে সিডি করতে pwdপারি এবং ব্যবহার করে আমি বিভিন্ন পথ দেখাব, তবে তাদের সামগ্রীটি অভিন্ন! কেন?

— জেন

@Zen unix.stackexchange.com/a/12291/70524

— muru

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

— প্রাচ্য

সম্পর্কিত: পিডব্লিউডি এবং / বিন / পিডাব্লুডির মধ্যে অদ্ভুত পার্থক্য ।

— জি-ম্যান

Answer 2

নিরাপদ দিকে থাকতে, স্ল্যাশ অন্তর্ভুক্ত করুন। পথগুলিকে একত্রিত করার সময় এটি একাধিক স্ল্যাশ হতে পারে তবে কমপক্ষে আপনি সমস্যা এড়াতে পারেন।

কয়েকটি উদাহরণ: rsyncট্রেলিং স্ল্যাশ অন্তর্ভুক্ত করা হলে পাথগুলি আলাদাভাবে আচরণ করে (এটি অন্য ডিরেক্টরিকে পরিবর্ত করার পরিবর্তে সেই ডিরেক্টরিটি সিঙ্ক্রোনাইজ করে)। ডিরেক্টরিগুলির সিম্বলিক লিঙ্কগুলি কখনও কখনও অপ্রত্যাশিতভাবে আচরণ করে যখন তাদের পিছনে স্ল্যাশ নেই - কমপক্ষে শেল সমাপ্তি বিভ্রান্ত হয়ে যায়। আপনি কখনই জানেন না যে আপনি যে কমান্ড / স্ক্রিপ্টটি প্রবর্তন করেছেন তা কোনও বিশেষ আচরণের জন্য স্ল্যাশ পরীক্ষা করার উপর নির্ভর করে। এমনকি এটি আপনাকে কিছুতে ওভাররাইট করা থেকে বাঁচাতে পারে। উদাহরণস্বরূপ, যদি আপনার কাছে কোনও ফাইলের নাম দেওয়া থাকে fooতবে আপনি ভুলভাবে এটি একটি ডিরেক্টরি বলে মনে করেন এবং এটিতে কোনও কিছু সরিয়ে নিতে চান, তবে mv bar fooফাইলটি ওভাররাইট করবে (ডেটা হ্রাস, সম্ভাব্য বিপর্যয়) তবে mv bar foo/কেবল অভিযোগ করবে এবং কিছুই করবে না।

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

Answer 3

না, আপনার করা উচিত নয়। এটি একটি অতিরিক্ত অপ্রয়োজনীয় স্ল্যাশ যোগ করে ( /)।

উদাহরণ

বলুন যে আপনি জাভা binডিরেক্টরিটি আপনার PATHভেরিয়েবলে রফতানি করতে চান ,

export PATH=$PATH:/opt/jre1.7.0_45/bin/

এখন এটি পরীক্ষা করুন,

user@host:~$ which java
/opt/jre1.7.0_45/bin//java

/জাভা আগে অতিরিক্ত স্ল্যাশ লক্ষ্য করুন ( ), কিন্তু ভাগ্যক্রমে এটি ঠিক যেমন ক্ষেত্রে কাজ করে।

Comments

আমি এই লিঙ্কটিতে দেখেছি সেখানে একটি 31 টির উত্তর রয়েছে যাতে লেখক মনে করেন আমাদের একটি স্ল্যাশ যুক্ত করা উচিত। আমি বিভ্রান্ত stackoverflow.com/questions/980255/…

— জেন

@ জেন, হ্যাঁ আমি এটি পরীক্ষা করেছি, এটি আপনার প্রশ্নের প্রথম মন্তব্যে ছিল। ধন্যবাদ।

— অর্ণব

কারও চেয়ে দুটি টুকরো টুকরো ভাল। এটি একটি কুরুচিপূর্ণ তবে নিরাপদ ... অন্য বিকল্পটি আরও খারাপ এবং বিপজ্জনক হতে পারে।

— প্রাচ্য