একটি ফাইল কেন / দেব / নাল হয়? কেন এটির কাজটি একটি সাধারণ প্রোগ্রাম হিসাবে প্রয়োগ করা হয় না?

Question

আমি লিনাক্সে বিশেষ ফাইলগুলির ধারণাটি বোঝার চেষ্টা করছি। যাইহোক, একটি বিশেষ ফাইল থাকা /devসহজ স্পষ্ট মনে হয় যখন এটির কাজটি আমার জ্ঞানের সাথে সি এর কয়েকটি মুঠোয় প্রয়োগ করা যেতে পারে।

তবুও আপনি এটি বেশ একই পদ্ধতিতে ব্যবহার করতে পারেন, অর্থাত্ nullপুনঃনির্দেশের পরিবর্তে পাইপিং /dev/null। এটি ফাইল হিসাবে থাকার কোনও নির্দিষ্ট কারণ আছে? এটিকে একটি ফাইল বানানো একই ফাইলটিতে অ্যাক্সেস করা অনেকগুলি প্রোগ্রামের মতো আরও অনেক সমস্যার কারণ হয়ে দাঁড়ায় না?

Comments

ঘটনাক্রমে, এই ওভারহেডের cat foo | barবেশিরভাগটিই কেন এটি তুলনায় আরও খারাপ (স্কেল) bar <foo। catএকটি তুচ্ছ প্রোগ্রাম, তবুও একটি তুচ্ছ প্রোগ্রাম ব্যয় তৈরি করে (তাদের মধ্যে কিছু ফিফো শব্দার্থবিজ্ঞানের ক্ষেত্রে নির্দিষ্ট - কারণ প্রোগ্রামগুলি ফিফোর seek()ভিতরে থাকতে পারে না , উদাহরণস্বরূপ, এমন একটি প্রোগ্রাম যা সন্ধানের সাথে দক্ষতার সাথে প্রয়োগ করা যেতে পারে আরও অনেক ব্যয়বহুল ক্রিয়াকলাপ শেষ করতে পারে) যখন পাইপলাইন দেওয়া হয়; যেমন অক্ষরযুক্ত ডিভাইসের সাহায্যে /dev/nullসেগুলি অপারেশনগুলিকে নকল করতে পারে, বা একটি বাস্তব ফাইলের সাহায্যে এটি প্রয়োগ করতে পারে তবে কোনও ফিফো কোনও প্রসঙ্গে প্রাসঙ্গিক-সচেতন পরিচালনা পরিচালনা করতে দেয় না)।

— চার্লস ডাফি

grep blablubb file.txt 2>/dev/null && dosomethingনাল একটি প্রোগ্রাম বা একটি ফাংশন হচ্ছে সঙ্গে কাজ করতে পারে না।

— রেক্সকোগিটানস

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

— mtraceur

পাশাপাশি কেউ ইশারা যেমন করে একটি ডিভাইস ড্রাইভার কার্নেল স্থান চলমান হয় সঙ্গে "C- এর লাইনের একটি থাবা" একটি প্রোগ্রাম , উত্তর কেউই এখন পর্যন্ত আসলে "একই ফাইল অ্যাক্সেস অনেকগুলি প্রোগ্রাম" এর অনুমান করেছেন প্রশ্নে।

— জেডিবিপি

রে "নিজের কাজের সি লাইনের একটি থাবা দ্বারা বাস্তবায়িত করা যেতে পারে": আপনি এটা বিশ্বাস করবে না, কিন্তু এটা করা হয় সি লাইনের একটি থাবা দ্বারা বাস্তবায়িত! উদাহরণস্বরূপ, এর জন্য readফাংশনের মূল অংশটি /dev/null"রিটার্ন 0" (যার অর্থ এটি কোনও কিছু করে না এবং আমি মনে করি, কোনও ইওএফের ফলাফল দেয়) নিয়ে গঠিত: (স্ট্যাটিক গিথুব.com/torvalds/linux/blob/master/ ড্রাইভার / চর / ম্যাম.কম ) ssize_t read_null(struct file *file, char __user *buf, size_t count, loff_t *ppos) { return 0; }(ওহ, আমি কেবল দেখতে পাচ্ছি যে @ জেডিবিপি ইতিমধ্যে এটি তৈরি করেছে Any যাইহোক, এখানে চিত্রণ রয়েছে :-)।

— পিটার এ স্নাইডার

Answer 1

একটি চরিত্র-বিশেষ ডিভাইস ব্যবহার করে কর্মক্ষমতা সুবিধা ছাড়াও, প্রাথমিক সুবিধাটি হ'ল পরিমিতি । / শ / পাইপলাইন কেবল শেল পাইপলাইনে নয়, কোনও ফাইল প্রত্যাশিত প্রায় কোনও প্রসঙ্গে ব্যবহার করা যেতে পারে। প্রোগ্রামগুলি বিবেচনা করুন যা কমান্ড-লাইন পরামিতি হিসাবে ফাইলগুলি গ্রহণ করে।

# We don't care about log output.
$ frobify --log-file=/dev/null

# We are not interested in the compiled binary, just seeing if there are errors.
$ gcc foo.c -o /dev/null  || echo "foo.c does not compile!".

# Easy way to force an empty list of exceptions.
$ start_firewall --exception_list=/dev/null

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

# Suppress errors, but print output.
$ grep foo * 2>/dev/null

Comments

