Bu cevap, görüşten ziyade teknik bir cevap girişimidir.
POSIX safları olmak istiyorsak, bir satırı şu şekilde tanımlarız:
Sıfır veya daha fazla <newline> karakterin yanı sıra sonlandırıcı <newline> karakteri.
Kaynak: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
Eksik satır:
Dosyanın sonunda bir veya daha fazla <newline> olmayan karakter dizisi.
Kaynak: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_195
Şu şekilde bir metin dosyası:
Sıfır veya daha fazla satır halinde düzenlenmiş karakterler içeren bir dosya. Satırlar NUL karakter içermez ve hiçbiri <newline> karakteri de dahil olmak üzere {LINE_MAX} bayt uzunluğunu aşamaz. POSIX.1-2008 metin dosyaları ve ikili dosyalar arasında ayrım yapmasa da (ISO C standardına bakın), çoğu yardımcı program metin dosyaları üzerinde çalışırken yalnızca öngörülebilir veya anlamlı çıktı üretir. Bu tür kısıtlamaları olan standart yardımcı programlar, STDIN veya INPUT FILES bölümlerinde her zaman "metin dosyaları" belirtir.
Kaynak: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_397
Aşağıdaki gibi bir dize:
İlk boş bayt tarafından ve bu son bayt dahil sonlandırılmış bir bayt dizisi.
Kaynak: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_396
Bundan sonra, herhangi bir sorunla potansiyel olarak karşılaşacağımız tek zamanın , bir dosya satırı veya bir metin dosyası olarak bir dosya kavramıyla uğraşmamızdır (bir metin dosyasının sıfır organizasyon olması) veya daha fazla satır ve bildiğimiz bir satır <newline> ile sonlanmalıdır).
Tipik bir örnek: wc -l filename.
Gönderen wckılavuzuna okuyoruz:
Satır, <newline> karakteriyle ayrılmış karakter dizesi olarak tanımlanır.
JavaScript, HTML ve CSS dosyalarına metin dosyaları olmalarının etkileri nelerdir?
Tarayıcılarda, modern IDE'lerde ve diğer ön uç uygulamalarında EOF'ta EOL'yi atlamakla ilgili bir sorun yoktur. Uygulamalar dosyaları düzgün şekilde ayrıştırır. Tüm İşletim Sistemleri POSIX standardına uygun olmadığından, dosyaları POSIX standardına (veya herhangi bir OS seviyesi standardına) göre işlemek, işletim sistemi olmayan araçların (örn. Tarayıcılar) pratik olmayacaktır.
Sonuç olarak, bir UNIX işletim sisteminde çalışıyor olsa da, EOF'daki EOL'nin uygulama düzeyinde neredeyse hiçbir olumsuz etkisi olmayacağından emin olabiliriz.
Bu noktada, istemci tarafında JS, HTML, CSS ile uğraşırken EOF'da EOL atlamanın güvenli olduğunu söyleyebiliriz. Aslında, <newline> içermeyen bu dosyalardan herhangi birini küçültmenin güvenli olduğunu belirtebiliriz.
Bunu bir adım öteye taşıyabilir ve NodeJS söz konusu olduğunda, POSIX standardına uygun olarak POSIX uyumlu olmayan ortamlarda çalışabileceğini söyleyebiliriz.
O zaman ne kaldı? Sistem düzeyinde takımlama.
Bu, ortaya çıkabilecek tek sorunların, işlevlerini POSIX'in semantiğine uymaya çalışan araçlarla ilgili olduğu anlamına gelir (örneğin, gösterildiği gibi bir çizginin tanımı wc).
Yine de, tüm mermiler POSIX'e otomatik olarak yapışmaz. Örneğin Bash, POSIX davranışını varsayılan olarak kullanmaz. Etkinleştirmek için bir geçiş vardır: POSIXLY_CORRECT.
EOL'nin <newline> olmasının değeri üzerine düşünülen yiyecekler: https://www.rfc-editor.org/old/EOLstory.txt
Takım pistinde kalmak, tüm pratik amaçlar ve amaçlar için şunu düşünelim:
EOL'si olmayan bir dosyayla çalışalım. Bu yazıda, bu örnekteki dosya EOL içermeyen küçültülmüş bir JavaScript'tir.
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
catDosya boyutunun, tek tek parçalarının toplamı olduğuna dikkat edin . JavaScript dosyalarının birleştirilmesi JS dosyaları için bir endişe kaynağıysa, her JavaScript dosyasını noktalı virgülle başlatmak daha uygun bir sorundur.
Bu iş parçacığında başka birisinin de belirttiği gibi: catçıktısı iki yerine yalnızca bir satır haline gelen iki dosya istiyorsanız ? Başka bir deyişle, catyapması gerekeni yapar.
manArasında catsadece EOF'a girdi okuma bahseder değil, <satır>. -nAnahtarının catayrıca , sayının 1'de ( . ' Ye göre ) başladığı satır olarak, <newline> sonlandırılmamış satırı (veya eksik satırı ) yazdıracağını unutmayın .man
-n 1'den başlayarak çıkış hatlarını numaralandırın.
POSIX'in bir çizgiyi nasıl tanımladığını anladığımıza göre , bu davranış belirsiz veya gerçekten uyumlu değildir.
Belirli bir aracın amacını ve uyumluluğunu anlamak, dosyaları bir EOL ile sonlandırmanın ne kadar kritik olduğunu belirlemeye yardımcı olacaktır. C, C ++, Java (JARs, vb.) 'De bazı standartlar geçerlilik için yeni bir satır belirler - JS, HTML, CSS için böyle bir standart yoktur.
Örneğin, wc -l filenamebirini kullanmak yerine awk '{x++}END{ print x}' filename, görevin başarısının bir dosya tarafından tehlikeye atılmadığından emin olun, yazmadığımızı işlemek isteyebiliriz (örneğin, yaptığımız küçültülmüş JS gibi bir üçüncü taraf kütüphanesi curl) - niyet gerçekten POSIX uyumlu anlamda hatları saymaktı .
Sonuç
JS, HTML ve CSS gibi belirli metin dosyaları için EOF'ta EOL atlamanın olumsuz bir etkisi olacağı çok az gerçek hayat kullanım örneği olacaktır. <newline> 'ın varlığına güvenirsek, takımlarımızın güvenilirliğini yalnızca yazar olduğumuz dosyalarla sınırlandırırız ve kendimizi üçüncü taraf dosyaları tarafından getirilen olası hatalara kadar açarız.
Hikayenin ahlakı: EOF'ta EOL'ye güvenmenin zayıflığı olmayan mühendis araçları.
EOL atlamanın nasıl olumsuz bir etkisi olduğunu inceleyebileceğimiz JS, HTML ve CSS için geçerli oldukları için kullanım durumlarını yayınlamaktan çekinmeyin.