আমরা সকলেই জানি যে অনুসন্ধান করার সময় \nনতুন লাইন হয় এবং \rক্যারেজ রিটার্ন ( ^M) হয় তবে যখন স্থান পরিবর্তন করা \rহয় তখন নতুন লাইন হয় যখন \nনাল বাইট হয় ( ^@)।
এই অসম্পূর্ণতার উত্স কী? প্রদত্ত যে এই আচরণটি ... অদ্ভুতভাবে বলার জন্য অদ্ভুত (এবং যখন আপনি প্রথমবার এটি ভুল করেন তখন বেশ প্রতিক্রিয়াশীল) আমি আশা করি এর কিছু উদ্ভট historicalতিহাসিক কারণ রয়েছে।
(ঘটনাক্রমে, এই আচরণ "সংশোধন" করার এবং আরও স্বজ্ঞাত কিছু পাওয়ার উপায় আছে কি?)
উত্তর:
সর্বাধিক প্রাথমিক স্তরে, অনুসন্ধানের অংশগুলির প্রতিস্থাপনের মধ্যে ইতিমধ্যে একটি অসামঞ্জস্য রয়েছে :substituteকারণ পূর্ববর্তীটি একটি নিয়মিত প্রকাশ এবং পরেটিরটি নির্দিষ্ট অতিরিক্ত অতিরিক্ত পালানোর ক্রম সহ পাঠ্য । এর \nঅর্থ কী তা বোঝার জন্য আপনার অন্তর্দৃষ্টি দ্বারা এটি কেবল হাইলাইট করা হয়েছে ।
উদাহরণস্বরূপ, বিবেচনা করুন যে \nঅনুসন্ধানে কোনও আক্ষরিক সাথে মেলে না \n। এটা তোলে লাইন (EOL) বাইট ক্রম শেষে, যা হতে পারে ম্যাচ \r, \r\n, বা শুধু \nউপর নির্ভর করে 'fileformat'বাফার।
যতদূর কেন \r"একটি ইওল inোকান" বোঝাতে ব্যবহৃত হয়, এর পিছনে কিছু ইতিহাস রয়েছে। ভিআইয়ের কোনও ফাইলগুলিতে NUL বাইট হ্যান্ডেল করার কোনও উপায় ছিল না। অভ্যন্তরীণভাবে এনএল বাইটকে এনএল বাইট প্রতিস্থাপনের মাধ্যমে ভিমের উন্নতি হয়েছে (যেহেতু সি স্ট্রিংগুলি NUL সীমিত করা হয়)।
প্রতিস্থাপনের :substituteকারণে আচরণের মধ্যে ফাঁস হওয়া এই বাস্তবায়ন বিশদটি \nকেবল সেই রেখার অভ্যন্তরীণ উপস্থাপনায় সন্নিবেশ করা হয়, যা NUL বাইট নির্দেশ করতে ব্যবহৃত হয়। \rএকটি ইওল সন্নিবেশ করায়, অভ্যন্তরীণ লাইনটি দুটি ভাঙে। ভিম আসলে ইওএল বাইটসকে মেমোরিতে সঞ্চয় করে না, পরিবর্তে (ডি) বাফারটি পড়ার / লেখার সময় সেগুলি সিরিয়ালকরণ করে।
অনেকগুলি স্ক্রিপ্ট এবং অনেক ব্যবহারকারীর পেশী মেমরি ভঙ্গ না করে এখনই এটি পরিবর্তন করা যাবে না। ধন্যবাদ, এটি নথিভুক্ত :help sub-replace-special।
একটি NULবাইট সি একটি স্ট্রিং টারমিনেটর, এবং এই কারণে তেজ এই প্রচলিত রীতি অনুযায়ী, এ ম্যানুয়াল বর্ণিত ব্যবহার :h NL-used-for-Nul:
ফাইলের <নুল> অক্ষরগুলিকে মেমরিতে <NL> হিসাবে সংরক্ষণ করা হয়। ডিসপ্লেতে সেগুলিকে "^ @" হিসাবে দেখানো হয়। অনুবাদ ফাইল পড়া এবং লেখার সময় করা হয়। কোনও অনুসন্ধানের প্যাটার্নের সাথে <ulul> মেলানোর জন্য আপনি কেবল CTRL- @ বা "CTRL-V 000" লিখতে পারেন। এটি সম্ভবত আপনি প্রত্যাশা করেছেন। অভ্যন্তরীণভাবে অক্ষরটি অনুসন্ধান প্যাটার্নে <NL> দিয়ে প্রতিস্থাপন করা হয়েছে। যেটি অস্বাভাবিক তা হ'ল সিটিআরএল-ভি সিটিআরএল-জে টাইপ করা একটি <এনএনএল> সন্নিবেশও করে, সুতরাং ফাইলটিতে <নুল> অনুসন্ধান করে। {Vi ফাইলের <নুল> অক্ষরগুলি একেবারেই হ্যান্ডেল করতে পারে না}
এই সম্মেলনটি :s/.../.../কমান্ডে ছড়িয়ে পড়েছে , তবে কার্যক্রমে নয় substitute()। \rএবং কলগুলিতে \nপ্রতিস্থাপনের স্ট্রিংগুলি substitute()তাদের আসল অর্থ রাখে।
আমি মনে করি না উভয় আচরণের গভীর কারণ রয়েছে। ভিম মূল থেকে মূলত জৈবিকভাবে বিকশিত হয়েছে vi। এটির জন্য কখনও কোনও বড় নীলনকশা ছিল না, বৈশিষ্ট্যগুলি একে অপরের শীর্ষে সজ্জিত করা হয়েছিল, সেগুলি সংগঠিত রাখতে অপেক্ষাকৃত কম চেষ্টা করে।
অন্যান্য ভি ক্লোনগুলি প্রতিস্থাপনে সমর্থন করে না \rবা \n(সত্যিকারের ব্যাকস্ল্যাশ এবং চিঠি হিসাবে), কিন্তু লাইনের দুটি লাইনে বিভক্ত করার অর্থ একটি বাস্তব ^M( CTRL-V Enter) অর্থ আচরণ আচরণ :
একটি <গাড়ি রিটার্ন> এ প্রবেশ করা repl (যা একটি পলায়নপর <ব্যাকস্ল্যাশ> ইন করা দরকার, প্রাক্তন মোড এবং একটি পলায়নপর <নিয়ন্ত্রণ> খোলা বা -V ষষ্ঠ মোড) যে বিন্দু লাইনে বিভক্ত হইবে সম্পাদনা বাফারে নতুন লাইন তৈরি । <ক্যারেজ- পুনর্বার> ফেলে দেওয়া হবে।
ইউনিক্স ইতিহাস সংরক্ষণাগারে বিএসডি প্রাক্তন / vi এর প্রথম সংস্করণটি 4.1cBSD ( @(#)ex_re.c 7.2 10/16/81এবং 4BSD তে উপস্থিত নেই @(#)ex_re.c 6.2 10/23/80) [4.1a এবং 4.1b সংরক্ষণাগারে উপস্থিত নেই]।
সম্পর্কিত কোডটি হ'ল:
/* ^V <return> from vi to split lines */
if (c == '\r')
c = '\n';
নিউজ ফাইলে এটি উল্লেখ করা হয়েছে :
আরএইচএসে ^ V <return> ব্যবহার করে vi থেকে বিকল্প কমান্ডের সাহায্যে লাইনগুলি ভাগ করা সম্ভব। প্রাক্তন কমান্ড মোডটি ব্যবহারের জন্য এটি সর্বশেষ ভাল কারণটির যত্ন নেয়।
প্রাক্তন কমান্ড মোডে পূর্বে সমর্থিত আচরণটি ব্যাকস্ল্যাশ-এন্টার (অর্থাত্ ব্যাকস্ল্যাশ একটি বাস্তব নিউলাইন দ্বারা অনুসরণ করা) একটি নতুন লাইন সন্নিবেশ করানোর জন্য ছিল।
অসমত্বের উত্স কম্পিউটিং ইতিহাসে একটি উপায় ফিরে যায়।
সংক্ষিপ্ত সংস্করণ:
<CR> & <LF> (Carriage-Return and Linefeed)
==
\r & \n
দীর্ঘ সংস্করণ:
প্রথম স্ক্রিনগুলি মূলত টেলি টাইপগুলির ডিজিটাল সংস্করণ (টিটিওয়াই) ছিল এবং প্রিন্টারের সাথে একই আচরণ তৈরি করতে নিয়ন্ত্রণ কোড ব্যবহার করে। ক্যারেজ-রিটার্ন কার্সারটি (বা প্রিন্ট-হেড) শুরু কলামে নিয়ে গেছে। লাইনফিড পরবর্তী সারিতে উন্নীত হয়েছে (একটি স্ক্রিনে) এবং কাগজটিকে এক লাইনে এগিয়ে দিয়েছে।
মুদ্রকগুলির জন্য, আপনাকে একটি জোড় তৈরি করতে হয়েছিল <CR><LF>অথবা আপনার আউটপুটটি সঠিক দেখাচ্ছে না। প্রথম পর্দায়, সমস্যাটি এখনও সত্য ধরেছিল।
ডস (এবং পরে ওয়ার্ড-উইন্ডোজ) পুরানো মান অনুসরণ করে এবং এর সাথে পাঠ্য সংরক্ষণ করে <CRLF>।
* NIX পাঠ্য (বেশিরভাগ vi ব্যবহারকারী হিসাবে পরিচিত) কেবল <LF>দক্ষতার জন্য ব্যবহার করে।
উইন্ডোজে পরীক্ষা করার জন্য, ওয়ার্ড / ওয়ার্ডপ্যাড ব্যবহার করুন এবং "টাইপ হিসাবে পাঠ্য - এমএস-ডস ফর্ম্যাট" পাঠ্যের কয়েকটি লাইন সংরক্ষণ করুন। তারপরে একই ফাইলটি নোটপ্যাডে খুলুন। এটি স্বাভাবিক দেখতে হবে। তারপরে একই ফাইলটিকে ওয়ার্ড / ওয়ার্ডপ্যাডে "টাইপ করুন: পাঠ্য" হিসাবে সংরক্ষণ করুন। নোটপ্যাড সমস্ত নতুন লাইন উপেক্ষা করবে এবং একসাথে লাইনগুলি চালাবে। [নোটপ্যাডের পাঠ্য বিন্যাসটি \r\nওয়ার্ড / ওয়ার্ডপ্যাডে ডিফল্ট হওয়ার সাথে সংমিশ্রণে ডিফল্ট হয় \n]]
\ r এর কোড সমতুল্য <CR>
\ n এর কোড সমতুল্য <LF>
এবং vi এর সাথে আমার (খুব সীমাবদ্ধ) অভিজ্ঞতায় এটি <CRLF>আমার ডসের পাঠ্য সম্পাদক থেকে সংমিশ্রণটি "ঠিক" করার চেষ্টা করবে । vi এর পরিবর্তে একটি চরিত্র মুছে ফেলা শেষ হয়েছিল <NUL>। আমি vi ব্যবহার বন্ধ করে দেওয়ার একটি বড় অংশ।
\rহয়<CR>এবং\nহয়<LF>। এটি বিভিন্ন প্রসঙ্গে কেন আলাদাভাবে\n\rআচরণ করে তার আসল প্রশ্নটির সমাধান করে না ।