পাঠ্য ফাইলগুলি কেন একটি নতুন লাইনের সাথে শেষ করা উচিত?

Question

আমি ধরে নিলাম এখানকার প্রত্যেকে এই প্রবাদের সাথে পরিচিত যে সমস্ত পাঠ্য ফাইল একটি নতুন লাইনের সাথে শেষ হওয়া উচিত। আমি এই "বিধি "টি বছরের পর বছর ধরে জানি তবে আমি সবসময় ভাবছিলাম - কেন?

Comments

শুধু একটি নিটপিক ফাইলের শেষে এটি "নতুন লাইন" নয়। এটি শেষ লাইনের শেষে একটি "লাইন ব্রেক"। এছাড়াও, সম্পর্কিত প্রশ্নের সেরা উত্তর দেখুন: স্ট্যাকওভারফ্লো

— জিসিবি

কিছুটা নিটপিক করার জন্য, তিনি আসলে "নতুন লাইন" লেখেননি, তিনি "নিউলাইন" লিখেছিলেন, যা সঠিক।

— সিন্ড্রেনম

পরিচিত নয়, তবে আমি অবাক হয়েছি কারণ সত্যই যে অতিরিক্ত অতিরিক্ত নিউলাইন আসলে জিনিসগুলি ভঙ্গ করছে সেই

— সংখ্যাগুলি

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

— কে কে কোয়ান

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

— মার্কডি ব্ল্যাকওয়েল

Answer 1

কারণ এইভাবেই পসিক্স স্ট্যান্ডার্ড একটি লাইনকে সংজ্ঞায়িত করে :

3.206 লাইন

শূন্য বা আরও অ-নিউ-লাইন> অক্ষর এবং একটি সমাপ্তি <নিউলাইন> চরিত্রের ক্রম।

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

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

$ more a.txt
foo
$ more b.txt
bar$ more c.txt
baz
$ cat {a,b,c}.txt
foo
barbaz

এবং, পূর্ববর্তী উদাহরণটিও প্রমাণ করে যে, কমান্ড লাইনে ফাইলটি প্রদর্শন করার সময় (যেমন মাধ্যমে more), একটি নিউলাইন-টার্মিনেট করা ফাইলটি সঠিক ডিসপ্লেতে ফলাফল দেয়। একটি ভুলভাবে বাতিল হওয়া ফাইলটি গার্বলড (দ্বিতীয় লাইন) হতে পারে।

ধারাবাহিকতার জন্য, এই নিয়মটি অনুসরণ করা খুব সহায়ক - অন্যথায় ডিফল্ট ইউনিক্স সরঞ্জামগুলির সাথে কাজ করার সময় অতিরিক্ত কাজ করতে হবে।

---

এটিকে আলাদাভাবে চিন্তা করুন: লাইনগুলি যদি নিউলাইনের মাধ্যমে বন্ধ না করা হয় তবে catদরকারী হিসাবে কমান্ড তৈরি করা আরও শক্ত:

1. এটি প্রতিটি ফাইলের শুরুটিকে একটি নতুন লাইনে ফেলে দেয়, যা আপনি 95% সময় চান; কিন্তু
2. এটি দুটি ফাইলের শেষ এবং প্রথম লাইনটি মার্জ করার অনুমতি দেয়, যেমন উপরের উদাহরণটির মধ্যে b.txtএবং এর মধ্যে c.txt?

অবশ্যই এটি সমাধানযোগ্য তবে আপনার catআরও জটিল ব্যবহার করা দরকার ( অবস্থানিক কমান্ড লাইন যুক্তি যুক্ত করে, যেমন cat a.txt --no-newline b.txt c.txt) এবং এখন প্রতিটি পৃথক ফাইলের চেয়ে কমান্ডটি কীভাবে এটি অন্য ফাইলগুলির সাথে এক সাথে আটকানো হয় তা নিয়ন্ত্রণ করে। এটি প্রায় অবশ্যই সুবিধাজনক নয়।

… বা আপনার একটি বিশেষ সেন্ডিনেল চরিত্রটি প্রবর্তন করতে হবে যা এমন একটি লাইন চিহ্নিত করতে হবে যা সমাপ্তির পরিবর্তে অব্যাহত রাখার কথা। ভাল, এখন আপনি উল্টানো (লাইন সমাপ্তির অক্ষরের পরিবর্তে লাইন ধারাবাহিকতা) বাদে পসিক্সের মতো একই পরিস্থিতির সাথে আটকে আছেন।