এছাড়াও আপনি /dev/nullকেবল শেল কমান্ড ব্যবহার করবেন না । আপনি এটি কোনও সফ্টওয়্যার সরবরাহিত অন্যান্য পরামিতিতে ব্যবহার করতে পারেন --- উদাহরণস্বরূপ কনফিগারেশন ফাইলগুলিতে। --- সফ্টওয়্যারটি ফোর্ট এটি খুব সুবিধাজনক। এটিতে /dev/nullএবং নিয়মিত ফাইলের মধ্যে পার্থক্য করার প্রয়োজন হয় না ।

— পাবউক

আমি নিশ্চিত নই যে এক্সিকিউটেবলগুলি ডুবানো পৃথক পুনঃনির্দেশগুলির অংশটি আমি বুঝতে পেরেছি difficult সি তে, আপনি কেবল একটি pipe, forkএবং execveঅন্য কোনও প্রক্রিয়া পাইপিংয়ের মতো করেন, কেবলমাত্র dup2সংযোগগুলি সেট আপ করার কলগুলিতে পরিবর্তন আছে ? এটা সত্য সবচেয়ে শাঁস যে কাজ করতে সুন্দরতম উপায়ে প্রস্তাব না কিন্তু সম্ভবতঃ আমরা যদি এত ডিভাইস হিসাবে ফাইল প্যাটার্ন ছিল না এবং কিছু অধিকাংশ /devএবং /procএক্সেকিউটেবল হওয়ার উপক্রম হয়েছিল, শাঁস উপায় সহ ডিজাইন করা যেত আমরা এখন পুনঃনির্দেশ হিসাবে এটি সহজেই করতে।

— aschepler

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

— কিউবিক

আপনি কি ভুলে গেছেন wait4! আপনি সঠিক, POSIX এপিস ব্যবহার করে স্টাডাউট এবং স্টার্ডারকে বিভিন্ন প্রোগ্রামে পাইপ দেওয়া সম্ভব এবং স্টাডআউট এবং স্টডারকে বিভিন্ন কমান্ডে পুনঃনির্দেশের জন্য একটি চৌকস শেল সিনট্যাক্স উদ্ভাবন করা সম্ভব। যাইহোক, আমি এখনই এই জাতীয় কোনও শেল সম্পর্কে অবগত নই এবং বৃহত্তর বিষয়টি হ'ল / ডিভ / নাল বিদ্যমান টুলিংয়ের সাথে (যা মূলত ফাইলগুলির সাথে কাজ করে) খুব সুন্দরভাবে ফিট করে এবং / বিন / নাল তা করবে না। আমরা কিছু আই এপিআই এটি হিসাবে সহজ একটি ফাইল যেমন একটি প্রোগ্রাম করতে (! নিরাপদে) আউটপুট জিসিসি করে তোলে কল্পনা করতে পারে, কিন্তু যে অবস্থা আমরা হয় না।

— ioctl

শেল সংক্রান্ত @ioctl; কমপক্ষে zsh এবং বাশ উভয়ই আপনাকে এমন কিছু করার অনুমতি দেয় grep localhost /dev/ /etc/hosts 2> >(sed 's/^/STDERR:/' > errfile ) > >(sed 's/^/STDOUT:/' > outfile), ফলস্বরূপ পৃথকভাবে প্রক্রিয়াজাত করা হয় errfileএবংoutfile

— মতিজা নালিস

Answer 2

ন্যায়বিচারে, এটি প্রতি সেচের নিয়মিত ফাইল নয় ; এটি একটি চরিত্র বিশেষ ডিভাইস :

$ file /dev/null
/dev/null: character special (3/2)

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

Comments

