Czy jest możliwe, aby powiedzieć patch
, aby nie generować .orig
i .rej
pliki? Uważam, że to bardzo denerwujące, że łatka je tworzy.
Czy jest możliwe, aby powiedzieć patch
, aby nie generować .orig
i .rej
pliki? Uważam, że to bardzo denerwujące, że łatka je tworzy.
Odpowiedzi:
Jeśli nie podajesz żadnej opcji patch
innej niż -pN
, tworzy te pliki tylko wtedy, gdy łatka nie zastosuje się czysto.
Tak więc jedną z opcji jest zaprzestanie tworzenia (lub akceptowania) złych łat. :)
W prawdziwym świecie jest to funkcja. Gdy patch(1)
nie zastosuje segmentu poprawki do oryginalnego pliku, trwale zapisuje tymczasową kopię oryginalnego pliku, ponieważ *.orig
zrzuca odrzucony segment *.rej
i kontynuuje próbę zastosowania segmentów poprawki. Chodzi o to, że możesz otworzyć *.rej
plik i ukończyć proces łatania ręcznie, kopiując bity i kawałki do łatanego pliku. *.orig
Plik może być również przydatna, gdy proces łata przypadkowo wraki coś i trzeba odnosić się do pierwotnej wersji, aby go naprawić.
Nie zawsze naprawiam złą łatkę z tekstem z plików *.rej
i *.orig
, ale miło jest mieć je na wypadek, gdyby były potrzebne.
Po naprawieniu złej poprawki uruchamiam następujący skrypt w katalogu głównym projektu, aby szybko wyczyścić rzeczy:
#!/bin/bash
find . '(' \
-name \*-baseline -o \
-name \*-merge -o \
-name \*-original -o \
-name \*.orig -o \
-name \*.rej \
')' -delete
Nazywam to, cleanup-after-bad-patch
ponieważ długa nazwa częściowo zabezpiecza przed przypadkowym uruchomieniem tego, ponieważ może usunąć potrzebne pliki. Szczerze mówiąc, zwykle uruchamiam go pisząc clean
TabEnter, że to wystarczy, aby znaleźć ten skrypt PATH
na moich komputerach programistycznych.
Dodatkowe wzorce, które sprawdza, dotyczą plików wyjściowych mojego wybranego systemu kontroli wersji, gdy napotka ten sam problem podczas operacji scalania. Możesz dostosować to do swoich narzędzi VCS / SCM .
Aby powiedzieć patchowi, aby nie tworzył kopii zapasowych, po prostu pomiń -b
wszystkie --backup-...
opcje.
Aby nakazać, aby nie tworzył .rej
plików, dodaj -r -
opcję do polecenia.
GNU patch 2.6
-r /dev/null
--no-backup-if-mismatch
Opcja pozwoli uniknąć pliki „.orig”.
Możesz także wypróbować --merge
opcję, która powoduje konflikt wewnątrz pliku.
We wszystkich przypadkach powinieneś mieć jakiś sposób, aby szybko wrócić do dobrego stanu, jeśli scalenie stanie się przytłaczające.
Utknąłem z łatką v2.5.4, która -r -
powoduje, że tworzy pliki odrzucania o nazwie-
.
Odkryłem, że --reject-file=
np. Pusta wartość powoduje, że łatka kończy się niepowodzeniem z kodem wyjścia 2
JEŻELI próbuje zapisać plik odrzucenia. Jeśli nie ma żadnych odrzuceń, działa zgodnie z oczekiwaniami. Chociaż nie jest to kompletne rozwiązanie dla starszej wersji łatki, w niektórych okolicznościach może to być dopuszczalne lub pożądane.
Najlepsze, co mogłem wymyślić (co prawda sposób na zamiatanie brudu pod dywan) to -r <tmpfile>
:
# patch -r /tmp/deleteme.rej -i patchfile filetobepatched
ponieważ w wersji 2.5.8 -r -
faktycznie tworzy -
plik.
łatka -p1 -B / dev / null -r - <plik.patch
-B
flaga nie wysyła danych *.orig
wyjściowych /dev/null
, jak się wydaje z polecenia. Zdarza się, że zwykli użytkownicy nie mogą pisać do plików zwanych takimi jak /dev/nullfoo.cpp
. Jeśli zrobisz to jako root, /dev
zamiast tego dostaniesz śmieci w swoim drzewie. Po drugie, -r -
nie pomija *.rej
pliku. Po prostu wydaje się to robić, ponieważ błąd spowodowany fałszywą -B
flagą powstrzymuje go przed pokazaniem, co tak naprawdę zrobiłby bez -B
, czyli do utworzenia pliku o nazwie -
w bieżącym katalogu.
man patch
: „-r Umieść odrzucenia w pliku odrzuconym zamiast domyślnego pliku .rej. Gdy plikiem odrzuconym jest -, odrzuć odrzuca”.