---

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

Comments

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

— ডগ কোবার্ন

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

— কনরাড রুডল্ফ

@ লিওন পসিক্স নিয়মটি এজ প্রবণতা হ্রাস সম্পর্কে about এবং এটি এত সুন্দর করে। লোকেরা কীভাবে এটি বুঝতে ব্যর্থ হয় আমি আসলেই কিছুটা ক্ষতির মধ্যে আছি: এটি কোনও লাইনের সহজতম, স্বাবলম্ব সংজ্ঞা।

— কনরাড রুডলফ

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

— কনরাড রুডল্ফ

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

— কনরাড রুডলফ

Answer 2

প্রতিটি লাইন শেষ লাইক সহ একটি নতুন লাইনের অক্ষরে শেষ করা উচিত। কিছু প্রোগ্রামের কোনও ফাইলের শেষ লাইনটি প্রসেস করতে সমস্যা হয় যদি এটি নতুন লাইনটি বন্ধ না হয়।

জিসিসি এটি সম্পর্কে সতর্ক করে কারণ এটি ফাইলটি প্রক্রিয়া করতে পারে না , কারণ এটি স্ট্যান্ডার্ডের অংশ হিসাবে রয়েছে ।

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

যেহেতু এটি "উইল" ধারা রয়েছে তাই এই বিধি লঙ্ঘনের জন্য আমাদের অবশ্যই ডায়াগনস্টিক বার্তা প্রেরণ করতে হবে।

এটি এএনএসআই সি 1989 স্ট্যান্ডার্ডের 2.1.1.2 বিভাগে রয়েছে। আইএসও সি 1999 স্ট্যান্ডার্ডের 5.1.1.2 বিভাগ (এবং সম্ভবত আইএসও সি 1990 স্ট্যান্ডার্ড)।

তথ্যসূত্র: জিসিসি / জিএনইউ মেল সংরক্ষণাগার ।

Comments

দয়া করে ভাল প্রোগ্রাম লিখুন যাতে হয় প্রক্রিয়া করার সময় যেখানে প্রয়োজন হয় সেই নিউলাইনটি সন্নিবেশ করানোর অনুমতি দেয় বা "নিখোঁজ" ব্যক্তিদের সঠিকভাবে পরিচালনা করতে সক্ষম হয় ... যা প্রকৃতপক্ষে নিখোঁজ নয়

— tobibeer

@ বিল্টলিজার্ড, "কিছু প্রোগ্রামের কোনও ফাইলের শেষ লাইনটি যদি নতুন লাইনের অবসান না হয় তবে প্রক্রিয়াজাত করতে সমস্যা হয়" এর কয়েকটি উদাহরণ কী ?

— পেসারিয়ার

@ পেসারিয়র wc -lকোনও ফাইলের শেষ লাইনটি গণনা করবে না যদি এটি নতুন লাইন বন্ধ না করে। এছাড়াও, catযদি প্রথম ফাইলের শেষ লাইনটি নতুন লাইনটি বন্ধ না হয় তবে পরবর্তী ফাইলের প্রথম লাইনের সাথে একটি ফাইলের শেষ লাইনে যোগ দেবে। ডিলিমিটার হিসাবে নিউলাইনগুলি সন্ধান করা খুব যে কোনও প্রোগ্রামের মধ্যে এটি গোলমাল করার সম্ভাবনা রয়েছে।

— বিলটি

@BilltheLizard, আমি মানে wcকরেছে ইতিমধ্যে উল্লিখিত হয়েছে ....

— Pacerier

@ বিল্টলিজার্ড, আমার খারাপ, স্পষ্ট করে বলার জন্য: কোন ফাইলের শেষ লাইনের প্রসেসিংয়ে সমস্যা রয়েছে এমন কিছু প্রোগ্রামের কী উদাহরণ রয়েছে যা যদি নতুন লাইনের সমাপ্ত হয় না (পাশাপাশি যেগুলি থ্রেডে ইতিমধ্যে গণ-উল্লেখ করা হয়েছে catএবং wc)?

— পেসারিয়ার

Answer 3

এই উত্তরটি মতামত না করে কারিগরি উত্তরের চেষ্টা।

আমরা যদি পসিক্স পিউরিস্ট হতে চাই তবে আমরা একটি লাইনটিকে এইভাবে সংজ্ঞায়িত করি:

