ফাইলের শেষে কোনও নিউলাইন নেই

Question

যখন ক git diff এটি "ফাইলের শেষে কোনও নিউলাইন নয়" বলে ।

ঠিক আছে, ফাইলের শেষে কোনও নতুন লাইন নেই। বড় চুক্তি কি?

বার্তার তাৎপর্য কী এবং এটি আমাদের জানাতে চেষ্টা করছে?

Comments

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

— এনএফজি

Answer 1

এটি নির্দেশ করে যে আপনার কাছে নতুন লাইন নেই (সাধারণত) '\n' কাছে ফাইলের শেষে , ওরফে সিআর বা সিআরএলএফ) নেই।

এটি, সহজভাবে বলতে গেলে, ফাইলের শেষ বাইট (বা আপনি উইন্ডোজ থাকলে বাইটস) কোনও নতুন লাইন নয়।

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

নোট করুন ফাইল ফর্ম্যাটের দ্বারা অনুমোদিত হলে সর্বদা নতুন অক্ষরটিকে সর্বশেষ অক্ষর হিসাবে রাখাই ভাল স্টাইল। তদতিরিক্ত, উদাহরণস্বরূপ, সি এবং সি ++ শিরোলেখ ফাইলগুলির জন্য এটি ভাষা মানের দ্বারা প্রয়োজনীয়।

Comments

কৌতূহলের বাইরে, আপনি কী ব্যাখ্যা করতে পারেন যে কেন সর্বদা শেষ চরিত্র হিসাবে একটি নতুন লাইন রাখা ভাল স্টাইল হিসাবে বিবেচিত হয়? সম্পাদনা: এই আলোচনাটি খুঁজে পেয়েছি ।

— পল বেলোরা

@PaulBellora ঐতিহাসিকভাবে, এটা মান সি ল্যাঙ্গুয়েজ দ্বারা তৈরি একটি সিদ্ধান্ত stackoverflow.com/a/729725/233098 , কার্যত কারণ অনেক ইউনিক্স সরঞ্জাম প্রয়োজন হয় বা সঠিক প্রদর্শনের জন্য এটা আশা stackoverflow.com/a/729795/233098 । দার্শনিকভাবে, কারণ একটি পাঠ্য ফাইলে প্রতিটি লাইন একটি "শেষের লাইনের" অক্ষর দিয়ে শেষ হয় - শেষ লাইনে কোনও ব্যতিক্রম হওয়া উচিত নয়। এ সম্পর্কে অন্যভাবে চিন্তা করে, আসুন বিপরীতটি ঘুরে দেখি। যদি "শেষ-লাইনের" পরিবর্তে "স্টার্ট-অফ-লাইন" চিহ্নিতকারী থাকে, আপনি কি প্রথম লাইনে "স্টার্ট-অফ-লাইন" অক্ষরটি বাদ দিতে পারবেন?

— জো

@ জো যে এতটা বোঝায় না। একটি নতুন লাইন হল একটি নতুন লাইন , অর্থাৎ রেখার মধ্যে বিভাজক, শেষের লাইনের নয়। আমাদের লাইন অক্ষরগুলির শুরু নেই কারণ সেগুলি প্রয়োজনীয় নয়। আমাদের একই কারণে লাইন অক্ষরের শেষ নেই।

— আকজয়

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

— জো

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

— জো

Answer 2

এটি কেবল খারাপ শৈলী নয়, ফাইলের অন্যান্য সরঞ্জাম ব্যবহার করার সময় এটি অপ্রত্যাশিত আচরণের দিকে পরিচালিত করতে পারে।

এখানে test.txt:

first line
second line

শেষ লাইনে কোনও নিউলাইন চরিত্র নেই। আসুন দেখুন ফাইলটিতে কতগুলি লাইন রয়েছে:

$ wc -l test.txt
1 test.txt

হতে পারে এটি আপনি চান তবে বেশিরভাগ ক্ষেত্রে আপনি সম্ভবত ফাইলটিতে 2 লাইন থাকবেন বলে আশা করতেন।

এছাড়াও, আপনি যদি ফাইলগুলি একত্রিত করতে চান তবে এটি আপনার প্রত্যাশা মতো আচরণ করবে না:

$ cat test.txt test.txt
first line
second linefirst line
second line

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

Comments

বিড়ালের ফলাফল ঠিক আছে তবে ডাব্লুসি প্যারামিটার "-l, --lines" ঠিক ভুল just এমনকি এটির ম্যানুয়ালটিতে বলা হয়েছে "নিউলাইন গণনাগুলি মুদ্রণ করুন" এবং "লাইন গণনাগুলি মুদ্রণ করুন" না।

