/ Usr / sbin, / usr / স্থানীয় / sbin এবং / usr / স্থানীয় / বিন এর অর্থ কী?


23

আসুন সমস্ত বিন এবং এসবিন ফোল্ডার (ফাইল সিস্টেমের স্তরক্রমের মান থেকে) দিয়ে পরিষ্কার হয়ে যাক:

  • /bin সিস্টেম-স্তরের বাইনারিগুলির জন্য
  • /sbin অন্যান্য সিস্টেম-স্তরের বাইনারিগুলি বেশিরভাগ বুট লোডার এবং সিস্টেম প্রশাসকদের জন্য for
  • /usr/bin অপরিহার্য বাইনারিগুলির জন্য নয়
  • /usr/sbin- এখান থেকেই গণ্ডগোল শুরু হয় - সিস্টেম প্রশাসকদের জন্য প্রয়োজনীয় সরঞ্জাম নয়? এর মানে কী? পরীক্ষার জন্য?
  • /usr/local/bin - এই ফোল্ডারটি সম্পর্কে কোনও শব্দ নেই
  • /usr/local/sbin- স্থানীয়ভাবে ইনস্টল করা সিস্টেম প্রশাসন প্রোগ্রাম। আবার? কীভাবে /usr/sbin?

তাই প্রশ্ন হল: কেন এত ডিরেক্টরি হয় এবং অর্থ কি /usr/sbin, /usr/local/sbinএবং /usr/local/bin?

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

এটা এমন কেন?

আমি মনে করি এটি সঠিক নয় কারণ প্রোগ্রামটির স্রষ্টা যদি এটি যত্ন না নেন তবে আমাদের যদি প্রোগ্রামটি সরিয়ে ফেলার দরকার হয় তবে ম্যানুয়ালি এর প্রতিটি ফাইল মুছে ফেলতে হবে।


সার্জি, সুপার ইউজারে পোস্ট লেখার জন্য দয়া করে মার্কডাউন সিনট্যাক্সটি ব্যবহার করুন। এগুলির মধ্যে এইচটিএমএল থাকার কারণে তাদের সরল পাঠ্যে পড়া এবং সম্পাদনা করা সত্যই কঠিন হয়ে পড়ে।
slhck

ঠিক আছে, আমি চেষ্টা করব
সের্গেই

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

