Homebrew lägger OpenVPN-binären i sbin, inte i din PATH

Installationen slutar, brew säger att openvpn finns där, och skalet svarar command not found. Binären finns, den ligger bara i en katalog som skalet aldrig fick veta om. Homebrew länkar daemon-liknande binärer till prefixets sbin-katalog, och en standard-PATH i macOS innehåller vanligtvis bin-katalogen och inte sbin-katalogen. Inget är trasigt, och ingen ominstallation kommer att ändra det.

Fyra kontroller bekräftar mekanismen innan du redigerar någon skal-fil.

Vad formeln faktiskt installerar

Formeln openvpn bygger en kommandoradsdaemon, så dess körbara fil hamnar under sbin i stället för bin. Homebrew länkar sedan binären till prefixets sbin-katalog, och därför fungerar "$(brew --prefix)/sbin/openvpn" --version medan ett bart anrop inte gör det. Den versionsnumrerade Cellar-katalogen innehåller också en kopia, och att sätta den sökvägen i en startfil är sättet en maskin förblir låst till ett gammalt bygge efter en uppgradering.

Prefixets symboliska länk är den stabila sökvägen. Cellar-sökvägen är en implementeringsdetalj med ett versionsnummer i sig.

Fråga Homebrew, inte filsystemet

Börja med pakethanteraren, eftersom den vet vilken installation som äger formeln: command -v brew, brew --prefix, brew list --versions openvpn, brew --prefix openvpn. Om den sista skriver ut en sökväg finns formeln, och frågan gäller enbart uppslagningen. Om den inte skriver ut något letar skalet på fel ställe efter ett paket som aldrig installerades, och det är ett annat problem med en annan lösning.

Två Homebrew-installationer på en maskin är där detta spelar störst roll: den brew som svarar är inte nödvändigtvis den brew som installerade.

Varför skalet inte kan se sbin

Ett inloggningsskal bygger PATH från systemstandarderna plus allt dina startfiler lägger till. Homebrew bin läggs vanligen till och Homebrew sbin vanligen inte, så varje kommando fungerar utom daemonerna. command -v openvpn som inte returnerar något medan sökvägen med prefix returnerar en version är hela diagnosen i två kommandon. Bekräfta att katalogen verkligen innehåller länken med ls -l "$(brew --prefix)/sbin/openvpn".

En saknad länk är ett annat fel än en saknad PATH-post, och bara en av dem åtgärdas genom att redigera en skal-fil.

Åtgärda sökvägen en gång, på ett ställe

För ett snabbt test i det aktuella skalet sätter eval "$(brew shellenv)" installationsvariablerna och placerar båda katalogerna först. För en varaktig ordning lägger du shellenv-raden i den enda startfil som ditt skal läser för det inloggningsläge du använder, i stället för att sprida exporter över bash- och zsh-filer.

Öppna sedan ett nytt terminalfönster och upprepa versionsfrågan, eftersom ett cachelagrat skal fortsätter rapportera den gamla PATH.

Håll upptäckten åtskild från tjänsten

Att hitta en binär är inte samma sak som att köra en VPN-tjänst. Att starta openvpn automatiskt lägger till krav på profil, inloggningsuppgifter, rättigheter och livscykel som paketupptäckten aldrig har rört. Tunnelblick har också sin egen motor, så versionen du just skrev ut har kanske ingenting att göra med den version som programmet använder.

Notera vilken körbar fil som producerade versionsutskriften. Den enda raden sparar en timme nästa gång två versioner inte stämmer överens.