শূন্য বা আরও অ-নিউ-লাইন> অক্ষর এবং একটি সমাপ্তি <নিউলাইন> চরিত্রের ক্রম।

সূত্র: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206

একটি অসম্পূর্ণ রেখা:

ফাইলের শেষে এক বা একাধিক অ-নিউ-লাইন> অক্ষরের একটি ক্রম।

সূত্র: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_195

একটি পাঠ্য ফাইল:

একটি ফাইল যা শূন্য বা আরও বেশি লাইনে বিভক্ত অক্ষর ধারণ করে। লাইনগুলিতে NUL টি অক্ষর থাকে না এবং <নিউলাইন> অক্ষর সহ কোনওর চেয়ে দৈর্ঘ্য {LINE_MAX} বাইটের বেশি হতে পারে না। যদিও POSIX.1-2-2008 পাঠ্য ফাইল এবং বাইনারি ফাইলগুলির মধ্যে পার্থক্য না করে (আইএসও সি স্ট্যান্ডার্ড দেখুন), অনেকগুলি ইউটিলিটি কেবল পাঠ্য ফাইলগুলিতে অপারেটিং করার সময় অনুমানযোগ্য বা অর্থপূর্ণ আউটপুট তৈরি করে। যে স্ট্যান্ডার্ড ইউটিলিটিগুলির মধ্যে এই জাতীয় বিধিনিষেধ রয়েছে তারা সর্বদা তাদের STDIN বা ইনপুট ফাইল বিভাগগুলিতে "পাঠ্য ফাইলগুলি" নির্দিষ্ট করে।

সূত্র: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_397

একটি স্ট্রিং:

প্রথম নাল বাইট দ্বারা সমাপ্ত এবং বাইটের একটি স্বতন্ত্র ক্রম।

সূত্র: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_396

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

একটা উদাহরণ: wc -l filename।

থেকে wcএর ম্যানুয়াল আমরা পড়ি:

একটি লাইন << নিউলাইন> অক্ষর দ্বারা বিসর্জনিত অক্ষরের একটি স্ট্রিং হিসাবে সংজ্ঞায়িত হয়।

জাভাস্ক্রিপ্ট, এইচটিএমএল এবং সিএসএস ফাইলের লিখিত ফাইলগুলি এর পরে কী প্রভাব ফেলবে ?

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

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

এই মুহুর্তে আমরা আত্মবিশ্বাসের সাথে বলতে পারি যে ক্লায়েন্ট-সাইডে জেএস, এইচটিএমএল, সিএসএসের সাথে কাজ করার সময় EOF এ EOL এড়িয়ে যাওয়া নিরাপদ। প্রকৃতপক্ষে, আমরা বলতে পারি যে << নিউলাইন> না থাকা এই ফাইলগুলির যে কোনও একটিকেই নিরাপদ করা নিরাপদ।

আমরা এটি আরও একধাপ এগিয়ে নিয়ে যেতে এবং বলতে পারি যে নোডজেএসের সাথে সম্পর্কিত এটিও পসিক্স মানকে মেনে নিতে পারে না কারণ এটি নন-পসিক্স অনুবর্তী পরিবেশে চলতে পারে।

তখন আমরা কী রেখেছি? সিস্টেম স্তরের সরঞ্জামাদি।

এর অর্থ উত্থাপিত হতে পারে কেবলমাত্র ইস্যুগুলি সেই সরঞ্জামগুলির সাথে যা পসিক্সের শব্দার্থবিজ্ঞানের সাথে তাদের কার্যকারিতা মেনে চলার চেষ্টা করে (উদাহরণ হিসাবে দেখানো হয়েছে একটি রেখার সংজ্ঞা wc)।

তবুও, সমস্ত শেল স্বয়ংক্রিয়ভাবে পসিক্সের সাথে মেনে চলবে না। উদাহরণস্বরূপ ব্যাশ POSIX আচরণে ডিফল্ট হয় না। একটা সুইচ এটি সক্রিয় করা: POSIXLY_CORRECT।

ইওএল <এনওলাইন>: https://www.rfc-editor.org/old/EOLstory.txt এর মান নিয়ে চিন্তার জন্য খাদ্য

সমস্ত ব্যবহারিক অভিপ্রায় এবং উদ্দেশ্যগুলির জন্য, টুলিং ট্র্যাকের উপরে থাকা, আসুন এটি বিবেচনা করুন:

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