[ফাইলসিস্টেম কিউ

BTW। স্থানীয়ভাবে নির্মিত প্রোগ্রামগুলির "আনইনস্টলবিলিটি" সমস্যাগুলি মোকাবেলার স্বাভাবিক উপায় হ'ল তাদের জন্য স্থানীয় প্যাকেজ তৈরি করা। এই প্রক্রিয়াটি অবশ্য লিনাক্স বিতরণের উপর নির্ভরশীল। যদি অ্যাপ্লিকেশনগুলি মোতায়েনের সেই মোডকে সমর্থন করে তবে ফ্ল্যাটপ্যাক বা ডকারের মতো প্রতিষ্ঠিত প্যাকেজিং সিস্টেমগুলির আধুনিক পরিপূরকগুলি মনে আসে।
লিনাক্স-ফ্যান

উত্তর:


23

1. ডিরেক্টরি কাঠামো

এটি ফাইল সিস্টেমের হায়ারার্কি স্ট্যান্ডার্ডে আবৃত করা উচিত ( ২.৩ পিডিএফ )

/ বিন / প্রয়োজনীয় কমান্ড বাইনারিগুলি যা একক ব্যবহারকারী মোডে উপলব্ধ থাকতে হবে;
            সমস্ত ব্যবহারকারীর জন্য যেমন, বিড়াল, এলএস, সিপি

/ sbin / প্রয়োজনীয় সিস্টেম বাইনারি, উদাহরণস্বরূপ, init, আইপি, মাউন্ট।

/ usr / bin / অ-প্রয়োজনীয় কমান্ড বাইনারি (একক ব্যবহারকারী মোডে প্রয়োজন হয় না); 
            সকল ব্যবহারকারীর জন্য

/ usr / sbin / অ-প্রয়োজনীয় সিস্টেম বাইনারিগুলি, যেমন বিভিন্ন নেটওয়ার্ক-পরিষেবাদির জন্য ডেমন।

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

2. ইনস্টলেশন

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

কিছু প্যাকেজ পরিচালক আরপিএম থেকে ইনস্টল করতে পারেন (যেমন yum install oddity.rpm)

আপনি যদি উত্স থেকে সংকলন করে থাকেন তবে এটি সম্ভবত আপনার নিজের প্যাকেজ তৈরির পক্ষে একটি বিশাল পদক্ষেপ নয় যাতে সিস্টেম ইনস্টলার জানেন যে আপনি কী করেছেন।

তাহলে আপনার সমস্যা যেমন কমেছে yum remove packagename

বিকল্পটি হ'ল সমস্ত সাসাদমিন কার্যক্রম সম্পর্কে ভাল ডকুমেন্টেশন রাখা (আমি যাই হোক না কেন একটি টেক্সট ফাইলে একটি জার্নাল রাখি)


3
আমি এখনও usr / sbin, usr / স্থানীয় / বিন এবং usr / স্থানীয় / sbin এর মধ্যে পার্থক্য পাই না। ইউএসআর / স্থানীয় এই হোস্টের জন্য সুনির্দিষ্ট বলা হয়, ইউএসআর / এসবিন, ইউএসআর / বিন এছাড়াও হোস্টের সাথে নির্দিষ্ট নয়? দ্বিতীয় প্রশ্নটি সেই প্রোগ্রামগুলির বিষয়ে ছিল যা রেপগুলিতে নেই - আনইনস্টল করা সবসময় কাজ করে না - তাই আমি জিজ্ঞাসা করেছি কীভাবে সেগুলি মুছতে হয়?
সের্গেই

3
@ সার্জি এটি isতিহাসিক। /usr/(s)binএকটি নেটওয়ার্ক ফাইল সিস্টেম থেকে মাউন্ট করা প্রবণতা। এজন্য মেশিনটি বুট করার জন্য যা কিছু প্রয়োজন তা থাকা উচিত ছিল /(s)bin/usr/localপ্যাকেজ ম্যানেজারের বাইরে আপনি যে প্রোগ্রামগুলি ইনস্টল করেন (যা আপনার করা উচিত নয়) এখন বেশিরভাগ অংশের জন্য ব্যবহৃত হয়।
লেট_মে_বি

ম্যানুয়ালি ইনস্টল করা প্রোগ্রামগুলির জন্য যা আপনার আর দরকার নেই কেবল নিয়মিত মুছতে (আরএম)। / ইউএসআর / স্থানীয় হ'ল মেশিন নির্দিষ্ট ডেটা যেমন নেটওয়ার্ক বুটিং সিস্টেম / ইউএসআর প্রায়শই একটি নেটওয়ার্ক শেয়ারে থাকে। @ লেট_মে_বি প্যাকেজ পরিচালকের বাইরে থেকে প্রোগ্রাম ইনস্টল করা পুরোপুরি ঠিক আছে এবং প্রায়শই প্রয়োজন হতে পারে।
লামার বি

@ সার্জে: যদি আপনার কাছে দুটি কম্পিউটার থাকে তবে একই মাধ্যম থেকে ইনস্টল করা হয়েছে এবং পরে সেগুলির মধ্যে একটিতে ম্যানুয়ালি কিছু সফ্টওয়্যার যুক্ত করা হয়েছে, traditionতিহ্যগতভাবে এটি / ইউএসআর / লোকাল হিসাবে চলে যাবে কারণ এটি সেই মেশিনের স্থানীয় এবং "স্ট্যান্ডার্ড" এর অংশ নয় বিক্রেতা দ্বারা সরবরাহিত প্রোগ্রামের সেট। যেমনটি অন্যেরা বলেছেন, আজকাল এই historicalতিহাসিক অনুশীলনটি প্যাকেজ বিল্ডারদের দ্বারা খুব বেশি অনুসরণ করা হয় না - আমি মনে করি যে স্ট্যান্ডার্ড সংগ্রহস্থলের সফ্টওয়্যারটি ব্যবহারকারী-ইনস্টল করা স্থানীয় কাস্টমাইজেশনের পরিবর্তে কার্যকরভাবে বিক্রেতা-সরবরাহিত alচ্ছিক সফ্টওয়্যার হিসাবে বেশি বিবেচিত হয়।
রেডগ্রিটিব্রিক

3

সমস্ত * / sbin ডিরেক্টরিতে স্টাফ কেবল সিস্টেম প্রশাসকদের জন্য কার্যকর। আপনি যদি একজন সাধারণ ব্যবহারকারী হন তবে আপনি এগুলিকে আপনার পথ থেকে দূরে রাখতে পারেন।

আপনার যদি একটি একক ডিস্কে একটি একক ইউনিক্স মেশিন থাকে তবে বিভিন্ন ডিরেক্টরি খুব বেশি বোঝাতে পারে না, তবে আপনার যদি একটি বড় সিস্টেম এবং বিভিন্ন পার্টিশন থাকে তবে আরও বোধগম্য হন। মনে রাখবেন যে সিস্টেমগুলি কিছুটা আলাদা ছিল তখন এই অভ্যাসগুলির অনেকগুলি 80 এবং 90 এর দশকে তৈরি হয়েছিল।

/sbinখুব ছোট হতে থাকে । এগুলি এমন ইউটিলিটিগুলি যা আপনার প্রয়োজন যখন সত্যই হোস্ট করা হয়। আপনি এটিকে / root এবং / lib সহ ন্যূনতম মূল বিভাজনে রাখতে চাইবেন। / এসবিনে থাকা জিনিসগুলি সমস্ত স্থিতিশীলভাবে সংযুক্ত হত, যেহেতু আপনার / usr পার্টিশনটি যদি হোস করা থাকে তবে যে কোনও গতিযুক্ত লিঙ্কযুক্ত অ্যাপ্লিকেশন অকেজো। fsck এখানে এবং স্থিতিযুক্ত লিঙ্কযুক্ত। আপনার যদি / usr এর উপর নির্ভরশীলতা থাকে তবে স্পষ্টতই আপনি fsck / usr / করতে পারবেন না। অবশ্যই, যদি রুট পার্টিশনটি হোস করা হয় তবে আপনি খুব খারাপ হয়ে গেছেন। এই কারণেই এটি একটি ছোট পার্টিশন - খুব কম ব্লক ব্যবহার করে এখানে খারাপ ডিস্ক ব্লকের প্রতিক্রিয়া কমিয়ে নিন।

/usr/sbinবাইনারিগুলি সাধারণ সিসাদমিন সরঞ্জাম যেখানে আপনি কমপক্ষে একক ব্যবহারকারী মোডে যেতে পারেন এবং আপনার সমস্ত ভলিউম মাউন্ট করতে পারেন। এগুলি গতিশীলভাবে সংযুক্ত হওয়ার অনুমতি রয়েছে।

/ এসবিনের জন্য পৃথক পার্টিশন (ভাল / / পার্টিশনের উপর সবিন) এবং / ইউএসআর যখন আরও মনে রাখবেন যে ব্যাকআপ উভয় সময়ে এবং টেপের জন্য খুব ব্যয়বহুল ছিল। যদি তারা পৃথক পার্টিশনে থাকে তবে আপনি এগুলি আলাদাভাবে নির্ধারণ করতে পারবেন।

/usr/localএকটি নেটওয়ার্ক ফাইল সিস্টেম হতে পারে। স্থানীয়ভাবে লিখিত সিসাদমিন সরঞ্জামগুলি যা অনেকগুলি মেশিনে ভাগ করা যায় কখনও কখনও / usr / স্থানীয় / এসবিনে যায়। স্পষ্টতই কোনও নেটওয়ার্ক ফিক্সিং ব্যবহারগুলি সেখানে যেতে পারে না।

আবার একাধিক ভলিউমযুক্ত পরিচালিত মেশিনে নেটওয়ার্কযুক্ত পরিবেশে বড় বড় মেশিনগুলিতে প্রচুর পরিমাণে আরও বেশি বোঝা যায়, একক রুট পার্টিশনের জন্য একটি লিনাক্স মেশিনের চেয়ে কম।


2

আপনার সত্যিই আপনার দ্বিতীয় প্রশ্নটি সুপারইউসারটিতে আলাদা প্রশ্ন হওয়া উচিত। এটি প্রথমটির সাথে সম্পর্কিত নয়।

হ্যাঁ, সমস্ত জায়গাতেই ফাইল থাকা সফল হয়। এজন্য অনেকগুলি প্যাকেজিং সমাধান রয়েছে। রেডহ্যাট আরপিএম তৈরি করেছে যা সর্বত্র ব্যবহৃত হয়। সোলারিসের তাদের প্যাকেজ ফর্ম্যাট ছিল। এইচপি / ইউএক্স এর ছিল এবং এপিসে এবং অন্যান্য অনেকগুলি প্যাকেজ ফর্ম্যাট রয়েছে। জিনিসগুলিকে যথাযথ স্থানে (/ usr / bin, / usr / lib) যথাযথভাবে রাখুন তবে সহজেই যোগ এবং অপসারণের অনুমতি দিন।

উত্সের জন্য, এমন সরঞ্জামগুলি ব্যবহৃত হত যা আপনাকে / usr / স্থানীয় একটি সাবডিরের মধ্যে কনফিগার করতে এবং ইনস্টল করতে দেয় এবং এটি আপনার জন্য / usr / স্থানীয় / বিনে সিমলিংকগুলি পরিচালনা করবে। যেহেতু প্যাকেজ সরঞ্জামগুলির বিস্তৃত বিস্তার, এটি কম প্রয়োজন, এবং আমি তাদের নাম ভুলে গিয়েছি।

কিছু লোকেরা / অপ্ট / প্যাকেজনেম ইনস্টল করতে এবং সেখানে সমস্ত কিছু একসাথে রাখতে পছন্দ করে। ভাল: সবকিছুই একটি ডিরেক্টরিতে থাকে এবং একটি আনইনস্টল হয় rm -rf /opt/packagename। এর ডাউনসাইডগুলি প্রত্যেকের পাথের সাথে / অপ্ট / প্যাকেজ নাম / বিন যোগ করতে হয় এবং লোকেরা সাধারণত একটি পৃথক পার্টিশন পছন্দ করে না এবং আপনি মূল বিভাজনটি পূরণ করেন।


1
আরপিএম সর্বত্র ব্যবহৃত হয়? দেবিয়ান ফর্ম্যাটটি সর্বত্র ব্যবহৃত হয়েছে তা কি সত্যের কাছাকাছি হবে না?
আইকনোক্লাস্ট

আমি যুক্তি দিয়েছিলাম যে ডিপি যেমন হ'ল আরপিএম ঠিক ততটাই ততোধিক। এটি আপনি কোথায় কাজ করেন তার উপর এটি অনেকটা নির্ভর করে: ওপেন সোর্স সম্প্রদায়ে, আমি মনে করি ডিবিয়ান-ভিত্তিক প্যাকেজগুলির সাথে লিনাক্স ডেস্কটপ এবং লিনাক্স সার্ভারের দিকে ঝোঁক রয়েছে। কর্পোরেট পরিবেশে, লিনাক্স প্রায়শই রেড হ্যাট সুসংগত (যেমন CentOS, RHEL, ওরাকল লিনাক্স ইত্যাদি) সমান হয় বা "রেড হ্যাট বা এসএলইএস" হিসাবে সংজ্ঞায়িত হয় এবং এভাবে আবার সমস্ত আরপিএম :)
লিনাক্স-ফ্যান

1

ডিরেক্টরিগুলির অর্থ গ্রহণ করা (ডেবিয়ান জিএনইউ লিনাক্সের অভিজ্ঞতা থেকে) এটি হ'ল:

প্রথম পার্থক্য: sসুপারভাইজারের জন্য

sকোনও binডিরেক্টরিতে ইঙ্গিত করার আগে এটিতে এমন সরঞ্জাম রয়েছে যা সাধারণত প্রশাসকদের পক্ষে কার্যকর। নোট করুন যে উদাহরণস্বরূপ ifconfigএটিও এই বিভাগের অন্তর্ভুক্ত এবং আমি ifconfigএকটি নিয়মিত ব্যবহারকারীর হিসাবে প্রার্থনা করতে চাই (আমি কোনও আইপি ঠিকানা / নেটওয়ার্ক সংযোগ পেয়েছি কিনা তা পরীক্ষা করতে) যা এই পার্থক্যটিকে ততটা কঠিন মনে হয় না যতটা মনে হয়।

দ্বিতীয় পার্থক্য: local"স্থানীয় ডেটা" এর জন্য

অনুশীলনে, এখানে সর্বাধিক গুরুত্বপূর্ণ পার্থক্য হ'ল ওএস প্যাকেজ ম্যানেজাররা (এপিটি-র মতো) সাধারণ /usrকাঠামোতে প্যাকেজ ইনস্টল করে এবং /usr/localপ্রভাবিত না করে। এটি স্থানীয়ভাবে সংকলিত প্যাকেজগুলি বা সিস্টেম প্রশাসক দ্বারা সরবরাহিত সংস্থা-অভ্যন্তরীণ স্ক্রিপ্টগুলি এমন স্থানে স্থাপন /usr/localকরতে অনুমতি দেয় যেখানে তারা কখনই সঠিকভাবে প্যাকেজযুক্ত ফাইলগুলিতে হস্তক্ষেপ করবে না।

এটি /usr/localসাধারণ /usrকাঠামো থেকে বিদ্যমান ফাইলগুলিকে ওভাররাইড করা উচিত কিনা তা বিতর্কযোগ্য , দেখুন কোনও ব্যক্তির প্যাথ-এ / ইউএসআর / বিনের আগে / ইউএসআর / স্থানীয় / বিন রাখা কি বিপজ্জনক? এই সম্পর্কে কিছু বিশদ জন্য।

তৃতীয় পার্থক্য: শীর্ষ স্তর /binএবং /sbinডিরেক্টরি।

দেবিয়ান -তে আসলে একটি তথাকথিত উসরমার্জ রয়েছে । সেখানে পার্থক্য হল যে ব্যবহার করা হয় /binএবং /sbinবুট প্রক্রিয়া শুরুর দিকে পাওয়া যেত (মনে /usrএকটি নেটওয়ার্ক ডিভাইস বা বিভিন্ন পার্টিশন, RAID- প্রভৃতি হচ্ছে), কিন্তু nowdays কয়েক লিনাক্স অপারেটিং সিস্টেমে ভাল বুট ছাড়া /usrযার কারণে আমি top- মধ্যে পার্থক্য বিবেচনা করবে /usrলিনাক্সের জন্য level তিহাসিক আগ্রহের জন্য স্তর এবং ডিরেক্টরিগুলি।

শেষ অবধি: "বিক্ষিপ্ত" ফাইলগুলির যোগ্যতা এবং সমস্যা।

এর সত্যিকার অর্থে কোনও "সত্য সত্য" নেই। লিনাক্সের বিক্ষিপ্ত ফাইল সিস্টেমের সুবিধাগুলি হ'ল:

  • সমস্ত বাইনারি কয়েকটি ডিরেক্টরিতে থাকে। এর অর্থ আপনি শেল থেকে প্রতিটি প্রোগ্রাম কল করতে পারেন। উইন্ডোটির সাথে তুলনা করুন, যেখানে %PATH%আগ্রহের কোনও প্রোগ্রাম যুক্ত করতে সর্বদা পরিবেশের পরিবর্তনশীলকে সম্পাদনা করতে হবে । আমি উইন্ডোজটিতে খুব দীর্ঘ পথের পরিবেশ দেখেছি।

  • সমস্ত গ্রন্থাগার একটি কেন্দ্রীয় জায়গায় থাকে। এর অর্থ একাধিক অ্যাপ্লিকেশন ব্যবহার করার সময় এগুলি দুটিবার ইনস্টল করার দরকার নেই।

  • যেহেতু লিনাক্স ডিজাইন করা হয়েছে বেশিরভাগ সিস্টেমে ফাইলগুলি প্যাকেজ ম্যানেজার দ্বারা ট্র্যাক করা হয় , তাই ব্যবহারকারীদের দৃষ্টিকোণ থেকে ফাইলগুলির ওভারভিউ রাখার দরকার নেই।

  • FHS প্রমিতকরণ দরুন, ডকুমেন্টেশন কেন্দ্রীয় স্থান সিস্টেম যার ফলে পছন্দ মধ্যে থাকা man, infoআশানুরূপ কাজ এবং সহায়ক README ফাইল।

  • কোনও নির্দিষ্ট স্থানে ইনস্টল করা কোনও প্রোগ্রামের উপর নির্ভর করা সহজ। #!/bin/sh -eস্ক্রিপ্টগুলির শুরুতে প্রত্যেকেই লেখেন বা অনুরূপ এবং এটি কেবল কার্যকর । এমন একটি সিস্টেম বিবেচনা করুন যেখানে শেলটি একটি পৃথক ডিরেক্টরিতে যাবে: কীভাবে এটি কী নাম নেবে তা কীভাবে জানবে? যদি আগ্রহী হয়, উইন্ডোজে পার্ল বা ল্যাটেক্স ইনস্টল করার বিভিন্ন উপায় পরীক্ষা করে দেখুন কীভাবে এটি জটিল হতে পারে ...

আমি এখনও অবধি যে অসুবিধাগুলি পেয়েছি সেগুলি হ'ল:

  • সাধারণত, "উইন্ডোজের জন্য পোর্টেবল অ্যাপ্লিকেশন" অর্থে অ্যাপ্লিকেশনগুলি "পোর্টেবল" চালানো আরও কঠিন। লিনাক্সে, কেবলমাত্র অন্য কম্পিউটারে প্রোগ্রামটি অনুলিপি করা এত সহজ নয় ... একটি প্যাকেজ থাকা দরকার (যার জন্য রুট অনুমতি প্রয়োজন) অথবা LD_LIBRARY_PATHরিক্যুয়াইড লাইব্রেরির জন্য বিভিন্ন অনুসন্ধানের জন্য অ্যাপ্লিকেশনগুলিকে নির্দেশ করার জন্য ডিল করতে হবে।

  • একই প্রোগ্রামের একাধিক সংস্করণ ইনস্টল করার জন্য স্পষ্টভাবে সমর্থন করা দরকার যেখানে "প্রতি প্রোগ্রামের জন্য একটি ডিরেক্টরি" থাকা সিস্টেমগুলিতে এটি প্রায়শই কম থাকে।

  • প্যাকেজ পরিচালক ব্যতীত ফাইল পরিচালনা করা ত্রুটি-প্রবণ (ইতিমধ্যে উল্লিখিত)।


0

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

make

এবং এটি দিয়ে ইনস্টল করুন

make install

আপনি সাধারণত করতে পারেন

make uninstall

যা ফাইল সিস্টেম থেকে ফাইলগুলি মুছে দেয়।


মেক আনইনস্টল কেবল প্রোগ্রামারের মাধ্যমেই করা যেতে পারে এই প্রক্রিয়াটি মেক ফাইলটিতে যুক্ত করে। প্রশ্নটি ছিল - আনইনস্টলগুলি যেভাবে কাজ করে না তাদের কীভাবে মুছবেন?
সের্গেই

1
সঠিক, তবে আমি মনে করি মেকফাইলে আনইনস্টল না করে কোনও গুরুতর প্রকল্প খুঁজে পাওয়া বেশ কঠিন (এটিতে কখনও সমস্যা হয়নি)। যদি আপনি উত্স থেকে সংকলন করেন এবং মেকফাইলে আনইনস্টল না থাকে তবে আমি মনে করি এটি করা সহজ উপায় নয় তবে আপনি এখনও একটি স্ক্রিপ্ট লিখতে পারেন make installযা আউটপুটকে বিশ্লেষণ করে এবং সেখানে উল্লিখিত ফাইলগুলি মুছে দেয়।
মতেজ পুনর্লিখন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.