Comment rendre facilement une commande d'alias permanente?

Question

Je cherche partout et presque tout le monde a suggéré d'ouvrir ~/.bashrc ou ~/.bash_aliases, puis de mettre la commande alias à cet endroit, j'ai créé un nom de fonction palias en tant que fonction d'alias permanente et de le mettre dans ~/.bashrc:

function palias(){ echo "alias $1='$2'" >> /home/User/.bashrc;}

Alors maintenant, si je veux aliaser définitivement une commande, je viens de:

palias update "Sudo apt-get update"

Je me demande s’il existe une commande intégrée telle que cette fonction ou quelque chose de ce genre à installer à partir de référentiels?

Eliah Kagan · Accepted Answer

Il n'y a pas de bash intégré pour ajouter des alias permanents. Ces alias sont créés en les ajoutant à un fichier de configuration provenant de shells interactifs, comme vous l'avez fait avec _.bashrc_.

Mais vous pourriez envisager de modifier votre implémentation palias() en lui faisant placer les alias dans un fichier séparé. Je pense que cela peut être considéré comme une amélioration, pour six raisons:

Le fichier principalement édité automatiquement peut être séparé du fichier principalement édité manuellement. Si vous avez besoin de voir ce qui s'est passé - par curiosité ou pour enquêter sur un problème - cette séparation peut être utile. (Ou si la fonction est appelée plusieurs fois par inadvertance, créant ainsi un grand nombre de lignes inutiles, les dégâts seront un peu plus contenus.)
En plaçant les définitions d'alias individuelles générées automatiquement ailleurs que _.bashrc_, vous créez un système qui "fonctionne en arrière-plan", ce que les gens recherchent souvent lorsqu'ils recherchent une commande intégrée dédiée pour effectuer une tâche.
_.bashrc_ est déjà généralement assez compliqué. Il sera plus facile à lire et à modifier à des fins non liées si plusieurs alias ajoutés automatiquement par l'utilisateur ne sont pas renseignés.
Les simples implémentations de palias() - y compris ce que vous avez écrit et ce que je vais vous recommander - créeront des lignes incorrectes si le fichier auquel elles ajoutent n'est pas déjà terminé (ou vide). Normalement, les éditeurs de texte le font pour vous, mais il est possible de terminer accidentellement un fichier texte sans nouvelle ligne. Dans ce cas, palias() créera une ligne regroupée qui peut être ou ne pas être correcte et qui, dans tous les cas, serait très difficile à lire. En plaçant des alias dans un fichier séparé que vous modifiez rarement, ou du moins moins souvent, manuellement, vous réduisez le risque.
Si vous développez votre implémentation palias() pour lire le contenu existant de son fichier cible, par exemple, pour donner des avertissements utiles, il peut être beaucoup plus facile de le faire si on peut supposer qu'il est entièrement constitué de définitions d'alias. (Ou, pour une analyse plus sophistiquée: entièrement de définitions de pseudonymes et de lignes supposées fausses.)
Il est déjà largement suggéré (bien que ce ne soit certes pas un avertissement puissant) de placer les nouveaux alias dans un fichier séparé: _.bash_aliases_

Voir Comment créer un alias Bash permanent? pour plus d'informations sur les emplacements où placer des alias.

Les fichiers par défaut _.bashrc_ sous Ubuntu contiennent le code suivant:

_# Alias definitions. # You may want to put all your additions into a separate file like # ~/.bash_aliases, instead of adding them here directly. # See /usr/share/doc/bash-doc/examples in the bash-doc package. if [ -f ~/.bash_aliases ]; then . ~/.bash_aliases fi _

Ainsi, si vous créez _.bash_aliases_, il sera utilisé. La commande permettant de définir la fonction palias() peut alors être:

_palias() { echo "alias $1='$2'" >> ~/.bash_aliases; } _

Cette commande devrait quand même aller dans _.bashrc_, mais les alias créés seront placés dans _.bash_aliases_.

Des implémentations plus sophistiquées sont possibles. Vous pourriez:

Exécutez la définition et ajoutez-la pour qu'elle soit immédiatement utilisable. Ceci est suggéré dans réponse d'osirisgothra . J'utiliserais:
```
_palias() { echo "alias $1='$2'" >> ~/.bash_aliases; alias "$1=$2"; } _
```
Vérifiez que _.bash_aliases_ est inexistant, vide ou terminé par une nouvelle ligne. S'il est non vide, mais pas par une nouvelle ligne, ajoutez une nouvelle ligne avant la définition d'alias.
```
_palias() { local target=~/.bash_aliases [[ -f "$target" && -n $(tail -c1 "$target") ]] && echo >> "$target" echo "alias $1='$2'" >> "$target" } _
```
^{Voir réponse de Gilles à Ajouter des nouvelles lignes manquantes dans plusieurs fichiers pour plus de détails sur la détection des nouvelles lignes manquantes avec tail.}
Vérifiez et avertissez lorsque vous définissez un alias déjà défini dans _.bash_aliases_.

Ploutox a suggéré cette idée. Mais je ne recommande pas d'utiliser _grep $1 ~/.bash_aliases_ ou similaire, car il produira de fréquents faux positifs, anytime _$1_ correspond à une partie de la définition d'un autre alias, et occasionnellement. faux négatifs. La question est encore compliquée par la façon dont certains alias bash valides, pris comme expressions rationnelles, correspondent plus souvent à eux-mêmes --_+_ et _._ sont effectivement utilisés dans les noms de commande et de pseudonymes - et quelques-uns ne le font pas. correspondre même eux-mêmes.
_{_grep "alias $1="_ est préférable, mais n'atténue le problème que partiellement. Un _^_ dominant dans le modèle correspondrait plutôt bien que le _alias name_ d'une définition, mais ne résoudrait pas le problème des méta-caractères d'expression rationnelle dans _$1_, alors que _grep -F_ résoudrait tous les métacaractères de leur signification particulière mais qui empêchent ainsi l'utilisation de _^_.}

greping _.bashrc_ de cette manière est encore pire que _.bash_aliases_, car il existe une variété de texte pratiquement illimitée pouvant faire partie de ce fichier, généralement en dehors de toute définition de pseudonyme.

Si vous souhaitez vérifier les alias définis dans le shell actuel, qu'ils soient écrits ou non en _.bash_aliases_ (ou ailleurs), vous pouvez utiliser _alias "$1"_ (ou exécuter alias avec pas d’argumentation et ne correspond pas, soigneusement, à sa sortie). Le crédit va à muru pour cette idée. Cela a le désavantage que si vous définissez un alias avec alias pour le tester puis le rendre permanent avec palias, vous ' J'aurai un avertissement même si ce n'était pas encore permanent et que tout va bien.