curl http://cdnjs.cloudflare.com/ajax/libs/AniJS/0.5.0/anijs-min.js -o x.js
curl http://cdnjs.cloudflare.com/ajax/libs/AniJS/0.5.0/anijs-min.js -o y.js

$ cat x.js y.js > z.js

-rw-r--r--  1 milanadamovsky   7905 Aug 14 23:17 x.js
-rw-r--r--  1 milanadamovsky   7905 Aug 14 23:17 y.js
-rw-r--r--  1 milanadamovsky  15810 Aug 14 23:18 z.js

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

যেহেতু এই থ্রেডে অন্য কেউ উল্লেখ করেছেন: আপনি যদি এমন catদুটি ফাইল চান যাঁর আউটপুট দুটি পরিবর্তে কেবল একটি লাইন হয়ে যায়? অন্য কথায়, catএটি করার কথা বলে যা করে।

এর manমধ্যে catকেবলমাত্র << নিউলাইন> নয়, ইওএফ পর্যন্ত পড়া ইনপুট উল্লেখ রয়েছে। নোট করুন যে -nস্যুইচটি catএকটি নন-নিউলাইন> টার্মিনেটেড লাইন (বা অসম্পূর্ণ লাইন ) একটি লাইন হিসাবেও মুদ্রণ করবে - যেটি গণনাটি 1 থেকে শুরু হয় (অনুযায়ী man।)

-n আউটপুট লাইন সংখ্যা 1 থেকে শুরু করুন।

এখন যখন আমরা বুঝতে পারি যে পসিক্স কীভাবে একটি লাইনকে সংজ্ঞায়িত করে , এই আচরণটি অস্পষ্ট বা সত্যই অ-সঙ্গতিপূর্ণ হয়।

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

উদাহরণস্বরূপ, এটির পরিবর্তে wc -l filenameকেউ এটি করতে পারে awk '{x++}END{ print x}' filenameএবং আশ্বস্ত করুন যে আমরা যে ফাইলটি লিখেছি না তার প্রক্রিয়াটি করতে চাইলে কোনও কাজটির সাফল্য হুমকির সম্মুখীন হয় না (উদাহরণস্বরূপ তৃতীয় পক্ষের লাইব্রেরি যেমন মিনিফাড জেএস আমরা curlডি) না করি - অভিপ্রায়টি ছিল সত্যই পসিক্স অনুগত অর্থে লাইন গণনা করা ।

উপসংহার

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

গল্পের নৈতিক: ইঞ্জিনিয়ার টুলিং যা EOF এ EOL এর উপর নির্ভর করার দুর্বলতা রাখে না।

জেএস, এইচটিএমএল এবং সিএসএসে প্রযোজ্য ক্ষেত্রে ব্যবহারের ক্ষেত্রে নির্দ্বিধায় দ্বিধা বোধ করবেন যেখানে EOL এড়ানো যায় কীভাবে তার বিরূপ প্রভাব ফেলে তা আমরা পরীক্ষা করতে পারি।

Comments

পসিক্স প্রশ্নে ট্যাগ করা হয় না ... এমভিএস / ওএস লাইন শেষ সম্পর্কে? বা এমএস-ডস লাইন শেষ? যাইহোক, সমস্ত পরিচিত পক্সিক্স সিস্টেমগুলি চূড়ান্ত লাইন শেষ না করেই টেক্সট ফাইলগুলিকে মঞ্জুরি দেয় (কোনও পিক্স্স কমপ্লায়েন্ট দাবিদার সিস্টেমের কোনও সন্ধান পাওয়া যায় নি যার উপর "টেক্সট ফাইল" কার্নেলের মধ্যে বিশেষ চিকিত্সা রয়েছে যাতে ক্ষেত্রে এটি একটি নতুন নিউলাইন সন্নিবেশ করায়) এটি)

— লুইস কলোরাডো

Answer 4

এটি এর মধ্যে পার্থক্যের সাথে সম্পর্কিত হতে পারে :

• পাঠ্য ফাইল (প্রতিটি লাইন একটি লাইনের শেষে শেষ হওয়ার কথা)
• বাইনারি ফাইল (কথা বলার জন্য কোনও সত্য "লাইন" নেই, এবং ফাইলটির দৈর্ঘ্য অবশ্যই সংরক্ষণ করতে হবে)