cat file | nullপ্রথমে অনেকগুলি ওভারহেড থাকবে, প্রথমে পাইপ স্থাপনের সময়, একটি প্রক্রিয়া তৈরি করে, নতুন প্রক্রিয়াতে "নাল" চালানো ইত্যাদি Also এছাড়াও, nullনিজেই একটি লুপ রিডিং বাইটে সিপিইউ বেশ কিছুটা ব্যাটারে পরে ব্যবহার করবে that সবে ফেলে দেওয়া হয়েছে ... /dev/nullকার্নেলের মধ্যে প্রয়োগটি সেভাবে আরও কার্যকর। এছাড়াও, আপনি যদি /dev/nullপুনর্নির্দেশের পরিবর্তে যুক্তি হিসাবে পাস করতে চান তবে কী হবে ? (আপনি <(...)

— ব্যাশে

যদি আপনাকে nullপুনঃনির্দেশের পরিবর্তে নামক একটি প্রোগ্রামে পাইপ করতে হয় তবে /dev/nullশেলটিকে কোনও প্রোগ্রাম চালানোর জন্য শেলকে বলার কোনও সহজ, স্পষ্ট উপায় কি কেবল তার স্টাডারকে নালায় পাঠাতে হবে?

— মার্ক প্লটনিক

ওভারহেড প্রদর্শনের জন্য এটি সত্যিই ব্যয়বহুল সেটআপ। আমি /dev/zeroপরিবর্তে ব্যবহার করার পরামর্শ দিতে হবে।

— ক্রাইলিস

সেই উদাহরণগুলি ভুল। dd of=-নামক একটি ফাইলে লেখেন -, স্ট্যান্ডআউটে of=লেখার জন্য বাদ দিন কেবল সেখানে ddডিফল্টরূপে লেখেন। পাইপিং এর স্টিডিনটি না পড়ায় falseকাজ করবে না false, সুতরাং ddসাইনপাইপ দিয়ে হত্যা করা হবে। কমান্ড যে তার ইনপুট আপনি ব্যবহার করতে পারেন বর্জন জন্য ... cat > /dev/null। এছাড়াও তুলনা যারা সম্ভবত বোতল ঘাড় হিসাবে অপ্রাসঙ্গিক সম্ভবত এখানে এলোমেলো সংখ্যা জেনারেশন হতে পারে।

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

ddইত্যাদির এএসটি সংস্করণগুলি যখন গন্তব্যটি / ডিভ / নাল সনাক্ত করে তখন কোনও রাইটিং সিস্কেল করেও বিরক্ত করে না।

— মার্ক প্লটনিক

Answer 3

আমি সন্দেহ করি যে ইউনিক্স (এবং ফলস্বরূপ লিনাক্স) আকারের দৃষ্টিভঙ্গি / ডিজাইনের সাথে কেন অনেক কিছু আছে এবং এর থেকে প্রাপ্ত সুবিধাগুলি।

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

বলুন আপনার কাছে আপনার nullকমান্ড-লাইন প্রোগ্রাম এবং /dev/nullডিভাইস নোড রয়েছে। শেল-স্ক্রিপ্টিং দৃষ্টিকোণ থেকে, foo | nullপ্রোগ্রামটি প্রকৃতপক্ষে আসল উপকারী এবং সুবিধাজনক , foo >/dev/nullটাইপ করতে খুব সামান্য সময় নেয় এবং অদ্ভুত বলে মনে হতে পারে।

তবে এখানে দুটি অনুশীলন:

1. কর্মসূচির বাস্তবায়ন শুরু করা যাক nullবিদ্যমান ইউনিক্স সরঞ্জাম ও ব্যবহার /dev/null- সহজ: cat >/dev/null। সম্পন্ন.

2. আপনি বাস্তবায়ন করতে পারেন /dev/nullপরিপ্রেক্ষিতে null?

আপনি একেবারে ঠিক বলেছেন যে স্রেফ ইনপুট ফেলে দেওয়ার জন্য সি কোডটি তুচ্ছ, সুতরাং এটি এখনও স্পষ্ট হতে পারে না যে কার্যটির জন্য ভার্চুয়াল ফাইল উপলব্ধ থাকা কেন এটি কার্যকর।

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

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

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

লক্ষ্য করুন যে এর কমনীয়তাটি হ'ল সমস্ত জড়িত প্রোগ্রামগুলির কোড জটিলতা হ্রাস করে - প্রতিটি সাধারণ-তবে-বিশেষ ব্যবহারের জন্য যা আপনার সিস্টেম একটি প্রকৃত "ফাইল নাম" সহ "ফাইল" হিসাবে সরবরাহ করতে পারে, আপনার কোডটি কাস্টম কমান্ড যুক্ত এড়াতে পারে হ্যান্ডল করার জন্য লাইন বিকল্প এবং কাস্টম কোড পাথ path

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

"সবকিছুই একটি ফাইল" সম্পদ অ্যাক্সেসের জন্য openএটির একটি রূপক বলে মনে হয়: আপনি একটি উত্তরাধিকারসূত্রে নেমস্পেসে প্রদত্ত একটি পথের ডাক দেন, বস্তুর সাথে একটি রেফারেন্স (ফাইল বর্ণনাকারী) পেতে পারেন readএবং আপনি writeফাইল ডেস্ক্রিপ্টারগুলিতে এবং ইত্যাদি করতে পারেন । আপনার স্টিডিন / স্টাডাউট / স্ট্ডার হ'ল ফাইল বর্ণনাকারী যা কেবল আপনার জন্য প্রাক-খোলার হয়ে গেছে। আপনার পাইপগুলি কেবল ফাইল এবং ফাইল বর্ণনাকারী এবং ফাইল পুনঃনির্দেশ আপনাকে এই সমস্ত টুকরা একসাথে আঠালো করতে দেয়।

এই বিমূর্তগুলি একসাথে কতটা ভালভাবে কাজ করেছে, এবং ইউনিক্স অংশটির মতোই সফল হয়েছিল, এবং /dev/nullপুরোটির অংশ হিসাবে এটি সবচেয়ে ভাল বোঝা যায়।

---

পিএস এটি "সবকিছুই একটি ফাইল" এর ইউনিক্স সংস্করণ এবং মূল্যবান /dev/nullরূপকটির আরও নমনীয় এবং শক্তিশালী জেনারালাইজেশনের দিকে প্রথম পদক্ষেপের মতো জিনিসগুলি অনুসরণ করে যা অনেকগুলি সিস্টেমে প্রয়োগ করা হয়েছিল at

উদাহরণস্বরূপ, ইউনিক্সে বিশেষ ফাইল-জাতীয় বস্তুর মতো /dev/nullকার্নেলটি নিজেই প্রয়োগ করা উচিত ছিল, তবে দেখা গেছে যে ফাইল / ফোল্ডার আকারে কার্যকারিতা প্রকাশ করার পক্ষে এটি যথেষ্ট কার্যকর যে তখন থেকে একাধিক সিস্টেম প্রোগ্রামগুলির জন্য একটি উপায় সরবরাহ করে that এটা করতে.

প্রথমটির মধ্যে একটি প্ল্যান 9 অপারেটিং সিস্টেম ছিল, যা ইউনিক্স তৈরি করা একই ব্যক্তিদের দ্বারা তৈরি হয়েছিল। পরে, জিএনইউ হার্ড এর "অনুবাদকদের" সাথে একই রকম কিছু করেছিল। এদিকে, লিনাক্স FUSE পেয়েছে (যা এখন অন্য মূলধারার সিস্টেমেও ছড়িয়ে পড়েছে)।

Comments

@ পিটারকর্ডস উত্তরটির পয়েন্টটি ডিজাইন না বুঝার অবস্থান থেকে শুরু করছে। প্রত্যেকে যদি নকশাটি ইতিমধ্যে বুঝতে পারে তবে এই প্রশ্নটির অস্তিত্ব থাকবে না।

— অরেঞ্জডগ

@ এমট্রেসুর: রুটের অনুমতি ছাড়াই একটি ছবি ফাইল মাউন্ট করবেন? কিছু প্রমাণ দেখায় যে ফুসের জন্য মূলের প্রয়োজন হবে না, তবে আমি নিশ্চিত নই।

— পিটার কর্ডেস

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

— mtraceur

ইউনিক্সের সাথে একজন তরুণ ইঞ্জিনিয়ার হিসাবে আমাকে প্রথম যে কথাটি বলা হয়েছিল তা হ'ল "সবকিছুই একটি ফাইল" এবং আমি কসম খেয়েছি যে আপনি রাজধানী শুনতে পেলেন। এবং প্রাথমিকভাবে এই ধারণাটি ধরে রাখা ইউনিক্স / লিনাক্সকে বোঝার জন্য আরও অনেক সহজ মনে হয়। লিনাক্স সেই নকশার দর্শনের বেশিরভাগই উত্তরাধিকার সূত্রে পেয়েছিল। আমি খুশি যে কেউ এটি উল্লেখ করেছে।

— স্টিফেনজি

@ পিটারকর্ডস, ডস NULপ্রতিটি ডিরেক্টরিতে ম্যাজিক ফাইলের নামটি উপস্থিত করে টাইপিংয়ের সমস্যাটিকে "সমাধান" করেছে , অর্থাৎ আপনার টাইপ করা সমস্ত হ'ল > NUL।

— ক্রিশ্চিয়ান সিউপিতু

Answer 4

আমি মনে করি পারফরম্যান্সের কারণে প্রোগ্রামমের পরিবর্তে /dev/nullএকটি চরিত্রের ডিভাইস (যা একটি সাধারণ ফাইলের মতো আচরণ করে) ।

এটি যদি কোনও প্রোগ্রাম হয় তবে এটি লোডিং, শুরু, সময়সূচী, চলমান এবং পরে প্রোগ্রামটি বন্ধ করে এবং আনলোড করা প্রয়োজন require আপনি যে সাধারণ সি প্রোগ্রামটি বর্ণনা করছেন সেটি অবশ্যই প্রচুর রিসোর্স গ্রহণ করবে না, তবে আমি মনে করি যে প্রক্রিয়া পরিচালন ক্রিয়াকলাপগুলি বিশাল আকারে ব্যয়বহুল হিসাবে বৃহত সংখ্যক (লক্ষ লক্ষ) পুনর্নির্দেশ / পাইপিং ক্রিয়াকে বিবেচনা করার সময় এটি একটি তাত্পর্যপূর্ণ হয় makes তারা প্রসঙ্গ সুইচ জড়িত।

আরেকটি অনুমান: একটি প্রোগ্রামে পাইপ দেওয়ার জন্য গ্রহনযোগ্য প্রোগ্রামের দ্বারা মেমরি বরাদ্দ করা প্রয়োজন (এমনকি যদি এটি সরাসরি পরে ফেলে দেওয়া হয়)। আপনি যদি সেই সরঞ্জামটিতে পাইপ করেন তবে একবার প্রেরণ প্রোগ্রামে এবং পুনরায় গ্রহণের প্রোগ্রামে আপনার দ্বিগুণ মেমরি খরচ হয়।

Comments

এটি কেবল সেটআপ ব্যয় নয়, পাইপের প্রতিটি লেখার জন্য মেমরির অনুলিপি এবং পড়ার প্রোগ্রামে প্রসঙ্গে একটি স্যুইচ প্রয়োজন। (বা পাইপ বাফার পূর্ণ হয়ে গেলে কমপক্ষে একটি প্রসঙ্গ স্যুইচ করুন And এবং পাঠকের যখন readডেটা হবে তখন অন্য একটি অনুলিপি করতে হবে )। এটি ইউনিক্স ডিজাইন করা এমন একক-কোর পিডিপি -11 এ নগন্য নয়! স্মৃতি ব্যান্ডউইথ / অনুলিপি আজকের তুলনায় অনেক সস্তা। writeএফডি চালু থাকা একটি সিস্টেম কল /dev/nullএমনকি বাফার থেকে কোনও ডেটা না পড়েই সরাসরি ফিরে আসতে পারে।

— পিটার কর্ডেস

@ পিটারকর্ডস, আমার নোটটি স্পর্শকাতর, তবে এটি সম্ভবত সম্ভব যে, স্মৃতিচারণ লেখায় আজকের চেয়ে আগের চেয়ে বেশি ব্যয়বহুল। একটি 8-কোর সিপিইউ সম্ভাব্যভাবে একটি ঘড়ির সময় 16 টি পূর্ণসংখ্যার ক্রিয়াকলাপ সম্পাদন করে, অন্যদিকে শেষ প্রান্তের মেমরি রচনাটি 16 টি ঘড়ি (4GHz সিপিইউ, 250 মেগাহার্টজ র‌্যাম) এ সম্পূর্ণ হয়। এটি 256 এর ফ্যাক্টর the আধুনিক সিপিইউতে র‌্যাম পিডিপি -11 সিপিইউতে একটি আরএল 02 এর মতো, প্রায় পেরিফেরিয়াল স্টোরেজ ইউনিটের মতো! :) সোজাভাবে নয়, স্বাভাবিকভাবেই নয়, তবে ক্যাশে মারতে থাকা সমস্ত কিছুই লিখিত হয়ে যাবে এবং অকেজো লেখাগুলি কখনও কখনও গুরুত্বপূর্ণ ক্যাশে জায়গার অন্যান্য গণনা বঞ্চিত করবে।

