È possibile dire di patchnon generare .orige .rejfile? Trovo estremamente fastidioso che la patch li crei.
È possibile dire di patchnon generare .orige .rejfile? Trovo estremamente fastidioso che la patch li crei.
Risposte:
Se non stai offrendo alcuna opzione a parte patchquella -pN, crea quei file solo quando una patch non si applica in modo pulito.
Pertanto, un'opzione è quella di interrompere la creazione (o l'accettazione) di patch errate. :)
Indietro nel mondo reale, questa è una caratteristica. Quando patch(1)non riesce ad applicare un segmento di patch al file originale, salva la copia del file originale temporaneo in modo duraturo come *.orig, scarica il segmento rifiutato *.reje continua a provare ad applicare segmenti di patch. L'idea è che è possibile aprire il *.rejfile e completare manualmente il processo di patch copiando bit e pezzi nel file patchato. Il *.origfile può anche essere utile quando il processo di patch rovina accidentalmente qualcosa ed è necessario fare riferimento alla versione originale per risolverlo.
Non aggiorno sempre una brutta patch con il testo dei file *.reje *.orig, ma è bello averli nel caso ne avessi bisogno.
Dopo aver corretto una patch errata, eseguo il seguente script nella radice del progetto per ripulire rapidamente le cose:
#!/bin/bash
find . '(' \
-name \*-baseline -o \
-name \*-merge -o \
-name \*-original -o \
-name \*.orig -o \
-name \*.rej \
')' -delete
Lo chiamo cleanup-after-bad-patchperché il nome lungo assicura in parte contro l'esecuzione accidentale, poiché potrebbe rimuovere i file ancora necessari. Ad essere sincero, però, normalmente lo eseguo digitando cleanTabEnter, che è sufficiente per trovare questo script nei PATHmiei computer di sviluppo.
I pattern aggiuntivi che controlla sono per i file emessi dal mio sistema di controllo versione scelto quando incontra lo stesso problema durante un'operazione di unione. Potresti volerlo regolare per i tuoi strumenti VCS / SCM .
A dire patch non ai backup produrre basta omettere il -bed eventuali --backup-...opzioni.
Per indicare di non creare .rejfile, aggiungere l' -r -opzione al comando.
GNU patch 2.6Mac, forse prova-r /dev/null
L' --no-backup-if-mismatchopzione eviterà i file ".orig".
Potresti anche provare l' --mergeopzione, che crea un conflitto nel file.
In tutti i casi dovresti avere un modo per tornare rapidamente a un buono stato se l'unione diventa schiacciante.
Sono bloccato con la patch v2.5.4 dove -r -causa la creazione di file di rifiuto denominati -.
Ho scoperto che, ad --reject-file=esempio, un valore vuoto provoca il fallimento della patch con il codice di uscita 2 SE tenta di scrivere un file di rifiuto. Se non ci sono scarti, funziona come previsto. Sebbene non sia una soluzione completa per la versione precedente della patch, in alcune circostanze ciò può essere accettabile o desiderato.
Il meglio che potrei trovare (certamente un modo per spazzare lo sporco sotto il tappeto) sta usando -r <tmpfile>, cioè:
# patch -r /tmp/deleteme.rej -i patchfile filetobepatched
poiché nella v2.5.8, -r -crea effettivamente il -file.
patch -p1 -B / dev / null -r - <file.patch
-Bflag non invia l' *.origoutput a /dev/null, come sembra dal tuo comando. Succede semplicemente che gli utenti normali non possono scrivere su file chiamati cose come /dev/nullfoo.cpp. Se lo fai come root, otterrai invece spazzatura nel tuo /devalbero. Secondo, -r -non sopprime il *.rejfile. Sembra proprio che lo faccia perché l'errore dovuto al -Bflag fasullo gli impedisce di mostrarti cosa farebbe davvero senza il -B, che è creare un file chiamato -nella directory corrente.
man patch: "-r Metti gli scarti nel file di rifiuto invece del file .rej predefinito. Quando il file di rifiuto è -, elimina gli scarti."