আমি কেন কোনও পাঠ্য সম্পাদক দিয়ে / dev / stdout পড়তে পারি না?


9

আমি এখনই শিখতে শুরু করেছি যে লিনাক্সে সমস্ত কিছু কীভাবে ফাইল টিএম হয়, যা আমাকে আশ্চর্য করে তোলে যে আমি যদি আক্ষরিক / dev / stdout থেকে পড়ি তবে কী হবে:

$ cat /dev/stdout 
^C
$ tail /dev/stdout 
^C

( ^Cপ্রোগ্রামটি স্থগিত হওয়ার পরে তিনিই আমাকে হত্যা করছেন)।

আমি যখন চেষ্টা করে vimদেখি, কল্পনাতীত বার্তাটি পাই: "/ dev / stdout" কোনও ফাইল নয়। খাবি!

তাহলে কী দেয়, যখন আমি এই "ফাইলগুলি" পড়ার চেষ্টা করব তখন কেন হ্যাঙ্গআপ বা ত্রুটি বার্তা পাচ্ছি?


1
ভিম কোনও ফাইলকে কী বিবেচনা করে এবং * নিক্সে "সবকিছুই একটি ফাইল" (কোনও সম্পর্কিত ট্রেডমার্ক নয়) এর অর্থ কী তা একই জিনিস নয়। যেমন # 1 এবং # 2 দেখুন
স্বর্ণলোকগুলি

উত্তর:


11

আমি কেন হ্যাঙ্গআপ পাচ্ছি?

আপনি "হ্যাঙ্গআপস" পাচ্ছেন না cat(1)এবং tail(1)এগুলি কেবল পড়তে অবরুদ্ধ করছে। cat(1)ইনপুটটির জন্য অপেক্ষা করে এবং এটি একটি সম্পূর্ণ লাইনটি দেখার সাথে সাথে এটি মুদ্রণ করে:

$ cat /dev/stdout
foo
foo
bar
bar

এখানে আমি টাইপ করেছি fooEnterbarEnterCTRL- D

tail(1)ইনপুটটির জন্য অপেক্ষা করে এবং এটি সনাক্ত করতে পারে কেবল তখনই এটি মুদ্রণ করে EOF:

$ tail /dev/stdout
foo
bar
foo
bar

এখানে আমি আবার টাইপ করেছি fooEnterbarEnterCTRL- D

বা ত্রুটি বার্তা

ভিম একমাত্র যা আপনাকে একটি ত্রুটি দেয়। এটি এটি করে কারণ এটি বিপরীতে চলে এবং এটি এটির বিট সেট করে না findsstat(2)/dev/stdoutS_IFREG

/dev/stdoutএকটি ফাইল, তবে নিয়মিত ফাইল নয়। আসলে, ফাইল সিস্টেমে এন্ট্রি দেওয়ার জন্য কার্নেলের মধ্যে কিছু নাচ রয়েছে। লিনাক্সে:

$ ls -l /dev/stdout
lrwxrwxrwx 1 root root 15 May  8 19:42 /dev/stdout -> /proc/self/fd/1

ওপেনবিএসডি তে:

$ ls -l /dev/stdout
crw-rw-rw-  1 root  wheel   22,   1 May  7 09:05:03 2015 /dev/stdout

ফ্রিবিএসডি তে:

$ ls -l /dev/stdout
lrwxr-xr-x  1 root  wheel  4 May  8 21:35 /dev/stdout -> fd/1

$ ls -l /dev/fd/1
crw-rw-rw-  1 root  wheel  0x18 May  8 21:35 /dev/fd/1

5

(প্রায়) সবকিছুই একটি ফাইল তবে সবকিছুই নিয়মিত ফাইল নয়। ডিরেক্টরি, নেটওয়ার্ক সকেট, সিরিয়াল পোর্ট ইত্যাদির মতো একটি বিশেষ ফাইলের জন্য কোনও পাঠ্য সম্পাদককে কল করা কোনও অর্থবোধ করে না

/dev/stdoutইউনিক্স বৈকল্পিকের উপর নির্ভর করে ফাইলটি বেশ কয়েকটি জিনিসের একটি হতে পারে:

  • একটি "বিশেষ" ফাইল, সাধারণত একটি অক্ষর ডিভাইস;
  • একটি "যাদু" প্রতীকী লিঙ্ক যা ফাইলটিতে এটি নির্দেশ করে যে এতে অ্যাক্সেস করার প্রক্রিয়াটি এই বর্ণনাকারীর উপর উন্মুক্ত হয়েছে;
  • উপরের একটিতে একটি প্রতীকী লিঙ্ক।

যে কোনও ক্ষেত্রে, প্রারম্ভিক /dev/stdoutএবং অনুরূপ ফাইলগুলি একটি নতুন ফাইল বর্ণনাকারী তৈরি করে যা একই ফাইলের সাথে সম্পর্কিত যা অ্যাপ্লিকেশনটি ইতিমধ্যে ফাইল বর্ণনাকারী ১ এ খোলা আছে "" স্ট্যান্ডার্ড আউটপুট "মানে ফাইল বর্ণনাকারী 1, এবং এটি কেবল একটি কনভেনশন যে এই ফাইলের বর্ণনাকারী ব্যবহার করা হয় আউটপুট জন্য - কার্নেল যত্ন করে না।

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

আপনি যখন চালনা করেন cat /dev/stdout, ঠিক তেমনই একই কাজটি করে cat /dev/stdinবা cat /dev/stderrকারণ, কারণ এই তিনটি ফাইল বর্ণনাকারী একই ফাইলের সাথে সংযুক্ত: এটি catটার্মিনাল থেকে পড়তে বলে । যে কি catকোন যুক্তি দিয়ে তারাও তাই করছে।

যদি আপনি দৌড়ে থাকেন cat /dev/stdout >fooতবে /dev/stdoutফাইলটি উল্লেখ করা হবে foo- সেই আদেশটি সমান cat foo >foocatবাস্তবায়নের উপর নির্ভর করে , এটি হয় ত্রুটিযুক্ত হতে পারে (জিএনইউ সংস্করণ অভিযোগ করে যে "ইনপুট ফাইল আউটপুট ফাইল"), বা এটি কিছুই করতে পারে না কারণ এটি ফাইলটি fooখালি থেকে পড়ে ( >fooকেবল এটি কেটে গেছে)। এর কোনও সংস্করণে catএই বিশেষ কেসটি সনাক্ত করে না, যদি fooখালি না থাকে, তবে cat /dev/stdout >>fooবা সমতুল্য cat foo >>fooফাইলটির বিষয়বস্তু অনির্দিষ্টকালের জন্য নিজের মধ্যে সংযোজন করবে।

আপনি যখন চালান vim /dev/stdout, এটি অভিযোগ করে কারণ এটি টার্মিনালটি কীভাবে সম্পাদনা করতে হয় তা জানে না (এটি কেবল অর্থবোধ করে না)।


2

catএবং tailফাইলের শেষের পরে alচ্ছিক সামগ্রী খুঁজছেন। /dev/stdoutখোলা থাকে, তাই catএবং সন্ধান করা tailচালিয়ে যান।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.