— এম

@ কে কে এম: হ্যাঁ, কার্নেলের পাইপ বাফারে প্রায় 3x 128kiB এল 3 ক্যাশে পায়ের ছাপ নষ্ট করে এবং nullপ্রোগ্রামে একটি রিড বাফার চুষতে পারে, তবে বেশিরভাগ মাল্টি-কোর সিপিইউ সব সময় ব্যস্ত সমস্ত কোর দিয়ে চালায় না, তাই nullপ্রোগ্রামটি চালানোর জন্য সিপিইউ সময় বেশিরভাগ বিনামূল্যে। সমস্ত কোর পেগড সহ একটি সিস্টেমে, অকেজো পাইপিং এটি একটি বড় বিষয়। তবে না, একটি "হট" বাফার র‍্যামে ফ্লাশ না হয়ে অনেকবারই আবার লেখা যেতে পারে, তাই আমরা বেশিরভাগ ক্ষেত্রে কেবল ক্যাশে নয়, এল 3 ব্যান্ডউইথের হয়ে প্রতিযোগিতা করছি। দুর্দান্ত নয়, বিশেষত একটি এসএমটি (হাইপারথ্রেডিং) সিস্টেমে যেখানে একই শারীরিক অন্যান্য লজিক্যাল কোর (গুলি) প্রতিযোগিতা করে ...

