প্রচুর শেবাং (স্ক্রিপ্ট ঘোষণা) লাইন - তাদের পরিমাণ হ্রাস করার কোনও উপায়?


12

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

প্রতিটি .shফাইলের শুরুতে , আমি রেখেছি #!/bin/bash

সহজ কথায়, আমি বুঝতে পারি স্ক্রিপ্ট ঘোষণার দুটি উদ্দেশ্য রয়েছে:

  1. তারা ব্যবহারকারীকে ফাইলটি নির্বাহ করতে কী শেলের প্রয়োজন তা স্মরণে রাখতে সহায়তা করে (ফাইলটি ব্যবহার না করে কয়েক বছর পরে বলুন)।
  2. তারা নিশ্চিত করে যে অন্য কোনও শেল ব্যবহারের ক্ষেত্রে অপ্রত্যাশিত আচরণ রোধ করতে স্ক্রিপ্টটি কেবল একটি নির্দিষ্ট শেল (সেই ক্ষেত্রে বাশ) দিয়ে চলে।

যখন কোনও প্রকল্পের মধ্যে 5 টি ফাইল থেকে 20 ফাইল বা 20 ফাইল থেকে 50 ফাইলের (এই ক্ষেত্রে নয় তবে কেবল প্রদর্শনের জন্য) বড় হওয়া শুরু হয় তখন আমাদের কাছে 20 লাইন বা স্ক্রিপ্ট ঘোষণার 50 টি লাইন রয়েছে। আমি স্বীকার করি, যদিও এটি কারওর কাছে মজাদার হতে পারে, তবে 20 বা 50 ব্যবহার করার পরিবর্তে আমার প্রতি প্রকল্পের জন্য কেবল 1 বলুন (সম্ভবত প্রকল্পের মূল ফাইলটিতে ) কিছুটা বাড়াবাড়ি বোধ করে ।

20 বা 50 এর কথিত অপ্রয়োজনীয়তা বা কিছু মূল ফাইলে কিছু "গ্লোবাল" স্ক্রিপ্ট ডিক্লারেশন ব্যবহার করে স্ক্রিপ্ট ঘোষণার লাইনগুলির বৃহত্তর সংখ্যাকে এড়ানোর কোনও উপায় আছে কি?


2
আপনার উচিত ছিল না কিন্তু পারে; এটি সরান এবং আপনার সমস্ত স্ক্রিপ্টগুলি কার্যকর করুন/bin/bash -x "$script"
jesse_b


... সাধারণত যখন কিছু এই মুহুর্তে পৌঁছায় তখনই আমি ইতিমধ্যে শেষ করেছি শেল স্ক্রিপ্ট ব্যবহার বন্ধ করার এবং কাজটি করার জন্য একটি আসল স্ক্রিপ্টিং ভাষা পাওয়ার।
শাদুর

উত্তর:


19

যদিও আপনার প্রকল্পে এখন কেবলমাত্র 50 ব্যাশ স্ক্রিপ্ট থাকতে পারে, তা শিগগিরই বা পরে অন্যান্য ভাষা যেমন পার্ল বা পাইথনগুলিতে লিখিত স্ক্রিপ্টগুলি সংগ্রহ করতে শুরু করবে (এই স্ক্রিপ্টিং ভাষাগুলির যে সুবিধার জন্য বাশ নেই)।

#!প্রতিটি স্ক্রিপ্টে যথাযথ- লাইন না থাকলে, দোভাষী কী কী ব্যবহার করবেন তা না জেনে বিভিন্ন স্ক্রিপ্টগুলি ব্যবহার করা অত্যন্ত কঠিন হবে। প্রতিটি স্ক্রিপ্ট অন্যান্য স্ক্রিপ্ট থেকে কার্যকর করা হয় তা বিবেচ্য নয় , এটি কেবলমাত্র শেষ ব্যবহারকারীদের থেকে বিকাশকারীদের দিকেই সমস্যাটি সরিয়ে দেয়। এই দুটি গ্রুপেরই উভয়েরই জানা উচিত নয় যে কোনও স্ক্রিপ্টটি ব্যবহার করতে সক্ষম হতে কোন ভাষায় লিখিত হয়েছিল।

