md5sum sağlama toplamına '\' hazırlanıyor

Adında "\" olan bir dosyanın sağlama toplamını bulurken neden md5sum sağlama toplamı önünde "\" hazırlanıyor?

$ md5sum /tmp/test\\test
\d41d8cd98f00b204e9800998ecf8427e  /tmp/test\\test

Aynısı diğer her bir yardımcı program için belirtilmiştir.

hashsum coreutils checksum

— jsaji
kaynak

Sadece referans *sumolarak md5sum, sha1sumGNU coreutils içindeki diğer programlar ( e, g, vb. İle aynı aileden ) aynı şeyi yapar.

— Kusalananda

Bu davranışı görmüyorum, yardımcı programın sürümü nedir:md5sum --version

— Kiwy

@Kusalananda Bu coreutils sürümüne özgü olabilir; CentOS 7'de cksum; örneğin% cksum test\\test 3915528286 4 test\test

— Stephen Harris,

@StephenHarris Muhtemelen bunun nedeni cksumbir POSIX yardımcı programı ve özelliğidir. izin vermiyor.

— Kusalananda

Yanıtlar:

Bu edilir belgelenmiş , coreutils için md5sum:

Eğer dosya bir ters eğik çizgi veya satır başı karakteri içeren, çizgi ters eğik çizgi başlatılır ve dosya adına her sorunlu karakteri bile keyfi dosya adları varlığında kesin çıkış yaparak, ters eğik çizgiyle edilir.

( dosya , dosya içeriğini değil dosya adıdır).

b2sum, sha1sumve çeşitli SHA-2 araçları aynı şekilde davranır md5sum. sumve cksumyapma; sumsadece geriye doğru uyumluluk için sağlanır (ve ataları çıkış alıntı üretmeyen) ve cksumbir POSIX tarafından belirlenen ve çıkış, bu tür izin vermez.

Bu davranış Kasım 2015'te tanıtıldı ve aşağıdaki NEWSgirişle 8.25 (Ocak 2016) sürümünde yayınlandı :

md5sumşimdi standart çıktıdaki durum için dosya başına tek bir satır sağlar, satırın başında bir '\' kullanarak ve yeni satırları '\ n' ile değiştirir. Bu aynı zamanda etkiler sha1sum, sha224sum, sha256sum, sha384sumve sha512sum.

