md5sum antepone '\' al checksum

Perché md5sum sta anteponendo "\" davanti al checksum quando trova il checksum di un file con "\" nel nome?

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

Lo stesso si nota per ogni altra utilità.

hashsum coreutils checksum

— jsaji
fonte

Solo per riferimento, le altre *sumutility (della stessa famiglia di md5sum, e, g, sha1sumecc.) Nei coreutils GNU fanno lo stesso.

— Kusalananda

Non vedo questo comportamento, qual è la versione dell'utilità:md5sum --version

— Kiwy,

@Kusalananda Potrebbe trattarsi di una versione specifica di coreutils; su CentOS 7 cksumno; ad es.% cksum test\\test 3915528286 4 test\test

— Stephen Harris,

@StephenHarris Questo probabilmente è perché cksumè un'utilità POSIX e le sue specifiche. non lo consente.

— Kusalananda

Risposte:

Questo è documentato , per Coreutils md5sum:

Se il file contiene una barra rovesciata o una nuova riga, la riga viene avviata con una barra rovesciata e ogni carattere problematico nel nome del file viene eliminato con una barra rovesciata, rendendo l'output inequivocabile anche in presenza di nomi di file arbitrari.

(il file è il nome del file, non il contenuto del file).

b2sum, sha1sume i vari strumenti SHA-2 si comportano allo stesso modo di md5sum. sume cksumnon farlo; sumviene fornito solo per compatibilità con le versioni precedenti (e i suoi antenati non producono output tra virgolette), cksumè specificato da POSIX e non consente questo tipo di output.

Questo comportamento è stato introdotto a novembre 2015 e rilasciato nella versione 8.25 (gennaio 2016), con la seguente NEWSvoce:

md5sumora assicura una singola riga per file per lo stato sull'output standard, usando un '\' all'inizio della riga e sostituendo tutte le nuove righe con '\ n'. Questo riguarda anche sha1sum, sha224sum, sha256sum, sha384sume sha512sum.

La barra rovesciata all'inizio della riga funge da flag: le fughe nei nomi dei file vengono elaborate solo se la riga inizia con una barra rovesciata. (L'escaping non può essere il comportamento predefinito: spezzerebbe le somme generate con versioni precedenti di Coreutils contenenti \\o \nnei nomi di file memorizzati.)

— Stephen Kitt
fonte

È un peccato che qualcosa di completamente non intuitivo come questo non sia documentato nelle manpagine, però. (E sì, sono consapevole che GNU vuole invece che tutti leggano le loro infopagine altamente contorte .)

— roaima,

@msouth la barra rovesciata all'inizio della riga funge da flag che indica che le barre rovesciate nel nome file sono escape; altrimenti non sapresti se elaborare \necc. come letterali o fughe.

— Stephen Kitt,

@msouth se è all'inizio del nome file, non hai modo di sapere se si tratta della bandiera o di un nome file che inizia davvero con una barra rovesciata ...

— Stephen Kitt,

@StephenKitt Non credo che il leader \ sia lì per chiarimenti. Non c'è ambiguità se l'output è documentato come sempre in backslash e newline in escape. È lì in modo che la de-fuga non debba essere eseguita se non necessario. Puoi ovviamente discutere se ne vale la pena (personalmente penso che non lo sia, ma non sono un coreutilscollaboratore).

— TypeIA,

La frase della documentazione "ogni carattere problematico nel nome del file è sfuggito con una barra rovesciata" è errato; sostituire una nuova riga con \nnon equivale a sfuggire a una nuova riga con una barra rovesciata!

— Ruakh,

La risposta di Stephen Kitt copre cosa e cercherò di capire perché questo cambiamento è stato implementato. In primo luogo, qualcuno ha osservato che un nome file contenente newline ¹ potrebbe generare risultati ambigui . Ad esempio, considera questo output:

d41d8cd98f00b204e9800998ecf8427e  foo
25af89c92254a806b2e93fffd8ac1814  bar

Questo significa che c'erano due file fooe bar, o solo un file il cui nome file è "foo\n25af89c92254a806b2e93fffd8ac1814 bar"? Certo, quest'ultima possibilità è altamente improbabile, ma è possibile. Per risolvere l'ambiguità gli sviluppatori hanno scelto di sfuggire a nuove righe con una barra rovesciata ( \). L'output diventa quindi distinguibile. Tuttavia, allora c'è un'ulteriore ambiguità:

764efa883dda1e11db47671c4a3bbd9e  foo\nbar

Il nome di questo file contiene una nuova riga o una barra rovesciata seguita da un n? Per risolvere questo, dobbiamo evitare anche le barre rovesciate, in modo che quest'ultimo caso diventi:

764efa883dda1e11db47671c4a3bbd9e  foo\\nbar

Alla fine, hanno scelto di anteporre ogni riga di output che contiene tali escape con a \\per rendere più semplice per un parser rilevare se l'escaping è stato eseguito. Presumibilmente, ciò è stato fatto per consentire ai parser di gestire l'output sia da versioni con escape che da versioni md5sumsenza escape (non GNU). La bandiera significa anche che non è necessario effettuare la fuga "costosa" quando non è necessario. Puoi vedere un esempio di questa analisi in azione md5sum.c(riga 382 nella versione collegata).

¹ Per newline intendo il personaggio \nche a volte viene anche specificamente indicato come avanzamento di riga o LF ; vedi md5sum.c.

— TypeIA
fonte

Naturalmente il comportamento sano sarebbe quello di vietare completamente ogni file contenente una nuova riga. Rifiuta solo di elaborarli.

— pipe

@pipe è un comportamento folle . POSIX consente tali nomi di file e le utilità che si rifiutano intenzionalmente di lavorare con file legittimi sono dannose e devono essere eliminate con il fuoco.

— Ruslan,

@Ruslan Il punto è protestare contro POSIX per aver permesso tali nomi antisociali . Consentire tali personaggi ha probabilmente causato una grande quantità di problemi di sicurezza e un eccesso di codice solo per gestire casi così speciali.

— pipe

@pipe mentre LF nel nome di un file è davvero antisociale, altre cose menzionate nel tuo link sono molto più discutibili - come spazi, lettere non latine ecc.

— Ruslan

Sovraingegneria classica da parte degli ingegneri. Lezione (ancora una volta): non consentire agli ingegneri di soddisfare i requisiti. Troveranno il caso più oscuro e contorto, lo eleveranno al caso dominante e confonderanno tutti.