শেল স্ক্রিপ্টগুলি এক- #!লাইন ছাড়াই এবং সুস্পষ্ট দোভাষী ছাড়াও বিভিন্নভাবে কার্যকর করা হয় শেলটি কীভাবে আহ্বান করে তা নির্ভর করে (উদাহরণস্বরূপ প্রশ্নটি দেখুন কোন শেল ইন্টারপ্রেটার কোন শেবাং ছাড়াই একটি স্ক্রিপ্ট চালায়? এবং বিশেষত স্টাফেনের উত্তর ) যা আপনি চান তা নয় উত্পাদনের পরিবেশে (আপনি সামঞ্জস্যপূর্ণ আচরণ এবং সম্ভবত এমনকি বহনযোগ্যতাও চান)।

স্পষ্টত দোভাষীর সাথে সম্পাদিত স্ক্রিপ্টগুলি #!লাইন - লাইন যা বলে তা বিবেচনা না করেই সেই দোভাষী দ্বারা চালিত হবে । আপনি যদি পাইথন বা অন্য কোনও ভাষায় একটি বাশ স্ক্রিপ্ট পুনরায় বাস্তবায়ন করার সিদ্ধান্ত নেন তবে এটি লাইনটিতে আরও সমস্যার সৃষ্টি করবে।

আপনার এই অতিরিক্ত কী-স্ট্রোকগুলি ব্যয় করা উচিত এবং সর্বদা #!প্রতিটি স্ক্রিপ্টে একটি লাইন যুক্ত করা উচিত।


কিছু পরিবেশে, প্রতিটি প্রকল্পে প্রতিটি স্ক্রিপ্টে বহু অনুচ্ছেদে বয়লারপ্লেট আইনী পাঠ্য রয়েছে। খুব খুশি হোন যে এটি #!আপনার প্রকল্পে কেবলমাত্র একটি লাইন যা "রিডানড্যান্ট" বোধ করে।


উত্তরটি এর দ্বারা প্রসারিত করা উচিত: #!ফাইলটি অনির্বাচিত অনুমতি পাওয়ার সাথে সাথে শেলটি লাইন দ্বারা দোভাষীটি নির্ধারণ করে এবং দোভাষী দ্বারা লোড করা হয় না, তবে শেল দ্বারা by এটি হ'ল লাইন উপস্থিত /path/to/myprog.plথাকলে পার্ল প্রোগ্রাম চালায় #!(পার্ল ইন্টারপ্রেটারের দিকে ইঙ্গিত করছে) এবং ফাইলটি সম্পাদনের অনুমতি রয়েছে।
রেক্সকোগিটান

11

আপনি এর বিন্দু ভুল #!। সংজ্ঞায়িত দোভাষীর অধীনে এই প্রোগ্রামটি পরিচালনা করার জন্য এটি অপারেটিং সিস্টেমের পক্ষে আসলে একটি নির্দেশ

সুতরাং একটি স্ক্রিপ্ট হচ্ছে #!/usr/bin/perlএবং ফলস্বরূপ প্রোগ্রামটি চালানো যেতে পারে ./myprogramএবং পার্ল ইন্টারপ্রেটার ব্যবহার করা যেতে পারে। অনুরূপ #!/usr/bin/pythonএকটি অজগর অধীনে একটি প্রোগ্রাম চালানোর কারণ হতে পারে।

সুতরাং লাইনটি #!/bin/bashওএসকে বাশার অধীনে এই প্রোগ্রামটি চালাতে বলে।

এখানে একটি উদাহরণ:

$ echo $0
/bin/ksh

$ cat x
#!/bin/bash

ps -aux | grep $$

$ ./x
sweh      2148  0.0  0.0   9516  1112 pts/5    S+   07:58   0:00 /bin/bash ./x
sweh      2150  0.0  0.0   9048   668 pts/5    S+   07:58   0:00 grep 2148

সুতরাং, আমার শেলটি ksh হওয়া সত্ত্বেও, প্রোগ্রামটি "x" #!লাইনের কারণে ব্যাশের অধীনে চলে এবং আমরা প্রক্রিয়া তালিকাতে এটি স্পষ্টভাবে দেখতে পারি।


