Bazı derleyiciler (özellikle C veya C++ olanlar) aşağıdakiler hakkında uyarı verir:
No new line at end of file
Bunun sadece C-programcıları için bir sorun olacağını düşündüm, ancak github taahhüt görünümünde bir mesaj görüntüler:
\ No newline at end of file
PHP dosya için.
Bu iş parçacığı açıklanan önişlemci şey anlıyorum, ama bu PHP ile ne ilgisi var? Aynı
include() şey mi, yoksa
\r\n Ve
\n Konusuyla mı ilgili?
Dosyanın sonunda yeni bir satır almanın anlamı nedir?
Bu, bir dosyanın sonuna fazladan bir satırsonu eklemek değil, orada olması gereken satırsonu kaldırmama ile ilgilidir.
Metin dosyalarında çalışması gereken yardımcı programlar, yeni satırla bitmeyen dosyalarla iyi baş edemeyebilir; tarihsel Unix yardımcı programları, örneğin son satırsonundan sonra metni yoksayabilir. [~ # ~] gnu [~ # ~] utilities, metin olmayan dosyalarla düzgün davranma politikasına sahiptir ve diğer modern yardımcı programların çoğunda olduğu gibi, ancak finali eksik olan dosyalarla garip davranışlarla karşılaşabilirsiniz. newline¹.
GNU diff ile, karşılaştırılan dosyalardan biri bir satırsonu ile bitiyor ancak diğeriyle bitmiyorsa, bu gerçeği not etmekte dikkatli olun. Fark çizgi odaklı olduğundan, bunu gösteremez dosyalardan biri için yeni bir satır kaydederek ancak diğerleri için değil - yeni satırlar diff dosyasındaki her bir satırın nerede olduğunu belirtmek için gereklidir başlar ve biter Bu yüzden diff bu özel metni _
\ No newline at end of file_ to yeni satırla bitmeyen bir dosyayı, gelen bir dosyadan ayırın.
Bu arada, bir C bağlamında, bir kaynak dosya benzer şekilde bir dizi satırdan oluşur. Daha kesin olarak, bir çeviri birimi, her biri yeni satır karakteriyle bitmesi gereken bir dizi satır olarak tanımlanan bir uygulamada görüntülenir ( n1256 §220.127.116.11). Unix sistemlerde haritalama kolaydır. DOS ve Windows'da, her CR LF dizisi (_
\r\n_) yeni bir satıra (_
\n_) eşleştirilir; Yeni satır karakteri olmayan ancak bunun yerine sabit veya değişken boyutlu kayıtlara sahip birkaç işletim sistemi vardır; bu sistemlerde, dosyalardan C kaynağına eşleme _
\n_ Bu, unix ile doğrudan ilgili olmasa da, son satırını eksik olan bir C kaynak dosyasını kayıt tabanlı metin dosyaları olan bir sisteme kopyalarsanız, geri kopyalayacağınız anlamına gelir. ya ilk dönüşümde kesilen tamamlanmamış son satırla ya da ters dönüşüm sırasında üzerine eklenen yeni bir satırla sonuçlanır.
¹ Örnek: GNU sort çıktısı her zaman yeni satırla biter. Bu nedenle
foo dosyası son satırsonu eksikse _
sort foo | wc -c_ 'nin bir tane rapor ettiğini görürsünüz _
cat foo | wc -c_ 'den daha fazla karakter.
Bunun nedeni olmayabilir, ancak yeni bir satırla bitmeyen dosyaların pratik bir sonucu:
cat kullanarak birkaç dosyayı işlemek isterseniz ne olacağını düşünün. Örneğin, satırın başında 3 dosyada
foo kelimesini bulmak istiyorsanız:
cat file1 file2 file3 | grep -e '^foo'
Dosya3'teki ilk satır
foo ile başlıyor, ancak dosya2'nin son
\n son satırından sonra bu olay grep tarafından bulunmaz, çünkü dosya2'deki son satır ve dosya3'teki ilk satır grep tarafından tek bir satır olarak görülür.
Bu nedenle, tutarlılık için ve sürprizlerden kaçınmak için dosyalarımı her zaman yeni bir satırla bitirmeye çalışıyorum.
İki yönü vardır:
Bir satırsonu ile bitmezse, son satırı ayrışamayan bazı C derleyicileri vardır/vardır. C standardı, bir C dosyasının bir satırsonu (C11, 18.104.22.168, 2.) ile bitmesi gerektiğini ve satırsonu olmayan bir son satırın tanımlanmamış davranış verdiğini belirtir (C11, J.2, 2. madde). Belki de tarihi nedenlerden dolayı, böyle bir derleyicinin bazı satıcıları ilk standart yazıldığında komitenin bir parçasıydı. Böylece GCC tarafından uyarı.
diff program (
git diff, github vb.) dosyalar arasındaki satır satır farkları gösterir. Genellikle yalnızca bir dosya yeni satırla sona erdiğinde bir ileti yazdırırlar, çünkü bu farkı görmezsiniz. Örneğin, iki dosya arasındaki tek fark son satırsonu karakterinin varlığıysa, ipucu olmadan her iki dosya da aynı gibi görünecektir,
diff ve
cmp bir çıkış döndürdüğünde- eşitsiz başarıyı ve dosyaların sağlama toplamlarını kodlayın (örneğin
md5sum) eşleşmiyor.
github adresinden aldığınız
\ No newline at end of file Bir yamanın sonunda görünür (
diff biçiminde , sondaki nota bakın "Birleştirilmiş Biçim" bölümünün).
Derleyiciler dosyanın sonunda yeni satır olup olmadığını umursamaz, ancak
git (ve
diff/
patch yardımcı programları) bunları hesaba katmak zorundadır . Bunun birçok nedeni var. Örneğin, bir dosyanın sonuna yeni satır eklemeyi veya kaldırmayı unutmak, hashsum değerini değiştirir (
md5sum/
sha1sum). Ayrıca, dosyalar her zaman program değildir ve son bir
\n Fark yaratabilir.
Not : C derleyicilerinden gelen uyarı hakkında, geriye dönük uyumluluk amacıyla son satırsonu için ısrar ediyorlar.
\n (Veya sisteme bağlı başka bir satır sonu karakter dizisi) ile bitmezse çok eski derleyiciler son satırı kabul etmeyebilir.
Farklı tarih tutmanın da bir anlamı var. Bir dosya yeni satır karakteri olmadan sona ererse, dosyanın sonuna herhangi bir şey eklemek diff yardımcı programları tarafından son satırı değiştirerek görüntülenir (çünkü
\n Eklenir).
Bu,
git blame Ve
hg annotate Gibi komutlarda istenmeyen sonuçlara neden olabilir.
POSIX, bu, işletim sistemleri arasındaki uyumluluğu korumak için IEEE tarafından belirtilen bir dizi standarttır.
Bunlardan biri, sıfır veya daha fazla karakter olmayan bir sıra artı bir son satırsonu karakteri olan bir "satır" tanımıdır.
Bu nedenle, son satırın gerçek bir "satır" olarak tanınması için, yeni bir satır karakteri olması gerekir.
Satır sayısı veya bölme/yardımın dosyanızın ayrıştırılması için işletim sistemi araçlarına bağımlıysanız bu önemlidir. Verilen PHP bir betik dilidir, özellikle ilk günlerinde veya şimdi bile (tamamen hiçbir fikrim/varsayım yok) böyle OS bağımlılıkları vardı tamamen mümkündür.
Gerçekte, çoğu işletim sistemi tam olarak POSIX uyumlu değildir ve insanlar yeni hatların sonlandırılması gibi, hatta bu makineyi önemsemeyen makineler değildir. Yani çoğu şey için onun hakkında bakım, uyarı veya sadece metnin son bit gerçekten gidiyor bir çizgi olduğunu her şeyi bir smorgasbord yani sadece dahil.