Poniższego można użyć jako obejścia dla wersji macOS 10.15.1 polecenia apropos, w której wyrzuca ona skargi w postaci makewhatis: / usr / lib / lib… .dylib: To nie jest katalog.

Najpierw utwórz skrypt obejścia:

  $ mkdir -p ~ / workarounds
$ sed -e 66s @ / usr / lib @@ / usr / bin / apropos > ~ / workarounds / apropos.macos_10.15.1
$ diff / usr / bin / apropos ~ / workarounds / apropos.macos_10.15.1
66c66
< for d in / var / cache / man $ manpath / usr / lib
---
> for d in / var / cache / man $ manpath
$ chmod + x ~ / workarounds / apropos.macos_10.15.1
 

Następnie dodaj alias do powłoki, aby nakazać jej użycie skryptu obejścia, dopóki nie stanie się dostępna nowsza wersja skryptu kanonicznego.

W przypadku Zsh możesz użyć następującego polecenia:

  $ / bin / cat <<END >> ~ / .zshrc
# Obejście dla zepsutego polecenia apropos.
alias apropos = ~ / workarounds / apropos.macos_10.15.1
KONIEC
 

W przypadku innych powłok, takich jak ksh lub bash, użyj odpowiednio ~ / .profile lub ~ / .bash_profile.

o służy obejście?

Apropos żądania (i żądania man -k) są obsługiwane przez skrypt / usr / bin / apropos . Ten skrypt wyszukuje pliki bazy danych „whatis” we wszystkich katalogach ścieżki man (patrz man —path ), a także / var / cache / man i / usr / lib . Sprawdzanie / var / cache / man / whatis i / usr / lib / whatis wydaje się być obecne z powodów historycznych, jednak te pliki nie są aktywnie generowane w Mojave lub Catalina. Przez lata wiele różnych osób miało swój wkład w różne smaki Uniksa i wielu z nich miało różne pomysły na to, gdzie umieszczać różne typy plików. W pewnym momencie ktoś zdecydował, że / usr / lib byłoby dobrym miejscem na umieszczenie pliku whatis, a w innym momencie ktoś inny pomyślał, że / var / cache / man będzie dobrym miejscem miejsce. Inni myśleli, że odpowiednim miejscem będą odpowiednie katalogi stron podręcznika. Różne rozwiązania, które wydawały się wówczas odpowiednie. Skrypt apropos tradycyjnie sprawdzał te lokalizacje pod kątem obecności pliku whatis.

Wraz z przejściem na tworzenie katalogów systemowych na Catalinie jako tylko do odczytu (dobry posunięcie), pliki bazy danych whatis nie mogą być zapisywane w katalogach takich jak / usr / share / man . Apple może sobie z tym poradzić na różne sposoby, ale w tym wydaniu ktoś zdecydował się zmienić skrypt apropos, zmuszając go do generowania wyników w locie, wywołując /usr/libexec/makewhatis.local dla dowolnej strony podręcznika katalog, który nie zawiera pliku whatis.

Ten nowy kod apropos działa dobrze dla rzeczywistych katalogów stron podręcznika i dla / var / cache / man (ponieważ nie istnieje), ale nie działa w przypadku / usr / lib . Opisane powyżej obejście po prostu usuwa / usr / lib z listy przeszukiwanych katalogów.

Na koniec ustaw sobie przypomnienie na miesiąc lub dwa, aby sprawdzić, czy firma Apple naprawiła odpowiedni skrypt.Jeśli tak, usuń obejścia, usuwając alias i skrypt obejścia.

Właśnie natknąłem się na to i przeszukałem tutaj w Google ...

Wygląda na to, że „whatis” albo grepuje przez wygenerowane pliki whatis, albo generuje je w locie na standardowe wyjście. To, co widzimy, to wynik działania „makewhatis” uruchamianego w / usr / lib.

Te same błędy wystąpią z adresu:

  / usr / libexec / makewhatis -o / dev / fd / 1 / usr / lib
 

/ usr / lib nie znajduje się w manpath (wyjście "man --path") - jest dodawane jawnie przez "whatis", chociaż z jakiego powodu nie mam pojęcia. Nie ma tam stron podręcznika systemowego, a makewhatis wyraźnie oczekuje, że wszystko w folderze man będzie podkatalogiem.

Gdybyśmy mogli edytować skrypt „whatis”, moglibyśmy to naprawić. Ale nie możemy, ponieważ / usr / bin jest tylko do odczytu.

Gdybyśmy mogli wygenerować pusty katalog / usr / lib / whatis, skargi zostałyby zatrzymane. Ale nie możemy, ponieważ / usr / lib jest tylko do odczytu.

Możliwe jest naprawienie /usr/libexec/makewhatis.local, aby zatrzymać ten nonsens, ale jest to tylko do odczytu.

Muszę przeprowadzić pewne badania, aby sprawdzić, czy istnieje sposób na uzyskanie przez chwilę wolumenu systemu operacyjnego do odczytu i zapisu.

Z podobnej notatki: nawet jeśli udało nam się uruchomić "makewhatis", nie wygeneruje / usr / lib / whatis, ponieważ / usr / lib nie znajduje się w ścieżce man ... więc wygrał ' napraw to. Utworzenie pustego / usr / lib / whatis jest prawdopodobnie najłatwiejszą i najbezpieczniejszą opcją, jeśli możemy dowiedzieć się, jak to zrobić.

