Partager les alias et le paramètre PATH entre zsh et bash

24

Le shell que j'utilise normalement est zsh. J'ai plusieurs alias pour activer la couleur dans certains programmes tels que lset grep. J'ai également défini mon chemin personnalisé afin que je puisse exécuter des programmes dans un endroit non standard (comme dans ~/bin/).

Je ne changerai pas le shell de root en zsh, mais je voudrais partager ces paramètres afin que root puisse également l'avoir. Je découvre que ce zshn'est pas du sourcing /etc/profile. Je peux me l'approvisionner /etc/zsh/zprofile, mais j'aimerais une autre manière plus "appropriée".

— phunehehe
source

16

Je créerais un fichier /etc/commonprofileet je le sources dans /etc/profileet /etc/zsh/zprofile. Cela vous donne l'occasion de partager les paramètres communs et toujours utiliser bashrespectivement des zshparamètres spécifiques et syntaxe /etc/profilerespectivement zprofile.

— fschmitt
source

entre autres bonnes réponses je pense que celle-ci me convient le mieux, relativement simple et "propre"

— phunehehe

qu'entendez-vous par «source»?

— Hlung

@Hlung Pour charger l'explicilité du profil de shell, voici le 'source /path/to/.shell_profile'. Voir la page de manuel sur 'source'.

— Itachi

17

Zsh a un mode de compatibilité sh qui lui permettra d'exécuter du code POSIX sh et quelques extensions bash. Tant que vous n'utilisez pas les fonctionnalités bash que zsh n'a pas (avec la même syntaxe), vous pouvez avoir le même fichier provenant des deux shells. Utilisez le emulateintégré pour mettre zsh en mode de compatibilité; avec l' -Loption, l'émulation est locale à la fonction englobante (pas au script source englobant).

source_sh () {
  emulate -LR sh
  . "$@"
}

Pour des choses comme les variables d'environnement, vous pouvez utiliser source_sh /etc/profilein /etc/zprofileet source_sh ~/.profilein ~/.zprofile, car les fichiers de profil ne sont pas susceptibles d'utiliser des fonctionnalités spécifiques à bash.

Pour des choses comme les alias et les définitions de fonctions, étant donné que les fichiers shell rc sont susceptibles de contenir beaucoup de choses qui ne peuvent pas être partagées (invite, raccourcis clavier, paramètres de complétion,…), utilisez un fichier comme ~/.sh_aliasescelui-ci qui provient de ~/.bashrcet source_sh'd dans ~/.zshrc.

— Gilles 'SO- arrête d'être méchant'
source

2

Il devrait y avoir un moyen de dire "automatiquement voter toutes les réponses de Gilles". Cela me ferait gagner du temps. Non vraiment, vos réponses sont géniales. Toujours précis, bien écrit et complet.

— fschmitt

@fschmitt: Je suis d'accord. Et vous pouvez voir que ce n'est même pas édité! Cet indice fourni ici est vraiment bon.

— Quelqu'un vous utilise toujours MS-DOS

4

Et un simple lien symbolique?

ln -s /etc/profile /etc/zsh/zprofile

Vous pouvez également ajouter quelque chose comme ceci si vous avez besoin d'une initialisation conditionnelle:

#Determine our shell without using $SHELL, which may lie
shell="sh"
if test -f /proc/mounts; then
   case $(/bin/ls -l /proc/$$/exe) in
        *bash) shell=bash ;;
        *dash) shell=dash ;;
        *ash)  shell=ash ;;
        *ksh)  shell=ksh ;;
        *zsh)  shell=zsh ;;
    esac
fi

— écho
source

Hmm mais je ne pense pas que ce sera plus propre que de l'approvisionner. Existe-t-il un fichier que zsh et bash liront?

— phunehehe

qu'est-ce qui vous fait penser que l'approvisionnement ou la création d'un lien symbolique n'est pas une solution «propre»?

— echox

Je voulais juste dire si nécessaire, je voudrais source le fichier plutôt que de gérer le lien symbolique. Je ne veux pas créer beaucoup de dépendances entre les fichiers.

— phunehehe

1

Une alternative plus portable à l' /bin/ls -l /proc/$$/exeest ps -o comm= -p $$. Ce n'est pas entièrement fiable car certains shells se comportent différemment selon la façon dont ils ont été invoqués; dans la pratique de tester simplement $0en .profileest d'être probablement une meilleure indication. Mais la plupart des coquilles qui offrent des fonctionnalités utiles (bash, ksh, zsh) peuvent être simplement reconnus (et leur version identifiée, ce qui est un plus) en testant certaines variables: $BASH, $BASH_VERSION, $BASH_VERSINFO; $KSH_VERSION, ${.sh.version}; $ZSH_VERSION.

— Gilles 'SO- arrête d'être méchant'

echox, votre déclaration de cas ne détecte pas correctement zsh4 #Déterminez notre shell sans utiliser $ SHELL, qui peut se trouver shell = "sh" si test -f / proc / mounts; puis casse $ (/ bin / ls -l / proc / $$ / exe) dans bash) shell = bash ;; * tiret) shell = tiret ;; * frêne) coque = frêne ;; * ksh) shell = ksh ;; * zsh ) shell = zsh ;; #matches zsh4 esac fi

— Bryan Hunt

0

En ce qui concerne les variables, j'ai l'impression qu'il vous manque des modules et des fichiers de modules [1]. Une fois que vous commencez à le faire, il sera facile de créer des profils communs pour différents shells (y compris bash & zsh), python, perl et encore plus d'environnements, le tout à partir d'un fichier de module unique.

Il est également possible de définir des alias de la même manière; cependant, vous constaterez rapidement que les alias ne sont pas très bien hérités entre les shells successifs et peuvent nécessiter des solutions de contournement.

[1] http://en.wikipedia.org/wiki/Environment_Modules_(software)

— fgeorgatos
source