যদি প্রতিটি লাইন একটি শেষ-লাইনের শেষ হয়, তবে এটি এড়ানো হবে, উদাহরণস্বরূপ, দুটি টেক্সট ফাইলকে সংযুক্ত করে প্রথম রানের শেষ লাইনটিকে দ্বিতীয়টির প্রথম লাইনে পরিণত করবে।

এছাড়াও, একটি সম্পাদক ফাইলের শেষ-লাইনের মধ্যে শেষ হয় কিনা, এটি তার স্থানীয় বিকল্প 'ইওল'-এ সংরক্ষণ করে এবং ফাইলটি লেখার সময় এটি ব্যবহার করে কিনা তা লোডে পরীক্ষা করতে পারে।

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

1 first line
2 middle line
3 last line
4

Comments

+1 টি। এই খুব সমস্যাটি अनुभव করার সময় আমি এই SO প্রশ্নটি পেয়েছি। এটা খুব এই "জাল" শেষ লাইনটি দেখানোর জন্য অন্ধকার বিরক্তিকর, এবং যদি আমি এটা মুছে ফেলার, তারপর Git (এবং অন্যান্য সব UNIX সরঞ্জামগুলি আমাদের কাছে EOL আশা) অভিযোগ। এছাড়াও, মনে রাখবেন যে এটি কেবল 2005 সালেই নয়: গ্রহন 4.2 জুনোতে এখনও এই সমস্যা রয়েছে।

— MestreLion

@MestreLion এ ধারাবাহিকতা stackoverflow.com/questions/729692/...

— Pacerier

Answer 5

কিছু সরঞ্জাম এটি আশা করে। উদাহরণস্বরূপ, এটি wcপ্রত্যাশা করে:

$ echo -n "Line not ending in a new line" | wc -l
0
$ echo "Line ending with a new line" | wc -l
1

Comments

আমি "কিছু" বলব না, আমি বলি বেশিরভাগ সরঞ্জামগুলি টেক্সট ফাইলগুলির জন্য আশা করে যে সমস্ত না। বিড়াল, গিট,

— ডিফ, ডব্লুসি, গ্রেপ, সেড

সম্ভবত কেউ বলতে পারে যে এটি wcএটি প্রত্যাশা করে না , এটি "লাইন" সম্পর্কে বেশিরভাগ লোকের স্বজ্ঞাত বোঝার বিরোধী হিসাবে একটি "লাইন" এর POSIX সংজ্ঞায় কেবল কাজ করছে।

— গিলডেনস্টন

@ গিল্ডেনস্টার্ন স্বজ্ঞাত সংজ্ঞাটি উভয় ক্ষেত্রেই wc -lমুদ্রণের জন্য হবে 1, তবে কিছু লোক হয়তো বলতে পারেন দ্বিতীয় কেসটি প্রিন্ট করা উচিত 2।

— ফ্লিম

@ ফ্লিম আপনি যদি পসিক্স / ইউএনআইএক্সের \nমতো লাইন বিভাজক হিসাবে লাইন টার্মিনেটর হিসাবে ভাবেন , তবে দ্বিতীয় কেসটি 2 মুদ্রণের আশা করা একেবারেই উন্মাদ।

— সেমিকোলন

Answer 6

মূলত এমন অনেক প্রোগ্রাম রয়েছে যা চূড়ান্ত EOL EOF না পেলে ফাইলগুলি সঠিকভাবে প্রক্রিয়া করবে না will

জিসিসি আপনাকে এ সম্পর্কে সতর্ক করে কারণ এটি সি স্ট্যান্ডার্ডের অংশ হিসাবে প্রত্যাশিত। (বিভাগ 5.1.1.2 আপাতদৃষ্টিতে)

"ফাইলের শেষে কোনও নিউলাইন নেই" সংকলক সতর্কতা

Comments

জিসিসি ফাইলটি প্রক্রিয়া করতে অক্ষম, এটি সি স্ট্যান্ডার্ডের অংশ হিসাবে সতর্কতা দিতে হবে।

— বিল করুন

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

— কে কে কোয়ান

Answer 7

এটি খুব প্রথম দিন থেকেই উদ্ভূত হয়েছিল যখন সাধারণ টার্মিনালগুলি ব্যবহৃত হত। নতুন লাইন চরটি স্থানান্তরিত ডেটার একটি 'ফ্লাশ' ট্রিগার করতে ব্যবহৃত হয়েছিল।