Spróbuj tego ():

1. sudo mkdir / System / Volumes / Data / usr / share / man
2. sudo / usr / libexec / makewhatis -o / System / Volumes / Data / usr / share / man / whatis

3.   user @ host ~% cd / System / Volumes / Data / usr / share / man /
   użytkownik @ host man% lsl
   łącznie 384
   drwxr-xr-x 3 korzeń korzeniowy - 96 3 listopada 01:33.
   drwxr-xr-x 4 korzeń korzeniowy sunlnk 128 3 listopada 01:32 ..
   -rw-r - r-- 1 korzeń korzeniowy - 160236 3 listopada 01:33 whatis
    

   lsl to alias dla ls -laOe @ w moim systemie

Ciekawostki:

• Nie wiem, gdzie jest ten plik (poza tym, że plik tam jest) - pliku nie można znaleźć za pomocą polecenia sudo find / -name "whatis" w systemie plików
• Plik przetrwa ponowne uruchomienie
• Nie mam pojęcia, czy ten plik jest w ogóle używany przez whatis / apropos / fish | bash | zsh uzupełnianie powłoki (i rozwiązuje twoje problemy)

Rw oczekiwaniu na rozwiązanie, które wygenerowałoby brakujące pliki whatis:

Rozwiązanie pozwalające na aktualizację bazy danych „whatis” w / usr / share / man wymaga poprawki ze strony Apple. Muszą albo dodać / usr / share / man do swojej listy firmowych linków (podobnie jak w implementacji dla / usr / share / snmp ) lub dodać kopię statyczną pliku whatis na wolumin systemowy.

Łącza firmowe to nowa funkcja APFS; zaprojektowany do obsługi łączenia woluminów do odczytu i zapisu z woluminami systemowymi tylko do odczytu. Począwszy od wydania Cataliny, podstawowe pliki systemu operacyjnego są przechowywane w woluminie tylko do odczytu, który jest następnie łączony z woluminem danych do odczytu i zapisu za pomocą trwałych łączy. W wersji macOS 10.15.1 / usr / share / man jest obecny tylko na woluminie systemowym tylko do odczytu. Możesz dodać wpis dla / usr / share / man do wolumenu danych, tworząc katalog / System / Volumes / Data / usr / share / man , jak pokazano na klanomath, ale nie zostanie zmapowany do katalogu systemowego (/ usr / share / man), dopóki nie zostanie utworzony odpowiedni link firmowy.

Listę aktualnych linków firmowych można znaleźć w / usr / share / firmlinks . Dokumentacja, którą udało mi się do tej pory wykopać, nie jest jasna co do tego, czy firmlinks jest plikiem referencyjnym, czy plikiem konfiguracyjnym, ale wygląda jak plik konfiguracyjny, który jest odczytywany i używany jako część procedur rozruchowych. Zakładając, że jest to plik konfiguracyjny, teoretycznie można by rozwiązać problem, dodając do pliku wpis dotyczący / usr / share / man .

Niestety, ponieważ / usr / share / firmlinks znajduje się w woluminie systemowym tylko do odczytu, nie możesz go edytować jako użytkownik ani nawet jako superużytkownik.Nawet w trybie jednego użytkownika, montowanie systemowej grupy woluminów w trybie do odczytu i zapisu jest niemożliwe (np .: / sbin / mount -uw / nie działa).Może być możliwe zamontowanie woluminu systemowego jako dysku pomocniczego w systemie dodatkowym, a następnie dokonanie edycji;ale to więcej czasu na eksperymentowanie, niż byłem gotów poświęcić.

Krótko mówiąc, ulepszone zabezpieczenia Cataliny uniemożliwiają aktualizację tego katalogu, dopóki Apple nie naprawi problemu.

Powyższe uwagi dotyczą Cataliny (macOS v 10.15.1).Ponieważ jest to prosta poprawka, spodziewam się, że problem zostanie wkrótce poprawiony.

Właśnie dzisiaj znalazłem ten problem i utworzyłem następujące aliasy w ~ / .zshrc, aby wyczyścić dane wyjściowe polecenia:

  alias apropos = "apropos 2> / dev / null"
alias whatis = "whatis 2> / dev / null"
 

Aliasy usuwają błędy z danych wyjściowych za pomocą przekierowania. Powłoka ma dwa deskryptory plików wyjściowych.Standardowym wyjściem jest deskryptor pliku 1, a standardowym wyjściem błędów jest deskryptor pliku 2. Błędy generowane przez skrypt makewhatis.local są wysyłane na standardowe wyjście błędów.

Przekierowanie standardowego wyjścia błędów odbywa się za pomocą deskryptora pliku stderr „2”, operatora przekierowania wyjścia „>” i pliku docelowego „/ dev / null”.Plik / dev / null jest specjalnym obiektem systemu plików, który odrzuca wszystko, co w nim zapisane.Po przekierowaniu błędów wyświetlane są tylko pożądane wyniki.

Catalina złamała polecenie człowieka

Aby zignorować komunikaty o błędach w / bin / bash , utwórz alias dla man:

  alias man = '/ usr / bin / man 2> / dev / null'
 

Wydaje mi się, że zostało to naprawione w MacOs 10.15.4.Dziękuję @minopret za wskazanie tego w komentarzach do pierwotnego pytania.Uruchamianie niezmodyfikowanych poleceń whatis lub apropos nie powoduje błędów.