Polecenie usuwające komunikat o subskrypcji: najczęstsza jednolinijka, najcichsza szkoda

Zainstalowałeś Proxmoksa, zalogowałeś się i pojawił się komunikat o subskrypcji. Denerwuje, bo wraca przy każdym logowaniu. Szukasz, znajdujesz jednolinijkowe polecenie. Wygląda, że działa.

Ten wpis dotyczy tego polecenia, ale jego prawdziwym tematem nie jest polecenie: cicha cena wklejania czegoś, czego nie rozumiesz.

Zmierzony błąd

W szeroko krążącej jednolinijce siedzi prawdziwa wada, i jest subtelna.

W podstawowych wyrażeniach regularnych klasycznych narzędzi tekstowych kreska pionowa zapisana z ukośnikiem odwrotnym nie jest zwykłym znakiem, tylko operatorem alternatywy. Warunek w kodzie interfejsu zawiera dwie kreski, a gdy polecenie ucieka je w takiej postaci, między dwoma operatorami alternatywy powstaje pusta alternatywa.

Pusta alternatywa pasuje do każdego miejsca w pliku. W połączeniu z zamianą wszystkiego wyrażenie rozsypuje zmianę po całym pliku.

To nie jest domysł. Zmierzono to na kopii prawdziwego pliku: zmieniło się 26458 z 26458 wierszy, a liczba wystąpień false w pliku wzrosła z 558 do 26458. Administrator, który uruchomiłby to polecenie, zepsułby całą bibliotekę interfejsu Proxmoksa.

Na to nakłada się drugi problem: docelowy warunek nie mieści się w jednym wierszu, Proxmox rozkłada go na sześć. Narzędzie pracujące wiersz po wierszu i tak nigdy nie mogłoby go poprawnie dopasować.

Dlaczego nikt tego nie zauważył

Bo szkoda jest cicha. Polecenie nie zgłasza błędu, nic na ekranie nie czerwienieje. Interfejs może przez jakiś czas działać dalej, kłopot wychodzi później, a w tym momencie nikt nie łączy go z poleceniem wklejonym tydzień wcześniej.

Ogólna lekcja z tego: zdanie, że wszystkim działa, nie jest dowodem. Najczęściej jest tylko dowodem, że nikt nie sprawdził.

Cztery reguły dla każdej zmiany tej klasy

Każda operacja dotykająca pliku systemowego, kimkolwiek jest wykonawca, musi nieść te cztery reguły.

Kopię robi się raz i nigdy jej nie nadpisuje. Odświeżanie kopii przy każdym uruchomieniu oznacza, że za drugim razem robisz kopię stanu zepsutego.

Cel jest wąski. Jeśli docelowy tekst naprawdę się zmienił, operacji się nie wykonuje. Zmiana najbliższej rzeczy na wyczucie jest gorsza niż niezmienianie niczego.

Plik czyta się po zapisie. Jeśli oczekiwany wynik się nie pojawił, przywraca się kopię. To, że zapis nie zgłosił błędu, nie znaczy, że zapisał właściwą rzecz.

Zostawia się znacznik. Na pytanie, czy ten plik jest załatany, ma odpowiadać obecność oznaczenia, a nie zgadywanie.

Przypadek, o którym nikt nie myśli: co, jeśli kopia jest już zepsuta

Nawet wykonanie wszystkich czterech reguł zostawia jedną lukę. Co, jeśli inne narzędzie zepsuło plik wcześniej, a ty zrobiłeś kopię po tym?

Wtedy wycofanie przywraca zepsuty plik, a ty jesteś przekonany, że naprawiłeś. Dlatego także wycofanie trzeba sprawdzić: czy oryginał naprawdę wrócił, czy sama kopia była już załatana?

To przykład pytania, które trzeba stale zadawać przy pracy z zainstalowaną maszyną: nie co dzieje się na czystej instalacji, tylko co dzieje się na maszynie niosącej stary stan.

Co robi Atlas

Atlas wykonuje tę pracę wewnątrz produktu, a nie przez wklejenie polecenia, i stosuje wszystkie cztery powyższe reguły.

Kopia jest robiona raz i nigdy nadpisywana. Cel jest wąski: wzorzec elastyczny wobec białych znaków, ale dokładny co do reszty, więc trzyma się nawet gdy Proxmox zmieni formatowanie, ale jeśli sam warunek się zmienił, nic nie jest robione. Po zapisie plik jest odczytywany i weryfikowany; jeśli oczekiwany wynik się nie pojawi, kopia zostaje przywrócona. A wstawiany tekst niesie znacznik, więc na pytanie o załatanie odpowiada się z pewnością.

Po stronie wycofania obsłużony jest też ostatni z powyższych przypadków: po przywróceniu kopii sprawdza się, czy oryginał naprawdę wrócił, a jeśli nie, mówi się to wprost.

Jedno zdanie, które ten wpis naprawdę chce powiedzieć, brzmi tak: praca nie jest trudna, ale różnica między zrobieniem jej dobrze a sprawianiem wrażenia, że działa, przebiega przez pomiar.