— অবিশ্বাস্য জানুয়ারী

এবং আমি সাম্প্রতিক ইউজ লিনাক্স (ইউজার-লিনাক্স 2.34) দিয়ে এটি (ডাব্লুসি এবং বিড়াল) পুনরুত্পাদনও করতে পারি না।

— wget হয়

@ উইজেট আমি ইউজার-লিনাক্স ২.৪34 এ রয়েছি এবং এটি নিশ্চিত করতে পারে যে এই উত্তরটি যা বর্ণনা করে তা বর্তমান আচরণ। আমার অনুমান যে আপনার সম্পাদক "\ n" অক্ষর যুক্ত করেছেন।

— স্টেথানস

Answer 3

এর একমাত্র কারণ হ'ল ইউনিক্স historতিহাসিকভাবে সমস্ত মানব-পঠনযোগ্য পাঠ্য ফাইলগুলির একটি সম্মেলন একটি নতুন লাইনে শেষ হয়েছিল। এই সময়ে, এটি পাঠ্য ফাইলগুলি প্রদর্শন বা যোগদানের সময় অতিরিক্ত প্রক্রিয়াজাতকরণ এড়ানো এবং অন্যান্য ধরণের ডেটা (যেমন কাঁচা বাইনারি ডেটা যা মানব-পঠনযোগ্য নয়) ফাইলগুলিতে পাঠ্য ফাইলগুলিকে আলাদাভাবে চিকিত্সা করা এড়ানো হয়েছে।

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

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

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

এমন একাধিক প্রযুক্তিগত কারণ রয়েছে যা 1971 সালে উপলব্ধি করেছিল তবে এই যুগে এটি বেশিরভাগই কনভেনশন এবং বিদ্যমান সরঞ্জামগুলির সাথে সামঞ্জস্য বজায় রাখে।

Answer 4

যদি আপনি বিদ্যমান ফাইলটির শেষে পাঠ্যের একটি নতুন লাইন যুক্ত করেন যা ইতিমধ্যে একটি newline characterশেষে নেই, তবে ভিন্নতা পুরানো শেষ লাইনটি সংশোধিত হিসাবে দেখাবে, যদিও ধারণাগতভাবে এটি ছিল না।

এটি যুক্ত করার জন্য কমপক্ষে একটি ভাল কারণ newline character ।

উদাহরণ

একটি ফাইল রয়েছে:

A() {
    // do something
}

Hexdump:

00000000: 4128 2920 7b0a 2020 2020 2f2f 2064 6f20  A() {.    // do 
00000010: 736f 6d65 7468 696e 670a 7d              something.}

আপনি এখন এটিকে সম্পাদনা করুন

A() {
    // do something
}
// Useful comment

Hexdump:

00000000: 4128 2920 7b0a 2020 2020 2f2f 2064 6f20  A() {.    // do 
00000010: 736f 6d65 7468 696e 670a 7d0a 2f2f 2055  something.}.// U
00000020: 7365 6675 6c20 636f 6d6d 656e 742e 0a    seful comment..

গিট ডিফ প্রদর্শিত হবে:

-}
\ No newline at end of file
+}
+// Useful comment.

অন্য কথায়, এটি ধারণাগতভাবে ঘটনার চেয়ে আরও বড় পার্থক্য দেখায়। এটি দেখায় যে আপনি লাইনটি মুছে ফেলেছেন এবং লাইনটি }যুক্ত করেছেন }\n। এটি আসলে ঘটেছে, তবে ধারণাগতভাবে এটি ঘটেনি, তাই এটি বিভ্রান্তিকর হতে পারে।

Comments

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

— জেনিয়েন