— পিটার কর্ডস

.... তবে আপনার স্মৃতি গণনা খুব ত্রুটিযুক্ত। আধুনিক CPU- র মেমরি উপমা প্রচুর আছে, তাই যদিও লেটেন্সি ডির্যাম থেকে 200-400 কোর ঘড়ি চক্র ও L3> 40 ভালো কিছু হয়, ব্যান্ডউইডথ ~ 8 বাইট / ঘড়ি। (আশ্চর্যরূপে, এল 3 বা ডিআরএমে একক থ্রেডযুক্ত ব্যান্ডউইথটি কোয়াড-চ্যানেল মেমরি বনাম একটি কোয়াড-কোর ডেস্কটপ সহ বহু-কোর জিয়নে আরও খারাপ , কারণ এটি অনুরোধের সর্বাধিক চুক্তির দ্বারা সীমাবদ্ধ থাকে যে একটি কোর ফ্লাইটে রাখতে পারে band ব্যান্ডউইথ = সর্বাধিক সংশোধন / বিলম্ব: স্কাইলকে ব্রডওয়েল-ই এর চেয়ে একক থ্রেডেড মেমোরি থ্রুপুট জন্য এত ভাল কেন? )

— পিটার কর্ডেস

... কোয়াড-কোর বনাম 18-কোরের তুলনা করে হাসওয়েল সংখ্যার জন্য 7-cpu.com/cpu/Haswell.html দেখুন । যাইহোক, হ্যাঁ আধুনিক সিপিইউগুলি মেমরির জন্য অপেক্ষা না করে যদি তারা প্রতি ঘড়ি প্রতি একটি হাস্যকর পরিমাণ কাজ করতে পারে। আপনার সংখ্যাগুলি প্রতি ঘড়িতে কেবল 2 টি ALU অপারেশন হিসাবে উপস্থিত হতে পারে, যেমন হতে পারে 1993 সালের পেন্টিয়াম বা আধুনিক নিম্ন-শেষের দ্বৈত-ইস্যু এআরএম। একটি রিজেন বা হাসওয়েল সম্ভাব্যভাবে 4 স্কেলার পূর্ণসংখ্যার ALU অপস + 2 মেমরি অপস প্রতি ঘড়ি প্রতি মেমরি অপ্স করে বা সিমডি সহ আরও অনেক কিছু করে। উদাহরণস্বরূপ Skylake-AVX512 (প্রতি কোর) প্রতি 2-ক্লক থ্রুপুট চালু রয়েছে vpaddd zmm: প্রতি নির্দেশে 16 টি 32-বিট উপাদান।

— পিটার কর্ডেস

Answer 5

"সবকিছুই একটি ফাইল" এবং যেহেতু অন্যান্য উত্তরগুলির উপর ভিত্তি করে যে কোনও জায়গায় ব্যবহারের স্বাচ্ছন্দ্য ছাড়াও, @ ব্যবহারকারীর নাম হিসাবেও এখানে পারফরম্যান্স সমস্যা রয়েছে।

অনুশীলনে দেখানোর জন্য, আমরা সাধারণ প্রোগ্রামটি তৈরি করব nullread.c:

#include <unistd.h>
char buf[1024*1024];
int main() {
        while (read(0, buf, sizeof(buf)) > 0);
}

