Come mantenere agili i dotfile?

A causa del lavoro ho recentemente iniziato a utilizzare OS X e l'ho configurato utilizzando homebrew per ottenere un'esperienza simile a quella di Linux.

Tuttavia, ci sono alcune differenze nelle loro impostazioni. Alcuni devono solo essere installati su un sistema. Dato che i miei dotfile vivono in un repository git, mi chiedevo che tipo di switch avrei potuto impostare, in modo che alcune configurazioni vengano lette solo per il sistema Linux e altre per OS X.

Per quanto riguarda i dotfile, mi riferisco, tra l'altro, a .bash_profileso .bash_alias.

— k0pernikus
fonte

L'ho fatto con i rami git. Ne ho uno per FreeBSD, Gentoo e Ubuntu. Ma questo non è l'ideale.

— Raphael Ahrens,

@RaphaelAhrens Voglio evitare una soluzione basata sul ramo in quanto incline a divergere.

— k0pernikus,

Sì, puoi renderlo un po 'più semplice quando metti le cose specifiche del sistema in file speciali. Ma come ho detto non è l'ideale.

— Raphael Ahrens,

stackoverflow.com/questions/394230/… Puoi verificare Darwin su OS X.

— Raphael Ahrens,

Fondamentalmente il mio approccio si riduce a if (exists rcfile.local); source rcfile.local; endif, tradotto nel file rc appropriato. Il file rc principale che cerco di mantenere agnostico sul sistema, mentre la .localversione ha impostazioni specifiche del sistema. Se si desidera tutto in un singolo repository, è possibile disporre delle directory di sistema e collegare simbolicamente rcfile.local a quello nella directory corretta.

— jw013,

Risposte:

Mantenere i dotfile il più portatili possibile ed evitare le impostazioni dipendenti dal sistema operativo o gli switch che richiedono una versione particolare di uno strumento, ad esempio evitare la sintassi GNU se non si utilizza il software GNU su tutti i sistemi.

Probabilmente ti imbatterai in situazioni in cui è preferibile utilizzare impostazioni specifiche del sistema. In tal caso, utilizzare un'istruzione switch con le singole impostazioni:

case $(uname) in
  'Linux')   LS_OPTIONS='--color=auto --group-directories-first' ;;
  'FreeBSD') LS_OPTIONS='-Gh -D "%F %H:%M"' ;;
  'Darwin')  LS_OPTIONS='-h' ;;
esac

Nel caso in cui i file di configurazione di applicazioni arbitrarie richiedano opzioni diverse, è possibile verificare se l'applicazione fornisce switch di compatibilità o altri meccanismi. Ad vimesempio, è possibile controllare la versione e il livello di patch per supportare funzionalità versioni precedenti o versioni compilate con un set di funzionalità diverso, non sono disponibili. Esempio di frammento di .vimrc:

if v:version >= 703
  if has("patch769")
    set matchpairs+=“:”
  endif
endif

— Marco
fonte

uname -sè come uname. uname sta per nome Unix.

— Stéphane Chazelas,

@StephaneChazelas Capita di essere o è garantito su tutti i sistemi e posso sempre eliminare -s?

— Marco,

sì, unameda solo è stato il modo canonico per farlo per decenni ed è specificato da POSIX. L'originale uname(in Unix PWB) non ha preso alcuna opzione.

— Stéphane Chazelas,

@StephaneChazelas Grazie per il chiarimento, ho rimosso il -sda questa risposta e lo terrò a mente per i miei futuri script.

— Marco,

È un dettaglio relativamente minore e non toglie nulla al punto illustrato dal tuo esempio, ma quelle citazioni nel vimrc setdovrebbero davvero essere U + 201C e U + 201D anziché U + 0022?

— un CVn del

Se ti preoccupi solo di file che vengono effettivamente eseguiti, come .bash_profiles e amici, potresti essere in grado di cavartela usando, ad esempio, unameper differenziare in base al sistema su cui viene eseguito il codice.

Ad esempio , completamente non testato e con l'avvertenza che non ho un OS X su cui provare le cose, se attualmente hai su Linux:

alias ll='ls -lFA'

e su Mac OS X:

alias ll='ls -lFAx'

(dove -xfa sì che OS X lsfaccia qualcosa che GNU fa di default), quindi possono essere combinati in qualcosa del genere:

OS="$(uname -s)"
if test "$OS" = "Darwin"; then
    alias ll='ls -lFAx'
    # ...other OS X-specific things go here...
else if test "$OS" = "Linux"; then
    alias ll='ls -lFA'
    # ...other Linux-specific things go here...
fi
# ...generic things go here...

L'unico requisito quindi è che uname -sfunzioni per lo più allo stesso modo (dovrebbe, poiché entrambi i sistemi sono ragionevolmente POSIX-y e uname -s è richiesto da POSIX (grazie Marco per averlo sottolineato )), e che la sintassi per il branch script della shell basato su un confronto di stringhe è lo stesso. Probabilmente puoi testare anche in base ad altri criteri; ad esempio, potresti cercare / etc / lsb_release, controllare se / proc / sys / kernel / ostype contiene "Linux" o qualsiasi altro test tu possa fare.

— un CVn
fonte

@RaphaelAhrens È Darwin, ho appena controllato.

— k0pernikus,

@RaphaelAhrens Come ho scritto, non ho un OS X su cui provare le cose, quindi ho fatto una supposizione sfrenata per mostrare l'idea piuttosto che passare molto tempo su un dettaglio relativamente insignificante che l'OP può scoprire banalmente.

— un CVn

Wikipedia in soccorso en.wikipedia.org/wiki/Uname se qualcun altro vuole lì bash per Windows o altre cose.

— Raphael Ahrens,

L'opzione uname -onon è POSIX e non funziona su molti sistemi, ad esempio Solaris. -sè obbligatorio su POSIX e il modo più compatibile. IEEE Std 1003.1

— Marco

OSTYPEnon è disponibile in una shell POSIX. Per esempio, fallirà su un'installazione di FreeBSD predefinita e può essere usata solo in .bashrco .zshrc. Non funziona in modo affidabile in .profile, .aliasecc Dal momento che stiamo parlando di compatibiliy qui, mi piacerebbe consiglio di andare il modo sicuro, invece di basarsi su caratteristiche particolari della Shell, che non sono garantiti per essere disponibili su tutti i sistemi.

— Marco