@ জেন্তিয়েন আপনি "একটি নতুন লাইন" (একটি নতুন লাইন) এবং "একটি নতুন লাইন" (1 বা 2 টি অক্ষর একটি লাইনের শেষ

— সীমানা নির্ধারণ করছেন

@ মিনেক্সিউ না, জেনটিয়ান নয় সম্ভবত আপনি বুঝতে পারবেন না যে "একটি নতুন লাইন" "একটি নতুন লাইনের" সমান।

— অবিশ্বাস্য জানুয়ারী

@The IncredibleJan উত্তরে তারা যেভাবে ব্যবহৃত হচ্ছে, দুটি পদটির আলাদা অর্থ রয়েছে। আমি জানিনা আপনি স্মার্ট গাধা হওয়ার চেষ্টা করছেন বা কী চলছে তা কেবল ভুল বোঝাবুঝি করছেন।

— খনি

Answer 5

এটি কেবলমাত্র ইঙ্গিত করে যে ফাইলটির শেষের একটি নতুন লাইন নেই। এটি বিপর্যয় নয় এটি কেবল একটি বার্তা এটি পরিষ্কার করে দেওয়ার জন্য যে কমান্ড লাইনে কোনও ভিন্নতার দিকে তাকানোর সময় একটি নেই।

Answer 6

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

উদাহরণস্বরূপ বিবেচনা করুন, কেবলমাত্র একটি নিউলাইন চরিত্রযুক্ত একটি ফাইলকে একক, খালি লাইন হিসাবে বিবেচনা করা হয়। বিপরীতে, শূন্য বাইটের দৈর্ঘ্যের একটি ফাইল আসলে শূন্য লাইন সহ একটি খালি ফাইল। wc -lকমান্ড অনুযায়ী এটি নিশ্চিত করা যেতে পারে ।

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

Comments

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

— লেসলি ক্রাউস

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

— ব্যবহারকারী 34660

Answer 7

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

Comments

সাধারণভাবে ভাল পয়েন্ট, তবে আমি মনে করি না যে এই নির্দিষ্ট প্রশ্নের প্রসঙ্গে এটি অর্থবোধ করে।

— cst1992

@ cst1992 স্ট্যাকওভারফ্লোতে উত্তরগুলি যথাসম্ভব দরকারী বলে মনে করা হচ্ছে যার অর্থ তারা সমস্ত সম্ভাবনার ক্ষেত্রে প্রয়োগ করার কথা। প্রশ্নটি সংক্ষিপ্ত এবং আমার প্রস্তাবিত সম্ভাবনাটি এটি বাদ দেয় যেখানে আমি তা দেখতে পাচ্ছি না।

— ব্যবহারকারী 34660

Answer 8

মূল সমস্যাটি হ'ল আপনি লাইনটি কী সংজ্ঞায়িত করেন এবং শেষ-অন-লাইন চরিত্রের অনুক্রমটি লাইনের অংশ কিনা তা। ইউএনআইএক্স-ভিত্তিক সম্পাদক (যেমন ভিআইএম) বা সরঞ্জামগুলি (যেমন গিট) লাইন টার্মিনেটর হিসাবে EOL অক্ষর ক্রম ব্যবহার করে, সুতরাং এটি লাইনের একটি অংশ। এটি সি এবং প্যাস্কেলে সেমিকোলন (;) ব্যবহারের মতো। সি সেমিকোলনে বিবৃতি সমাপ্ত করে, পাস্কালে এটি তাদের আলাদা করে।

Answer 9

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

গিট এলএফ এর পরিবর্তে সিআরএলএফ

Answer 10

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

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

Comments

সি / সি ++ এ আপনি আপনার পুরো প্রকল্পটি এক লাইনে লিখতে পারেন। নতুন লাইনের দরকার নেই।

— অবিশ্বাস্য জানুয়ারী

আপনি পারে এক লাইনে আপনার পুরো প্রকল্পের লিখুন ... আপনি একটি ব্যবহার করবেন না //কোডের মাঝখানে শৈলী মন্তব্য নেই।

— ডগ কোবার্ন

Answer 11

আপনার আসল ফাইলে সম্ভবত কোনও নতুন লাইন অক্ষর নেই।

যাইহোক, মত কিছু সম্পাদকদের gedit- র দ্বারা লিনাক্স-এ চুপটি ফাইল শেষে সম্পর্কে newline যোগ করা হয়েছে। এই জাতীয় সম্পাদক ব্যবহার করার সময় আপনি এই বার্তাটি থেকে মুক্তি পেতে পারবেন না।

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

এই সম্পাদক স্পষ্টভাবে শেষ লাইনটি দেখায় এবং আপনি নিজের ইচ্ছামত লাইনটি মুছতে পারেন।

Answer 12

এটির মূল্যের জন্য, আমি যখন আমি একটি ম্যাকের উপর একটি ইন্টেলিজিজ প্রকল্প তৈরি করেছি তখন এটির মুখোমুখি হয়েছিলাম এবং তারপরে প্রকল্পটি আমার উইন্ডোজ মেশিনে স্থানান্তরিত করেছি। আমাকে ম্যানুয়ালি প্রতিটি ফাইল খুলতে হবে এবং ইন্টেলিজ উইন্ডোর নীচে ডানদিকে এনকোডিং সেটিংস পরিবর্তন করতে হয়েছিল। সম্ভবত যারা কেউ এই প্রশ্নটি পড়ে তবে বেশিরভাগ ক্ষেত্রেই ঘটছে না তবে এটি আমাকে কয়েক ঘন্টা কাজ বাঁচাতে পারত ...