এবং এটি সংকলন gcc -O2 -Wall -W nullread.c -o nullread

(দ্রষ্টব্য: আমরা পাইপগুলিতে lseek (2) ব্যবহার করতে পারি না, তাই পাইপটি খালি করার কেবল উপায় খালি না হওয়া পর্যন্ত এটি থেকে পড়া)।

% time dd if=/dev/zero bs=1M count=5000 |  ./nullread
5242880000 bytes (5,2 GB, 4,9 GiB) copied, 9,33127 s, 562 MB/s
dd if=/dev/zero bs=1M count=5000  0,06s user 5,66s system 61% cpu 9,340 total
./nullread  0,02s user 3,90s system 41% cpu 9,337 total

যদিও স্ট্যান্ডার্ড /dev/nullফাইল পুনঃনির্দেশের সাথে আমরা আরও ভাল গতি পাই (উল্লিখিত তথ্যের কারণে: কম প্রসঙ্গের স্যুইচিং, কার্নেল কেবল ডেটা অনুলিপি করার পরিবর্তে উপেক্ষা করে):

% time dd if=/dev/zero bs=1M count=5000 > /dev/null
5242880000 bytes (5,2 GB, 4,9 GiB) copied, 1,08947 s, 4,8 GB/s
dd if=/dev/zero bs=1M count=5000 > /dev/null  0,01s user 1,08s system 99% cpu 1,094 total

(এটি এখানে একটি মন্তব্য হওয়া উচিত, তবে এটির জন্য খুব বড় এবং এটি সম্পূর্ণ অপঠনযোগ্য হবে)

Comments

আপনি কোন হার্ডওয়্যার পরীক্ষা করেছেন? আমি স্কাইলেক আই 7-6700 কে (ডিডিআর 4-2666) তে যে 23 জিবি / এস পাই তার তুলনায় 4.8 গিগাবাইট / এস বেশ কম, তবে বাফারটি এল 3 ক্যাশে গরম থাকতে হবে So তাই ব্যয়ের একটি ভাল অংশ হ'ল সিস্টেম কলগুলি স্পেকটারের সাথে ব্যয়বহুল হওয়া is + মেল্টডাউন প্রশমনটি সক্ষম করা হয়েছে pip এটি পাইপিংয়ের জন্য দ্বিগুণ ব্যথা করে কারণ পাইপ বাফারগুলি 1M এর চেয়ে ছোট হয়, সুতরাং এটি আরও বেশি লেখার / পড়ার সিস্টেম কল। যদিও আমার প্রত্যাশার চেয়ে প্রায় 10x পারফেক্ট পার্থক্য। আমার স্কাইলেক সিস্টেমে এটি 23 গিগাবাইট / এস বনাম। ৩.৩ জিবি / এস , x86-64 লিনাক্স 4.15.8-1-ARCH চলছে, সুতরাং এটি 6.8 এর একটি কারণ W বাহ, সিস্টেম কলগুলি এখন ব্যয়বহুল )

— পিটার কর্ডস

@ পিটারকর্ডস 3 গিগাবাইট / এস k৪ কে পাইপ বাফার সহ প্রতি সেকেন্ডে 2x 103124 সিস্কল প্রস্তাব দেয় ... এবং সেই সংখ্যার প্রসঙ্গে চলেছে, হি। একটি সার্ভার সিপিইউতে, প্রতি সেকেন্ডে 200000 সিস্কল সহ, আপনি পিটিআই থেকে 8% ডলার ওভারহেড আশা করতে পারেন, যেহেতু খুব সামান্য কাজ করার সেট রয়েছে। (আমি যে গ্রাফটি উল্লেখ করছি তাতে পিসিআইডি অপ্টিমাইজেশন অন্তর্ভুক্ত নয়, তবে এটি ছোট কাজের সেটগুলির জন্য তাত্পর্যপূর্ণ নয়)। সুতরাং আমি নিশ্চিত নই যে পিটিআইয়ের সেখানে বড় প্রভাব আছে? brendangregg.com/blog/2018-02-09/…

— সোর্সজেডি

ওহ আকর্ষণীয়, সুতরাং এটি 2MB এল 2 ক্যাশে সহ একটি সিলভারমন্ট , যাতে আপনার ddবাফার + গ্রহণ বাফারটি ফিট না করে; আপনি সম্ভবত শেষ স্তরের ক্যাশে ব্যান্ডউইদথের পরিবর্তে মেমরি ব্যান্ডউইথের সাথে কাজ করছেন। আপনি 512 কে বাফার বা এমনকি 64 কে বাফার সহ আরও ভাল ব্যান্ডউইথ পেতে পারেন। ( straceআমার ডেস্কটপ অনুসারে , writeএবং read1048576 ফিরছে, তাই আমি মনে করি তার অর্থ আমরা কেবলমাত্র ব্যবহারকারীকে <-> কেবলমাত্র টিবিবি অবৈধকরণের + শাখা-ভবিষ্যদ্বাণী ফ্লাশের ব্যবহারকারীকে প্রদান করছি, @ স্রোকেজেদি প্রতি নয়) প্রশমিতকরণ যার সর্বাধিক ব্যয় হয়েছে, আমি মনে করি)

— পিটার কর্ডেস