ps -auxসতর্কতা দিতে পারে,
ওয়েইজুন চিউ

@ ওয়েইজুনঝৌ আরও বলুন ...
কুসালানন্দ

এর কিছু সংস্করণ psসতর্কতা দেয় Warning: bad syntax, perhaps a bogus '-'?
ওয়েজুন চাউ

2
psBSD এবং UXIX উভয় আর্গুমেন্ট সিনট্যাক্সকে suooprts করে। -auxভুল ইউনিক্স স্টিফেন সম্ভবত সম্ভবত auxযা সঠিক বিএসডি
জ্যাসেন

1
মানুষ, 2 জিনিস; (1) উদাহরণ ধারণায় মনোনিবেশ করুন (যেটি কলিংটি psদেখায় bash) স্পষ্ট বাক্য গঠন নয়; (২) ps -auxসেন্টোস 7 এবং ডবিয়ান 9 এ সতর্কতা ছাড়াই পুরোপুরি কাজ করে; আমার মেশিন থেকে আউটপুট হ'ল কাট'এনস্পেস; যদি -প্রয়োজন হয় বা না হয় তার পুরো আলোচনাটি লিনাক্স প্রোপসের পুরানো সংস্করণগুলিতে প্রযোজ্য , বর্তমান সংস্করণ নয়।
স্টিফেন হ্যারিস

9

চালু .sh

খারাপটি হ'ল .shফাইল-নামের শেষে।

কল্পনা করুন যে আপনি পাইথনের স্ক্রিপ্টগুলির একটি পুনরায় লিখেছেন।

ঠিক আছে এখন আপনাকে প্রথম লাইনটি পরিবর্তন করতে হবে এটি #!/usr/bin/python3এতটা খারাপ নয়, কারণ আপনাকে ফাইলটিতেও কোডের অন্যান্য লাইন পরিবর্তন করতে হয়েছিল। তবে আপনার কাছে থেকে ফাইলের নাম পরিবর্তন করতে হবে prog.shকরতে prog.py। এবং তারপরে আপনাকে অন্যান্য স্ক্রিপ্টগুলিতে এবং আপনার সমস্ত ব্যবহারকারীর স্ক্রিপ্ট (যেগুলি আপনি জানেন না সেগুলিও আছে) খুঁজে পেতে এবং নতুন স্ক্রিপ্টটি ব্যবহার করতে সেগুলি পরিবর্তন করতে হবে। sed -e 's/.sh/.py/g'আপনি যাদের সম্পর্কে জানেন তাদের জন্য সহায়তা করতে পারে। তবে এখন আপনার রিভিশন নিয়ন্ত্রণ সরঞ্জামটি প্রচুর সম্পর্কযুক্ত ফাইলগুলিতে পরিবর্তন দেখাচ্ছে।

বিকল্পভাবে এটি ইউনিক্স উপায়ে করুন এবং প্রোগ্রামটির নাম দিন progনা prog.sh

চালু #!

আপনার যদি সঠিক থাকে #!এবং এক্সিকিউটটি অন্তর্ভুক্ত করার জন্য অনুমতি / মোড সেট করে। তারপরে আপনার দোভাষীটি জানার দরকার নেই। কম্পিউটার এটি আপনার জন্য করবে।

chmod +x prog #on gnu adds execute permission to prog.
./prog #runs the program.

নন gnu সিস্টেমের জন্য ম্যানুয়ালটি পড়ুন chmod(এবং অষ্টাল শিখুন), সম্ভবত এটি যে কোনওভাবে পড়ুন।


1
হুঁ, এক্সটেনশনগুলি অগত্যা খারাপ নয়, কমপক্ষে তারা অন্য ধরণের ফাইল ব্যবহারকারীদের সাথে যোগাযোগ করতে সহায়তা করে।
সের্গেই কোলোডিয়াজনি

@ সের্গি কলোডিএজনি তবে আপনার ভাষাটি জানা উচিত নয়, আপনার এটি চালানো দরকার। এমনকি মাইক্রোসফ্ট এক্সটেনশনগুলি থেকে সরে যাওয়ার চেষ্টা করছে (দুর্ভাগ্যবশত তারা এগুলি আমার লুকিয়ে রাখছে)। তবে আমি সম্মত নই যে এগুলি একটি ভাল ধারণা হতে পারে: .imageছবিগুলির জন্য। .audioশব্দ ইত্যাদির জন্য সুতরাং এটি বাস্তবায়ন / এনকোডিং সম্পর্কে নয় তবে তা আপনাকে বলছে।
ctrl-alt-delor