Pour comparer les nouveaux alias permanents au contenu de _.bash_aliases_, vous pouvez procéder de la manière suivante:
```
_palias() { local target=~/.bash_aliases if grep -Pqs '^[ 	]*alias[ 	]+\Q'"$1"'\E\=' "$target"; then printf "%s: %s: warning: defining \`%s' again in %s
" \ "$0" "$FUNCNAME" "$1" "$target" >&2 fi echo "alias $1='$2'" >> "$target" } _
```
Cela semble bien fonctionner, même si je soupçonne qu'il existe des moyens plus élégants. (On peut soutenir que _[ ]*_ devrait être supprimé, si vous prenez des espaces avant les caractères précédant alias pour suggérer que cela fait partie d'une définition d'alias multiligne.) Il fonctionnera mal si _\E_ apparaît dans _$1_, mais les métacaractères Shell et les guillemets tels que _\_ ne sont pas valides dans les noms d'alias , vous n'aurez donc pas besoin de l'indiquer en entrée.
_{Dans l'idéal, en cas de mauvaise entrée, toute fonction que vous appelez, que vous appelez, n'effectue aucune opération, sauf l'affichage d'un message d'erreur utile. Mais, de par la nature de palias(), du moins si vous n'êtes pas prêt à rendre sa définition beaucoup plus sophistiquée (voir ci-dessous), le fardeau de la saisie raisonnable incombe déjà principalement à l'utilisateur. Vous pouvez écrire des erreurs de syntaxe de non-alias et de définition d'alias sur _.bash_aliases_ avec cette fonction. Bien que ce soit probablement acceptable compte tenu de la façon dont vous utiliserez palias(), l'étouffement de _\E_ est mineur. Comparaison.}

Plus sérieusement, _alias name1='def1' name2='def2' ..._ est une syntaxe parfaite pour la commande alias, mais je n'ai pas essayé d'analyser les définitions d'alias données en tant qu'arguments ultérieurs de alias dans _.bash_aliases_, Je pense que déterminer correctement où se trouve le premier blanc non cité apparaît non trivial.

Par conséquent, si vous utilisez la mise en oeuvre palias() ci-dessus et définissez parfois aussi manuellement les alias dans _.bash_aliases_ (ou le fichier que vous utilisez en tant que _$target_), vous devez définir un seul alias par _alias ..._ line si vous voulez avoir un comportement d'avertissement fiable.
_{Il échouera également à reconnaître les définitions d'alias à droite d'un _;_ ou d'autres connecteurs, par exemple pour chaîner des commandes alias distinctes sur la même ligne, mais il semble peu probable que vous souhaitiez le faire dans _.bash_aliases_.}
Analyser _$1_ pour s’assurer qu’il s’agit d’un nom valide pour un alias.
Analysez _$2_ pour essayer de déterminer s’il s’agit d’un corps plausible pour un alias, et si ce n’est pas le cas, avertissez-le, échouez ou, le cas échéant, citez-le correctement. Par exemple, que se passe-t-il si un caractère _'_ apparaît dans _$2_?
Faites une version plus simple de cela à la place, juste en recherchant et en adressant _'_ in _$2_.

Mais vous ne voudrez probablement pas vous embêter avec ça . Vous savez comment fonctionne votre fonction, ses limites et comment l'utiliser correctement. Je vois quatre options à la fois raisonnablement bonnes et assez simples:

Continuez simplement à utiliser ce que vous avez maintenant.
Utilisez une implémentation comme ci-dessus, en plaçant les alias dans _.bash_aliases_ au lieu de _.bashrc_.
Créez un troisième fichier pour les alias ajoutés automatiquement et sourcez ce fichier séparément (dans _.bashrc_ ou _.bash_alises_.
N'utilisez pas du tout une fonction palias() et ajoutez simplement des alias en éditant _.bash_aliases_ ou _.bashrc_.

osirisgothra · Answer

Je suggère (bien sûr que vous ne l'ayez pas et =) de mettre un eval "$_" après la commande echo, de sorte que l'alias soit ajouté immédiatement, et un grep -Pq "alias $1" && return au début, pour vous assurer que (1) vous n'avez pas de noms d'alias en double, (2) les alias sont définis immédiatement au lieu d'attendre qu'ils soient re-sourcés.

Si vous voulez être encore plus créatif (c’est ainsi que je le fais), autorisez-le également à prendre un numéro de votre historique et à le définir comme un alias ou un groupe de numéros attribué dans l’ordre à un ou plusieurs alias, etc.

J'ai consacré pas mal de travail à mon propre .bashrc au fil des ans - je le partage dans le cadre d'un projet appelé gxbase, mais comme ce sont "mes préférences", ce n'est probablement pas ce que "les autres" veulent. Les paramètres de configuration sont une chose personnelle very . La plupart des gens s'attendent à ce que les choses ressemblent à /etc/skel/.bashrc, et des choses comme l'achèvement de bash cessent de fonctionner si vous définissez trop d'options personnalisées :) Juste pour le fun, mon lien est http://gitorious.org/gxbase . Le fichier est en extras/my.bashrc/* (voir PS en bas si intéressé).

En ce qui concerne votre question, il y a many == des gens qui publient leurs soi-disant 'paramètres .bashrc ultimes' mais ils ne sont hélas que les ultimes pour them , ma réponse est la suivante: vous serez plus heureux si vous créez ce fichier vous-même et croyez-moi, pour l'amour de tout ce qui est saint; make [hors ligne] sauvegardes !!! :) Une copie papier (imprimée) est un bon moyen de la planifier davantage si vous voulez être encore plus créatif!

PS: Le contenu de .bashrc-git est une fourchette du projet gitsh, donc la plus grande part du crédit en revient à ce type, et l’intégration perlconsole & aptsh n’est pas non plus la mienne. Vous devrez installer les fichiers modded perlconsole & aptsh pour l'intégrer complètement aux répertoires virtuels.