@ সোর্সজেডি: স্পেকটার প্রশমন সক্ষম করার সাথে সাথে স্পাইলেটকে সিকিটার সক্রিয়করণ সহ সিকিউইলকে সর্বাধিক 1800 ডলার চক্রের syscallসাথে ফেরত আসার ব্যয় হয় ENOSYS, তার বেশিরভাগই wrmsrবিপিইউকে অকার্যকর করে তোলে, @ বিওনরপের পরীক্ষার অনুসারে । প্রশমন নিষ্ক্রিয় করা সহ, ব্যবহারকারী-> কার্নেল-> ব্যবহারকারী রাউন্ড ট্রিপ সময় 160 ডলার চক্র। কিন্তু আপনি যদি হয় মেমরি স্পর্শ প্রচুর, মেল্টডাউন প্রশমন গুরুত্বপূর্ণ, অত্যধিক। বিশাল পৃষ্ঠাগুলিতে সহায়তা করা উচিত (কম টিএলবি এন্ট্রি পুনরায় লোড করা দরকার)।

— পিটার কর্ডেস

@ পিটারকর্ডস একটি একক কোর ইউনিক্স সিস্টেমে আমরা অবশ্যই 64৪ কে প্রতি ১ টি কনটেক্সট সুইচ দেখতে পাব, বা আপনার পাইপ বাফার যা কিছু ছিল তা ক্ষতিগ্রস্ত করবে ... আসলে আমি [২ টি সিপিইউ কোরের সাথে একই সংখ্যার প্রসঙ্গের স্যুইচ] দেখতে পাচ্ছি] ( unix.stackexchange.com/questions/439260/… ); এটি অবশ্যই প্রসঙ্গের স্যুইচ হিসাবে (কোনও নামমাত্র "অলস প্রক্রিয়াতে") প্রতিটি 64 কে জন্য একটি ঘুম / জাগ্রত চক্র গণনা করতে হবে। একই সিপুতে পাইপলাইন প্রসেসগুলি রাখা আসলে দ্বিগুণের চেয়ে দ্রুত গতিতে কাজ করে।

— সোর্সজেডি

Answer 6

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

তবে বিবেচনা করুন, একটি পাইপও একটি ফাইল । এগুলি সাধারণত নামকরণ করা হয় না এবং তাই কেবল তাদের ফাইল বর্ণনাকারীর মাধ্যমেই তা চালিত করা যায়।

এই কিছুটা স্বীকৃত উদাহরণ বিবেচনা করুন:

$ echo -e 'foo\nbar\nbaz' | grep foo
foo

বাশের প্রক্রিয়া বিকল্প ব্যবহার করে আমরা একই জিনিসটি আরও চারিদিকের পথের মাধ্যমে সম্পাদন করতে পারি:

$ grep foo <(echo -e 'foo\nbar\nbaz')
foo

এর grepজন্য প্রতিস্থাপন করুন echoএবং আমরা কভারগুলির নীচে দেখতে পাচ্ছি:

$ echo foo <(echo -e 'foo\nbar\nbaz')
foo /dev/fd/63

<(...)কনস্ট্রাক্ট শুধু একটি ফাইলের নাম দিয়ে প্রতিস্থাপিত করা হয়, এবং grep মনে এটা কোন পুরানো ফাইল খোলার, এটা ঠিক নামে ঘটবে হচ্ছে /dev/fd/63। এখানে, /dev/fdএকটি যাদু ডিরেক্টরি রয়েছে যা প্রতিটি ফাইল বর্ণনাকারীর জন্য ফাইল অ্যাক্সেস করে এটির জন্য নামযুক্ত পাইপ তৈরি করে।

আমরা একটি সাধারণ ফাইলের মতো mkfifoনামযুক্ত পাইপ তৈরি করতে এবং এটিতে lsসমস্ত কিছু দেখায় এটি কম জাদু করতে পারি :

$ mkfifo foofifo
$ ls -l foofifo 
prw-rw-r-- 1 indigo indigo 0 Apr 19 22:01 foofifo
$ grep foo foofifo

অন্যত্র:

$ echo -e 'foo\nbar\nbaz' > foofifo

এবং দেখুন, গ্রেপ আউটপুট হবে foo।

আমি মনে করি একবার আপনি পাইপ এবং নিয়মিত ফাইল এবং / dev / নাল জাতীয় বিশেষ ফাইলগুলি কেবলমাত্র ফাইল হয়ে গেলে, এটি একটি নাল প্রোগ্রাম বাস্তবায়ন করা আরও জটিল is কার্নেলটি যে কোনও উপায়ে কোনও ফাইলের কাছে রাইটিং হ্যান্ডেল করতে হয়, তবে / dev / নাল ক্ষেত্রে এটি কেবলমাত্র মেঝেতে থাকা লেখাগুলি ফেলে দিতে পারে, অন্যদিকে পাইপের সাহায্যে এটি বাইটসকে অন্য কোনও প্রোগ্রামে স্থানান্তর করতে হয়, যার পরে এটি করতে হয় আসলে তাদের পড়ুন।

Comments

@ লাইল ইয়ে? তাহলে ইকো ছাপবে কেন /dev/fd/63?

— ফিল ফ্রস্ট

হুঁ। ভাল যুক্তি. ঠিক আছে, এটি শাঁস দ্বারা বাস্তবায়ন করা হয়েছে, তাই সম্ভবত আপনার শেলটি পুরানো বোর্ন শেল থেকে আমি বড় হয়েছি তার থেকে আলাদা।

— লাইল

একটি পার্থক্য হ'ল ইকো স্টিডিন থেকে পড়েনি, যখন গ্রেপ করে, তবে আমি ভাবতে পারি না যে শেলটি এটি কার্যকর করার আগে কীভাবে জানতে পারে।