1
@ ctrl-alt-delor ফাইলটি যদি বলা হয় launch-missilesবা delete-project-and-make-manager-pissedআমি যখন ভাষা সম্পর্কে কেবল কৌতূহলী ছিলাম তখন আমি "কেবল এটি চালাতে" চাই না :)
সের্গি কলডিয়াজহনি

2
আপনি যদি ভাষাটির জন্য আগ্রহী হন তবে fileকমান্ডটি ব্যবহার করুন । এটি বেশিরভাগ ফাইলের স্বীকৃতি দেয়।
জেসেন

2
আমি সম্মত হই যে এক্সটেনশনগুলি এক্সিকিউটেবল স্ক্রিপ্টগুলির জন্য খারাপ, ঠিক কারণ হিসাবে for আমি একটি স্ক্রিপ্টের জন্য একটি .sh এক্সটেনশন ব্যবহার করি যা অন্য শেল স্ক্রিপ্টের (যেমন একটি এক্সিকিউটেবল স্ক্রিপ্ট) দ্বারা উত্সাহিত করা দরকার - সেই পরিস্থিতিতে, প্রত্যয়টি গুরুত্বপূর্ণ / বৈধ কারণ এটি আমাদের জানায় যে আমরা কীভাবে ফাইলটি ব্যবহার করতে পারি।
লরেন্স রেনশওয়া

8

[হ্যাশবাং লাইন] নিশ্চিত করে যে অন্য কোনও শেল ব্যবহারের ক্ষেত্রে অপ্রত্যাশিত আচরণ রোধ করতে স্ক্রিপ্টটি কেবল একটি নির্দিষ্ট শেল (সেই ক্ষেত্রে বাশ) দিয়ে চলে।

এটি সম্ভবত ভুল হওয়া উচিত যে এটি বেশ ভুল। হ্যাশবাং লাইন কোনওভাবেই আপনাকে ভুল শেল / ইন্টারপ্রেটারকে ফাইল খাওয়ানোর চেষ্টা করতে বাধা দেয়:

$ cat array.sh
#!/bin/bash
a=(a b c)
echo ${a[1]} $BASH_VERSION
$ dash array.sh
array.sh: 2: array.sh: Syntax error: "(" unexpected

(বা একইভাবে awk -f array.shইত্যাদি)