Satırın başındaki ters eğik çizgi bir bayrak görevi görür: dosya adlarında kaçışlar, yalnızca satır ters eğik çizgiyle başlarsa işlenir. (Unescaping varsayılan davranış olamaz: bu , depolanan dosya adlarını içeren \\veya \niçinde bulunan Coreutils'in eski sürümleriyle oluşturulan toplamları kırar .)

— Stephen Kitt
kaynak

Yine de, mansayfalarda belgelenmemiş olması gibi tamamen sezgisel olmayan bir şey . (Ve evet, GNU’nun herkesin çok iyi kıvrılmış infosayfalarını okumasını istediğini

— biliyorum

@ satırın başındaki ters eğik çizgi, dosya adındaki ters eğik çizgilerin kaçma olduğunu belirten bir bayrak olarak hizmet eder; Aksi halde, değişmeyeceklerini \nvb. değişmezler veya kaçanlar olarak işlemeyi bilemezsiniz .

— Stephen Kitt

@ msouth eğer dosya adının başındaysa, bayrak mı, yoksa ters eğik çizgiyle başlayan bir dosya adı mı olduğunu bilmenin hiçbir yolu yok ...

— Stephen Kitt

@StephenKitt Ben lider \ sanmıyorum karalama için orada olduğunu sanmıyorum. Çıktının her zaman ters eğik çizgi ve yeni satırlardan kaçış olarak belgelenmesi durumunda belirsizlik yoktur . O orada, bu yüzden kaçma işlemi gerekmediğinde yapılmak zorunda kalmayacak. Buna değip değmeyeceğini elbette tartışabilirsiniz (şahsen öyle olmadığını düşünüyorum ama coreutilskatkıda bulunmuyorum ).

— TipIA

Belgelerin "dosya adındaki her sorunlu karakter ters eğik çizgiyle kaçtı" ifadesi yanlıştır; yeni bir satırı değiştirmek, yeni \nbir satırın ters eğik çizgiyle kaçması ile aynı değildir!

— ruakh

Stephen Kitt'in cevabı neyi kapsıyor ve bu değişikliğin neden uygulandığını anlatmaya çalışacağım . İlk olarak, birisi yeni satır ¹ içeren bir dosya adının sonuçlanabileceğini gözlemledi . belirsiz bir çıktıya . Örneğin, bu çıktıyı göz önünde bulundurun:

d41d8cd98f00b204e9800998ecf8427e  foo
25af89c92254a806b2e93fffd8ac1814  bar

İki dosya Bunun anlamı vardı mı foove barya kimin dosya adı sadece bir dosya"foo\n25af89c92254a806b2e93fffd8ac1814 bar" ? Verilmiş, bu ikinci olasılık oldukça düşüktür, ancak mümkündür. Belirsizliği gidermek için geliştiriciler ters eğik çizgi ile yeni çizgilerden kaçmayı seçti ( \). Çıktı daha sonra ayırt edilebilir hale gelir. Ancak, o zaman başka bir belirsizlik var:

764efa883dda1e11db47671c4a3bbd9e  foo\nbar

Bu dosyanın adı yeni bir satır mı yoksa arkasından n mu? Bunu çözmek için ters eğik çizgiden de çıkmamız gerekir, böylece ikinci durum şöyle olur:

764efa883dda1e11db47671c4a3bbd9e  foo\\nbar

Son olarak, \\bir çözümleyicinin kaçmanın yapılıp yapılmadığını tespit etmesini kolaylaştıracak bir kaçış içeren her bir çıktı hattını hazırlamayı seçtiler . Muhtemelen bu, ayrıştırıcıların hem kaçan sürümlerden hem de kaçan md5sumolmayan sürümlerden (GNU dışı) çıkan çıktıları işlemesine izin vermek için yapıldı . Bayrak ayrıca, "maliyetli" kaçmanın, gerekli olmadığında yapılması gerekmediği anlamına gelir. Bu ayrıştırma işleminin md5sum.ckendi içinde bir eylem olduğunu görebilirsiniz (bağlı sürümde satır 382).

¹ ile yeni satır bir karakter anlamına \nbazen özel olarak da ifade edilir satır besleme veya LF ; bkz md5sum.c.

— TypeIA
kaynak

Tabii aklı başında davranış, yeni bir satır içeren her dosyayı tamamen yasaklamak olacaktır . Sadece onları işlemeyi reddediyorum.

— boru

@pipe bu delice bir davranış. POSIX bu tür dosya adlarına izin verir ve kasıtlı olarak meşru dosyalarla çalışmayı reddeden kuruluşlar kötüdür ve ateşle öldürülmesi gerekir.

— Ruslan,

@Ruslan Amaç, bu tür antisosyal isimlere izin vermek için POSIX'e karşı protesto yapmaktır . Bu tür karakterlere izin vermek, büyük olasılıkla büyük miktarda güvenlik sorununa neden olmuş ve bu özel durumları ele almak için kod ihlaline neden olmuştur.

— pipo

Bir dosya adında LF gerçekten antisosyal iken, bağlantınızda belirtilen diğer şeyler çok daha tartışılabilir - benzeri boşluklar, latin olmayan harfler vb ..

— Ruslan

Mühendisler tarafından klasik aşırı mühendislik. Ders (yine): mühendislerin gereksinimleri sürmesine izin verme. En karanlık ve karmaşık vakayı bulacaklar ve onu hâkim olaya yükseltecekler ve herkesin kafasını karıştıracaklar.