— লাইল

এবং স্ট্রেস এটি পরিষ্কার করে তোলে: আমার জন্য। বাশ সহ আপনার ঠিক ঠিক আছে with '<(...)' কনস্ট্রাক্ট <ফাইলের নাম থেকে বেশ আলাদা কিছু করছে। হুঁ। আমি কিছু শিখেছি।

— লাইল

Answer 7

আমি যুক্তি দিয়ে বলব যে historicalতিহাসিক দৃষ্টান্তগুলি এবং পারফরম্যান্সের বাইরেও সুরক্ষা সমস্যা রয়েছে। সুবিধাপ্রাপ্ত মৃত্যুদণ্ডের শংসাপত্রগুলি সহ প্রোগ্রামের সংখ্যা সীমাবদ্ধ করা সিস্টেম সিকিউরিটির একটি মৌলিক চুক্তি। /dev/nullসিস্টেম পরিষেবাদি ব্যবহারের কারণে কোনও প্রতিস্থাপনের অবশ্যই এই জাতীয় সুযোগগুলি থাকা দরকার। আধুনিক সুরক্ষা কাঠামোগুলি শোষণ প্রতিরোধ করার জন্য দুর্দান্ত কাজ করে তবে সেগুলি বোকা নয়। ফাইল হিসাবে অ্যাক্সেস করা একটি কার্নেল চালিত ডিভাইস শোষণ করা আরও বেশি কঠিন।

Comments

এই বাজে কথা মত। বাগ-ফ্রি কার্নেল ড্রাইভার লেখার জন্য বাগ-ফ্রি প্রোগ্রাম লেখার চেয়ে সহজ কিছু নেই যা এর স্টিডিনটি পড়ে + পড়ে। এটা setuid বা কিছু হওয়ার তাই উভয়ের জন্য দরকার নেই /dev/nullবা প্রস্তাবিত ইনপুট-খারিজ প্রোগ্রাম, হামলা ভেক্টর একই হতে হবে: একটি স্ক্রিপ্ট বা প্রোগ্রাম যা রুট হিসাবে সঞ্চালিত হয় অদ্ভুত কিছু করতে পেতে (চেষ্টা মত lseekমধ্যে /dev/nullঅথবা খোলা এটি একই প্রক্রিয়া থেকে একাধিকবার, বা আইডিকে কী। বা /bin/nullএকটি উদ্ভট পরিবেশ, বা যাই হোক না কেন) দিয়ে ডাকে ।

— পিটার কর্ডেস

Answer 8

অন্যদের ইতিমধ্যে নির্দিষ্ট, /dev/null হয় কোড লাইনের একটি থাবা দিয়ে তৈরি একটি প্রোগ্রাম। এটি কেবল এই যে কোডগুলির এই লাইনগুলি কার্নেলের অংশ।

এটি পরিষ্কার করার জন্য, এখানে লিনাক্স বাস্তবায়ন: একটি অক্ষর ডিভাইস যখন পড়তে বা লিখিত হয় তখন ফাংশনগুলিকে কল করে। /dev/nullকল পাঠানোর জন্য লিখন_নুল , কল পড়ার সময় পাঠানো_নুল , এখানে নিবন্ধিত ।

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

Comments

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

— অঙ্কুর এস

অবশ্যই। আমি কেবল এই উত্তরটি যুক্ত করেছি কারণ প্রকৃত বাস্তবায়নটি মজাদার ছিল (আমি এটি সম্প্রতি আবিষ্কার করেছি), তবে আসল কারণটি অন্যরা কীভাবে নির্দেশ করেছে।

— ম্যাথিউ ময়

আমিও! আমি সম্প্রতি লিনাক্সে ডিভাইসগুলি শিখতে শুরু করেছি এবং উত্তরগুলি বেশ তথ্যপূর্ণ ছিল

— অঙ্কুর এস

Answer 9

আমি আশা করি আপনি / দেব / চার্জেন / দেব / শূন্য এবং / ডি / নাল সহ তাদের মতো অন্যদের সম্পর্কেও অবগত আছেন।

লিনাক্স / ইউনিক্স এর মধ্যে কয়েকটি রয়েছে - এমনভাবে উপলব্ধ করা হয়েছে যাতে লোকেরা ওয়েল রাইটেন কোড ফ্রেগমেটসের ভাল ব্যবহার করতে পারে।

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

জিরো একটি বিদ্যমান ফাইল বা আউটপুট পুরো শূন্যের পপুলেট করার জন্য ডিজাইন করা হয়েছে

/ dev / নাল একই ধারণা মাথায় রেখে অন্য একটি সরঞ্জাম।

আপনার টুলকিটের এই সমস্ত সরঞ্জামের অর্থ হ'ল ডিভাইস বা ফাইল প্রতিস্থাপন হিসাবে আপনার (আপনার নির্দিষ্ট প্রয়োজন) বিবেচনা না করে কোনও বিদ্যমান প্রোগ্রামকে অনন্য কিছু করার আপনার অর্ধেক সুযোগ রয়েছে

আপনার লিনাক্স সংস্করণে কেবলমাত্র কয়েকটি চরিত্রের ডিভাইস দিয়ে কে সবচেয়ে উত্তেজনাপূর্ণ ফলাফল তৈরি করতে পারে তা দেখার জন্য একটি প্রতিযোগিতা সেট আপ করুন।