আজ, নতুন লাইনের চরটির আর প্রয়োজন নেই। অবশ্যই, নতুন লাইনটি না থাকলে অনেক অ্যাপ্লিকেশানের এখনও সমস্যা আছে তবে আমি বিবেচনা করব যে এই অ্যাপগুলিতে একটি বাগ।

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

Comments

আজকাল পাঠ্য ফাইলগুলির জন্য ইওএফ-তে নতুন লাইনটি কোনও প্রয়োজন হতে পারে না তবে এটি একটি দরকারী কনভেনশন যা বেশিরভাগ ইউনিক্স সরঞ্জামকে একত্রে ফলাফলের সাথে একত্রে কাজ করে। এটি মোটেও কোনও বাগ নয়।

— MestreLion

আমাদের মধ্যে অনেকগুলি ইউনিক্স সরঞ্জামগুলি মোটেই ব্যবহার করে না এবং আমাদের যত্ন নেই।

— ডেভওয়ালি

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

— স্যাম ওয়াটকিন্স

@ সাম ওয়াটকিন্স সম্মত হ'ল সাধারণ সুস্পষ্ট সংজ্ঞাযুক্ত ফর্ম্যাটগুলি ভাল। তবুও কোডটির এখনও সত্যতা থাকা দরকার, এবং ধরে নেওয়া যায় না, ডেটা ফর্ম্যাট অনুসারে।

— chux - মনিকা

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

— polkovnikov.ph

Answer 8

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

Comments

"নিউলাইনস" ( \n) এর পরিবর্তে "নতুন লাইনগুলি" সনাক্ত করার জন্য পৃথক এবং দোষ কেবল আপডেট করা উচিত । সমস্যা সমাধান.

— অ্যান্ড্রু

হোয়াইটস্পেসের পরিবর্তনগুলি উপেক্ষা করতে আপনি -w ট্যাগ ব্যবহার করতে পারেন তবে সেগুলি ডিফল্ট নয়।

— রবিন হিটলটন

Answer 9

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

সুতরাং, কারণগুলি হ'ল:

1. কারণ পসিক্স এটির সংজ্ঞা দেয়।
2. কারণ কিছু সরঞ্জাম এটিকে প্রত্যাশা করে বা এটি ছাড়া "দুর্ব্যবহার" করে। উদাহরণস্বরূপ, wc -lএটি একটি নতুন লাইনের সাথে শেষ না হলে একটি চূড়ান্ত "লাইন" গণনা করবে না।
3. কারণ এটি সহজ এবং সুবিধাজনক। ইউনিক্সে, catকেবল কাজ করে এবং এটি কোনও জটিলতা ছাড়াই কাজ করে। এটি ব্যাখ্যার কোনও প্রয়োজন ছাড়াই কেবল প্রতিটি ফাইলের বাইটগুলি অনুলিপি করে। আমি মনে করি না এর সমত কোনও ডস আছে cat। ব্যবহারের copy a+b cফলে ফাইলের aপ্রথম লাইনের সাথে ফাইলের প্রথম লাইনটি মার্জ হয়ে যাবে b।
4. কারণ শূন্য লাইনের একটি ফাইল (বা স্ট্রিম) একটি খালি লাইনের ফাইল থেকে আলাদা করা যায়।

Answer 10

আমি নিজেকে বছরের পর বছর ধরে ভাবছি। তবে আমি আজ একটি ভাল কারণ জুড়ে এসেছি।

প্রতিটি লাইনে একটি রেকর্ডযুক্ত একটি ফাইল কল্পনা করুন (উদা: একটি সিএসভি ফাইল)। এবং কম্পিউটারটি ফাইলের শেষে রেকর্ড লিখছিল। তবে হঠাৎ এটি বিধ্বস্ত হয়েছিল। জি শেষ শেষ লাইন ছিল? (সুন্দর পরিস্থিতি নয়)

তবে আমরা যদি সর্বদা সর্বশেষ লাইনটি বন্ধ করে দিই তবে আমরা জানতে পারি (কেবলমাত্র শেষ লাইনটি শেষ হয়েছে কিনা তা পরীক্ষা করে দেখুন)। অন্যথায় কেবল নিরাপদ থাকার জন্য আমাদের প্রতিবার শেষ লাইনটি ফেলে দিতে হবে।

Answer 11