তবে যে কোনও ক্ষেত্রে, মড্যুলারটির আরেকটি উপায় হ'ল ফাইলগুলিতে শেল ফাংশনগুলি সংজ্ঞায়িত করা, ফাইলের জন্য একটি ফাংশন, যদি আপনি চান তবে এবং sourceপ্রধান প্রোগ্রাম থেকে ফাইলগুলি। এইভাবে, আপনার হ্যাশব্যাংগুলির প্রয়োজন হবে না: এগুলি অন্য কোনও মন্তব্য হিসাবে বিবেচিত হবে এবং সমস্ত কিছুই একই শেল ব্যবহার করে চালানো হবে। খারাপ দিকটি হ'ল sourceআপনার ফাংশনগুলির (যেমন for x in functions/*.src ; do source "$x" ; done) ফাইলগুলির দরকার পড়ে এবং তারা সকলেই একই শেল ব্যবহার করে চালাতে চান, তাই আপনি সরাসরি তাদের পার্ল-প্রয়োগের মাধ্যমে প্রতিস্থাপন করতে পারবেন না।


বাশ অ্যারে সহ উদাহরণস্বরূপ +1। একাধিক শেল অপরিচিত বা কি POSIX সংজ্ঞায়িত কিছু ব্যবহারকারীরা পারে অনুমান অন্য এক শেল থাকবেই কিছু বৈশিষ্ট্য। : এছাড়াও কাজগুলির জন্য এই হতে পারে প্রাসঙ্গিক unix.stackexchange.com/q/313256/85039
Sergiy Kolodyazhnyy

4

20 বা 50 এর কথিত অপ্রয়োজনীয়তা বা কিছু মূল ফাইলে কিছু "গ্লোবাল" স্ক্রিপ্ট ডিক্লারেশন ব্যবহার করে স্ক্রিপ্ট ঘোষণার লাইনগুলির বৃহত্তর সংখ্যাকে এড়ানোর কোনও উপায় আছে কি?

রয়েছে - একে বহনযোগ্যতা বা পসিক্স সম্মতি বলা হয়। সর্বদা পোর্টেবল, শেল-নিরপেক্ষ উপায়ে স্ক্রিপ্টগুলি লেখার চেষ্টা করুন, কেবলমাত্র এমন স্ক্রিপ্ট থেকে তাদের উত্স করুন যা #!/bin/shআপনি /bin/shইন্টারেক্টিভভাবে ব্যবহার করেন (বা খুব কমপক্ষে একটি পসিক্স-কমপ্লায়েন্ট শেল যেমন ksh)।

তবে পোর্টেবল স্ক্রিপ্টগুলি এগুলি থেকে আপনাকে বাঁচায় না:

  • শেলগুলির একটিতে বৈশিষ্ট্যগুলি ব্যবহার করা দরকার ( ইলকচকুর উত্তর একটি উদাহরণ)
  • খোলের চেয়ে বেশি উন্নত স্ক্রিপ্টিং ভাষা ব্যবহার করা দরকার (পাইথন এবং পার্ল)
  • পেব্যাক ত্রুটি: আপনার স্ক্রিপ্টটি ব্যবহারকারী জে। ডিওর হাতে পড়ে যিনি আপনার স্ক্রিপ্টটি আপনার ইচ্ছা মতো চালান না, উদাহরণস্বরূপ তারা /bin/shস্ক্রিপ্টটি চালায় csh

আমি যদি আমার মতামত প্রকাশ করতে পারি তবে "অপ্রয়োজনীয়তা এড়ানো" মুছে ফেলা #!ভুল লক্ষ্য। লক্ষ্যটি সামঞ্জস্যপূর্ণ পারফরম্যান্স এবং আসলে একটি কার্যনির্বাহী স্ক্রিপ্ট হওয়া উচিত যা কাজ করে এবং কোণার ক্ষেত্রে বিবেচনা করে, কিছু সাধারণ নিয়ম অনুসরণ করে যেমন নন-পার্সিং-এলএস বা সর্বদা-উদ্ধৃতি-ভেরিয়েবল-অযথা-শব্দ-বিভাজন

তারা ব্যবহারকারীকে ফাইলটি নির্বাহ করতে কী শেলের প্রয়োজন তা স্মরণে রাখতে সহায়তা করে (ফাইলটি ব্যবহার না করে কয়েক বছর পরে বলুন)।

তারা প্রকৃতপক্ষে ব্যবহারকারীর জন্য নয় - তারা সঠিক দোভাষী চালানোর জন্য অপারেটিং সিস্টেমের জন্য। এই ক্ষেত্রে "যথাযথ", এর অর্থ ওএস শেবাংয়ে যা আছে তা আবিষ্কার করে; যদি ভুল শেলের জন্য নীচের কোডটি থাকে - তবে এটি লেখকের ত্রুটি। ব্যবহারকারীর মেমোরি হিসাবে, আমি মনে করি না যে মাইক্রোসফ্ট ওয়ার্ড বা গুগল ক্রোমের মতো প্রোগ্রামগুলির "ব্যবহারকারী" কখনই কোন ভাষা প্রোগ্রামে লিখিত আছে তা জানা দরকার ছিল; লেখকদের প্রয়োজন হতে পারে।

তারপরে, পোর্টেবলভাবে লিখিত স্ক্রিপ্টগুলি এমনকি আপনি যে শেলটি মূলত ব্যবহার করেছেন তা মনে করার প্রয়োজনও দূর করতে পারে, কারণ পোর্টেবল স্ক্রিপ্টগুলি কোনও পসিক্স-কমপ্লায়েন্ট শেলটিতে কাজ করা উচিত।

তারা নিশ্চিত করে যে অন্য কোনও শেল ব্যবহারের ক্ষেত্রে অপ্রত্যাশিত আচরণ রোধ করতে স্ক্রিপ্টটি কেবল একটি নির্দিষ্ট শেল (সেই ক্ষেত্রে বাশ) দিয়ে চলে।

তারা না। আসলে যা অপ্রত্যাশিত আচরণকে বাধা দেয় তা হ'ল বহনযোগ্য স্ক্রিপ্টগুলি।


1

আপনাকে #!/bin/bashপ্রতিটি স্ক্রিপ্টের শীর্ষে রাখার কারণ হ'ল আপনি এটিকে পৃথক প্রক্রিয়া হিসাবে চালাচ্ছেন।

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

আপনি যদি #!লাইনটি সরাতে চান তবে আপনার বিকল্পগুলি হ'ল:

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

  2. ব্যবহার করে স্ক্রিপ্টটি কার্যকর করুন bash myscript.sh। এটি দুর্দান্ত কাজ করে তবে আপনাকে স্ক্রিপ্টের পথটি নির্দিষ্ট করতে হবে এবং এটি অগোছালো।

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

2 এবং 3 ক্ষেত্রে ফাইলটির অনুমতিগুলি কার্যকর করার (এবং এটি থাকা উচিত নয়) প্রয়োজন হয় না এবং এটির .sh(বা .bash) প্রত্যয় দেওয়া ভাল ধারণা।

তবে এই প্রকল্পগুলির মধ্যে কোনওটিই আপনার প্রকল্পের জন্য ভাল দেখাচ্ছে না, যেমন আপনি বলেছিলেন যে আপনি নিজের স্ক্রিপ্টগুলি মডুলার রাখতে চান (=> স্বতন্ত্র এবং স্বনির্ভর), সুতরাং আপনার #!/bin/bashনিজের স্ক্রিপ্টগুলির শীর্ষে থাকা উচিত ।

আপনার প্রশ্নে আপনি আরও বলেছেন যে আপনি ইউনিক্স দর্শনের অনুসরণ করছেন। যদি এটি সত্য হয় তবে আপনার #!লাইনটি আসলে কী জন্য তা শিখতে হবে এবং প্রতিটি এক্সিকিউটেবল স্ক্রিপ্টে এটি ব্যবহার চালিয়ে যান!


ভাল উত্তরের জন্য ধন্যবাদ। আমি উত্তরে সবকিছু পছন্দ এবং এই পর্যন্ত upvoting চিন্তা: then you should learn what the #! line is really for, and keep using it in every executable script!। হে ইউ জ্ঞানের নির্দিষ্ট বিন্দুতে U.P दर्शनদর্শন অনুসরণ করা যায়। এই সমস্ত উত্তরের পরেও আমি বুঝতে পারি কেন এটি that পদটিতে অন্তর্ভুক্ত করা যেতে পারে। আমি উত্তরটি সম্পাদনা করার পরামর্শ দিচ্ছি, এটির পরিবর্তে "শেব্যাংকে ইউনিক্স দর্শনের অভ্যন্তরীণ অংশ হিসাবে দেখুন যা আপনি সম্মান করেন এবং গ্রহণ করেন"।
ব্যবহারকারী 9303970

1
আমি সরাসরি থাকলে দুঃখিত, বা মন্তব্যটি অভদ্র মনে হলে। আপনার মন্তব্যগুলিতে পরামর্শ দেওয়া হয়েছে যে আপনি একটি আইডিইতে কাজ করতে পছন্দ করেন - এমন একটি 'প্রকল্প' যা আপনাকে সেই প্রকল্পের মধ্যে স্ক্রিপ্টগুলির জন্য বিশ্বব্যাপী নিয়ম সংজ্ঞায়িত করতে দেয়। এটি বিকাশের একটি বৈধ উপায়, তবে প্রতিটি স্ক্রিপ্টকে একটি স্বতন্ত্র, স্বতন্ত্র প্রোগ্রাম হিসাবে (ইউনিক্স দর্শনের 'আপনি উল্লেখ করেছেন) হিসাবে চিকিত্সা করার সাথে এটি উপযুক্ত নয়।
লরেন্স রেনশওয়া
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.