Znaczenie wiersza „exec tail -n +3 $ 0” w pliku 40_custom

Próbuję zrozumieć pliki konfiguracyjne grub. Podczas tego procesu natknąłem się na plik /etc/grub.d/40_custom . Mój plik zawiera następujące wiersze:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Windows 10" --class windows --class os {
insmod part_msdos
savedefault
insmod ntfs
insmod ntldr
set root='(hd0,msdos1)'
ntldr ($root)/bootmgr
}

ponieważ mój system ma podwójny rozruch i najwyraźniej jest to program ładujący dla systemu Windows 10.

Moje pytanie dotyczy jednak tej części exec tail -n +3 $0.
Jeśli odszyfrowuję go poprawnie, oznacza to po prostu wydrukowanie ostatnich linii, zaczynając od 3. linii ( +3) pliku $0. $0oczywiście w tym przypadku jest to plik /etc/grub.d/40_custom .

Dlaczego więc używamy tego polecenia w pliku 40_custom ? Jak rozumiem, wynik byłby taki sam, gdyby ιt został całkowicie pominięty. Jedyne, o czym mógłbym pomyśleć, to pierwsza linia identyfikująca tłumacza:

#!/bin/sh

Ale potem znowu jest wykonywany, ponieważ exec tail -n +3 $0następuje po nim. Czy to tylko konwencja (bezużyteczna)?

Sztuką jest to, co exec:

$ help exec
exec: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
    Replace the shell with the given command.

    Execute COMMAND, replacing this shell with the specified program.
    ARGUMENTS become the arguments to COMMAND.  If COMMAND is not specified,
    any redirections take effect in the current shell.

Oznacza to, że execw tym przypadku zastąpi powłokę tym, co zostało dane tail. Oto przykład tego w akcji:

$ cat ~/foo.sh
#!/bin/sh
exec tail -n +3 "$0"
echo foo

$ ./foo.sh
echo foo

Więc echopolecenie nie jest wykonywane, ponieważ zmieniliśmy powłokę i używamy tailzamiast tego. Jeśli usuniemy exec tail:

$ cat ~/foo.sh
#!/bin/sh
echo foo
$ ./foo.sh
foo

Jest to więc fajna sztuczka, która pozwala napisać skrypt, którego jedynym zadaniem jest wyprowadzenie własnej zawartości. Przypuszczalnie wszystkie wywołania 40_customoczekują, że ich zawartość zostanie wyświetlona. Oczywiście rodzi się pytanie, dlaczego nie po prostu biegać tail -n +3 /etc/grub.d/40_custombezpośrednio.

Zgaduję, że odpowiedź brzmi, ponieważ grub używa własnego języka skryptowego, a to wymaga tego obejścia.

Katalog /etc/grub.d/zawiera wiele plików wykonywalnych (zwykle skrypty powłoki, ale możliwy jest także każdy inny typ pliku wykonywalnego). Ilekroć grub-mkconfigzostanie wykonany (np. Jeśli uruchomisz update-grub, ale także podczas instalowania zaktualizowanego pakietu jądra, który zwykle ma hak poinstalacyjny, który informuje menedżera pakietów o aktualizacji grub.cfg), wszystkie są wykonywane w kolejności alfabetycznej. Wszystkie dane wyjściowe są łączone i kończą się w pliku /boot/grub/grub.cfg, dzięki zgrabnym nagłówkom sekcji, które pokazują, która część pochodzi z którego /etc/grub.d/pliku.

Ten jeden konkretny plik 40_customumożliwia łatwe dodawanie wpisów / linii grub.cfg, po prostu wpisując / wklejając je do tego pliku. Inne skrypty w tym samym katalogu wykonują bardziej złożone zadania, takie jak wyszukiwanie jąder lub systemów operacyjnych innych niż Linux i tworzenie dla nich pozycji menu.

Aby umożliwić grub-mkconfigtraktowanie wszystkich tych plików w ten sam sposób (wykonaj i pobierz dane wyjściowe), 40_customjest skrypt i używa tego exec tail -n +3 $0mechanizmu do wyświetlania zawartości (pomniejszonej o „nagłówek”). Gdyby nie był to plik wykonywalny, update-grubpotrzebowałby specjalnego, zakodowanego na stałe wyjątku, aby wziąć dosłowną zawartość tekstową tego pliku zamiast wykonywać go tak jak wszystkie inne. Ale co jeśli ty (lub twórcy innej dystrybucji linuksa) chcesz nadać temu plikowi inną nazwę? A co jeśli nie wiedziałeś o wyjątku i utworzyłeś skrypt powłoki o nazwie 40_custom?

Możesz przeczytać więcej na temat grub-mkconfigi /etc/grub.d/*w Podręczniku GNU GRUB (chociaż mówi głównie o opcjach, które możesz ustawić /etc/default/grub), i powinien być również plik, /etc/grub.d/READMEktóry stwierdza, że ​​pliki te są wykonywane do postaci grub.cfg.

TL; DR : sztuczka polega na uproszczeniu dodawania nowych wpisów do pliku

Cały punkt jest opisany na jednej ze stron Wiki Ubuntu na temat grub :

3. Tylko pliki wykonywalne generują dane wyjściowe do pliku grub.cfg podczas wykonywania aktualizacji-grub.

Dane wyjściowe skryptów /etc/grub.d/stają się zawartością grub.cfgpliku.

Co teraz robi exec? Może albo ponownie przesłać dane wyjściowe dla całego skryptu, albo jeśli podano polecenie - wspomniane polecenie wyprzedza i zastępuje proces skryptu. To, co kiedyś było skryptem powłoki z PID 1234, teraz jest tailpoleceniem z PID 1234.

Teraz już wiesz, że tail -n +3 $0drukuje wszystko po 3 linii w samym skrypcie. Dlaczego więc musimy to zrobić? Gdyby grub dbał tylko o wynik, równie dobrze moglibyśmy to zrobić

cat <<EOF
    menuentry {
    ...
    }
EOF

W rzeczywistości znajdziesz cat <<EOFprzykład w dokumentacji Fedory , choć w innym celu. Chodzi o to w komentarzach - łatwość użytkowania dla użytkowników:

# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.

Dzięki exectrickowi nie musisz wiedzieć, co robi cat <<EOF(spoiler, to się nazywa tutaj-doc ), ani nie musisz pamiętać, aby dodać EOFw ostatnim wierszu. Po prostu dodaj menu do pliku i gotowe. Dodatkowo, jeśli piszesz skrypt, dodając menu, możesz po prostu dołączyć >>do tego pliku za pomocą powłoki.

Zobacz też:

• Jaką logikę ma polecenie „exec tail -n +3 $ 0” z konfiguracji grub2?