সম্ভবত সম্ভবত কিছু পার্সিং কোড এটি উপস্থিত হবে বলে আশা করেছিল।

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

প্রকৃতপক্ষে - আপনি যদি একটি নতুন লাইনের সাথে শেষ করেন: তবে কি (তত্ত্ব অনুসারে) ইওএল এবং ইওএফ এর মধ্যে একটি ফাঁকা চূড়ান্ত রেখা আছে? এক ভাবনা ...

Comments

এটা একটা নিয়ম নয়, এটি একটি প্রচলিত রীতি আছে: একটি লাইন কিছু যে একটি সঙ্গে প্রান্ত শেষ অফ লাইন । সুতরাং না, ইওএল এবং ইওএফ এর মধ্যে কোনও "খালি চূড়ান্ত লাইন" নেই।

— MestreLion

@ ম্যাস্ট্রিলিয়ন: তবে প্রশ্নের মধ্যে থাকা চরিত্রটির নাম "শেষ-অবধি" নেই, এর নাম দেওয়া হয়েছে "নিউলাইন" এবং / অথবা "লাইনফিড"। একটি লাইন বিভাজক, লাইন টার্মিনেটর নয়। এবং ফলাফল একটি চূড়ান্ত ফাঁকা লাইন।

— বেন ভয়েগট

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

— MestreLion

@ মাস্টারলিয়ন, আপনি কি নিশ্চিত যে "লাইন টার্মিনেটর" বুদ্ধিমান? কয়েকটি অ-প্রোগ্রামার ধরুন এবং দ্রুত জরিপ করুন। আপনি দ্রুত বুঝতে পারবেন লাইনগুলির ধারণাটি "লাইন বিভাজক" এর ধারণার কাছাকাছি। "লাইন টার্মিনেটর" ধারণাটি কেবল অদ্ভুত ।

— পেসারিয়ার

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

— MestreLion

Answer 12

শেষদিকে নতুন লাইনের অভাবযুক্ত ফাইলগুলির সাথে একটি বাস্তব প্রোগ্রামিং সমস্যা রয়েছে: readবাশ অন্তর্নির্মিত (অন্যান্য readবাস্তবায়ন সম্পর্কে আমি জানি না ) প্রত্যাশার মতো কাজ করে না:

printf $'foo\nbar' | while read line
do
    echo $line
done

এই প্রিন্ট কেবলfoo ! কারণটি হ'ল যখন readশেষ লাইনের মুখোমুখি হয়, এটি লিখিত সামগ্রীগুলিতে লিখিত হয় $lineতবে প্রস্থান কোড 1 প্রদান করে কারণ এটি ইওএফ পৌঁছেছে। এটি whileলুপটি ভেঙে যায় , তাই আমরা কখনই echo $lineঅংশে পৌঁছায় না । আপনি যদি এই পরিস্থিতিটি পরিচালনা করতে চান তবে আপনাকে নিম্নলিখিতগুলি করতে হবে:

while read line || [ -n "${line-}" ]
do
    echo $line
done < <(printf $'foo\nbar')

এটি হ'ল ফাইলের শেষে একটি খালি লাইন না থাকার কারণে ব্যর্থ echoহলে তা readকরুন। স্বাভাবিকভাবেই, এক্ষেত্রে আউটপুটে একটি অতিরিক্ত নিউলাইন থাকবে যা ইনপুটটিতে ছিল না।

Answer 13

(পাঠ্য) ফাইলগুলি কেন একটি নতুন লাইনের সাথে শেষ করা উচিত?

পাশাপাশি অনেকে প্রকাশ করেছেন, কারণ:

1. অনেক প্রোগ্রাম ভাল আচরণ করে না, বা এটি ব্যর্থ হয়।

2. এমনকি যে প্রোগ্রামগুলি কোনও ফাইলকে ভালভাবে পরিচালনা করে তারও শেষের অভাব হয় '\n', তবে সরঞ্জামটির কার্যকারিতা ব্যবহারকারীর প্রত্যাশা পূরণ করতে পারে না - যা এই কোণার ক্ষেত্রে অস্পষ্ট হতে পারে।

3. প্রোগ্রামগুলি চূড়ান্তভাবে চূড়ান্ত অনুমোদন করে'\n' না (আমি এর কোনও কিছুই জানি না)।

---

তবুও এটি পরবর্তী প্রশ্নটি শুরু করে:

একটি নতুন লাইন ছাড়া পাঠ্য ফাইল সম্পর্কে কোডের কী করা উচিত?

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

   // Bad code
   while (fgets(buf, sizeof buf, instream)) {
     // What happens if there is no \n, buf[] is truncated leading to who knows what
     buf[strlen(buf) - 1] = '\0';  // attempt to rid trailing \n
     ...
   }
   

2. যদি চূড়ান্ত অনুসরণের '\n'প্রয়োজন হয় তবে ব্যবহারকারীকে তার অনুপস্থিতি এবং গৃহীত পদক্ষেপ সম্পর্কে সতর্ক করুন। আইওডাব্লু, ফাইলের ফর্ম্যাটটি যাচাই করুন। দ্রষ্টব্য: এতে সর্বাধিক লাইন দৈর্ঘ্য, অক্ষর এনকোডিং ইত্যাদির সীমা অন্তর্ভুক্ত থাকতে পারে

3. পরিষ্কারভাবে সংজ্ঞায়িত করুন, দলিল, একটি চূড়ান্ত নিখোঁজ কোডের হ্যান্ডলিং '\n'।

4. যতটা সম্ভব, শেষ হওয়ার অভাবের কোনও ফাইল তৈরি করবেন না '\n'।

Answer 14

এখানে খুব দেরি হয়ে গেছে তবে আমি ফাইল প্রসেসিংয়ে কেবল একটি বাগের মুখোমুখি হয়েছি এবং এটি এসেছিল কারণ ফাইলগুলি খালি নিউলাইন দিয়ে শেষ হচ্ছে না। আমরা টেক্সট ফাইলগুলির সাথে প্রক্রিয়াজাত করছিলাম sedএবং sedআউটপুট থেকে শেষ লাইনটি বাদ দিচ্ছিলাম যা অবৈধ জসন কাঠামোর কারণ হয়ে গিয়েছিল এবং বাকী প্রক্রিয়াটিকে ব্যর্থ স্থানে প্রেরণ করছে।

আমরা যা করছিলাম তা হ'ল:

এখানে একটি নমুনা ফাইল রয়েছে: এর ভিতরে foo.txtকিছু jsonসামগ্রী রয়েছে।

[{
    someProp: value
},
{
    someProp: value
}] <-- No newline here

বিধবা মেশিনে ফাইলটি তৈরি করা হয়েছিল এবং উইন্ডো স্ক্রিপ্টগুলি পাওয়ারশেল কমান্ড ব্যবহার করে সেই ফাইলটি প্রক্রিয়াজাত করছিল। সব ভালো.

sedকমান্ড ব্যবহার করে আমরা যখন একই ফাইলটি প্রসেস করিsed 's|value|newValue|g' foo.txt > foo.txt.tmp

সদ্য উত্পন্ন ফাইলটি ছিল

[{
    someProp: value
},
{
    someProp: value

এবং গম্ভীরভাবে, এটি অন্য প্রক্রিয়াগুলিকে ব্যর্থ করেছে কারণ অবৈধ জেএসওএন।

সুতরাং খালি নতুন লাইন দিয়ে আপনার ফাইলটি শেষ করা সবসময় ভাল অনুশীলন।

Answer 15

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

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

Answer 16

কল্পনা করুন যে ফাইলটি অন্য প্রক্রিয়া দ্বারা উত্পন্ন হওয়ার সময় ফাইলটি প্রক্রিয়াজাত করা হচ্ছে।

এর সাথে কি করতে হবে? একটি পতাকা যা নির্দেশ করে যে ফাইলটি প্রক্রিয়াজাত হওয়ার জন্য প্রস্তুত।

Answer 17

উত্স কোড ফাইলগুলির শেষে আমি ব্যক্তিগতভাবে নতুন লাইনগুলি পছন্দ করি।

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

Answer 18

আইএমএইচও, এটি ব্যক্তিগত স্টাইল এবং মতামতের বিষয়।

পুরানো দিনগুলিতে, আমি সেই নতুন লাইন রাখিনি। একটি অক্ষর সংরক্ষণ করা মানে সেই 14.4 কে মডেমের মাধ্যমে আরও গতি।

পরে, আমি সেই নিউলাইনটি রেখেছি যাতে শিফ্ট + ডাউনআরও ব্যবহার করে চূড়ান্ত লাইনটি নির্বাচন করা আরও সহজ।