Question Résultat anormal à l'aide de la commande bash «set»


Quand on émet le set commande sans arguments à une invite bash (qui devrait afficher une liste de variables shell et leurs valeurs), un script de 8 274 lignes défile par. L'examen de ce script montre que ce sont des instructions pour le shell pour l'exécution des commandes - et il semble qu'il exécute des scripts python, ce qui en fait essentiellement un kludge de proportions monstrueuses. J'ai vu d'autres incorporations se comporter de plusieurs manières

Aucune sortie:

Me:~$ wait
Me:~$ true
Me:~$ test

Une erreur, sans indication d'utilisation:

Me:~$ select
bash: syntax error near unexpected token `newline'

Une erreur, avec indication d'utilisation:

Me:~$ source
bash: source: filename argument required
source: usage: source filename [arguments]
Me:~$ return
bash: return: can only `return' from a function or sourced script

J'ai du mal à comprendre pourquoi set se comporte de cette façon. Cela semble non documenté et je ne m'y attendais pas vraiment. Je suis inquiet de savoir pourquoi cela se produit. Quelqu'un peut-il expliquer?


2
2018-02-19 21:08


origine




Réponses:


Ces lignes de 8k sont principalement des fonctions d’achèvement du paquet bash-completion. Sur mon ancien ordinateur de bureau, bash utilise presque une seconde pour lire et définir toutes ces fonctions, que je n'utilise jamais pour la plupart, donc je les désactive.

Pour le désactiver, modifiez votre ~ / .bashrc, localisez ces trois lignes vers la fin et ajoutez une # à chacune des lignes.

if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
    . /etc/bash_completion
fi

La prochaine fois que vous exécuterez une session interactive, set ne produira qu'environ 50-100 lignes; principalement des variables d'environnement et des variables shell spéciales.


4
2018-02-20 06:07



Ceci explique ce qui se passe ici. Merci beaucoup. L'exécution de "set" sans arguments devrait afficher les variables "set". - Eric Weir
@Eric Weir Si vous voulez seulement voir les variables définies, vous pouvez également utiliser declare -p il vous montre également quel type de variable c'est. declare -faffiche les fonctions. Courir help declare pour un aperçu rapide de la façon de l'utiliser et de lire sa sortie. - geirha


De http://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html:

Si aucune option ou argument n'est fourni, set affiche les noms et les valeurs de toutes les variables et fonctions du shell, triés en fonction des paramètres régionaux actuels, dans un format pouvant être réutilisé en entrée pour définir ou réinitialiser les variables actuellement définies.

La même documentation, mais avec quelques exemples, peut être trouvée à: http://ss64.com/bash/set.htmlet la commande help set donne un résumé de ces informations.

Le comportement que vous décrivez est donc correct. Je suis d'accord que ce serait bien s'il y avait un --help option; généralement quand tous man set, apropos set, which set, et whatis set ne pas être utile, je vais essayer de passer --help Comme une option. Cela empêche une commande de s'exécuter avec des résultats inattendus, car cela me donnera un message d'aide ou déclenchera une erreur. Dans ce cas:

$ set --help
bash: set: --: invalid option
set: usage: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...]

Je trouve que cette astuce est une sécurité utile.

Je dois souligner que les premiers résultats Google pour "bash set" m'ont amené à cette documentation.


1
2018-02-19 21:43



Merci de répondre. Il y a une option d'aide, comme vous le dites; c'est "aide ensemble". Sinon, je pense que vous n'avez pas compris le problème, car je ne suis pas certain de la réponse que vous proposez. Non, le comportement que j'ai décrit n'est pas correct. voir la réponse de geirha. - Eric Weir
Comme je lisais votre article, vous aviez trois «questions»: (1) «Il semble non documenté», que j'ai pris comme version implicite de la question «Pourquoi n'est-ce pas documenté / où est-ce documenté? (2) "C'est un résultat inattendu", que j'ai pris comme version implicite de la question "Est-ce un résultat inattendu" et (3) "Je ne semble pas aimer ça", ce qui n'est pas une question du tout. Phoenix a répondu aux deux premiers du mieux qu'il pouvait compte tenu de votre ambiguïté. - Huckle
De plus, leur comportement que vous avez décrit est parfaitement correct. Selon son premier lien. - Huckle


Essayer de courir set | more et regardez près du bas du premier écran. Vous verrez probablement quelque chose comme ceci:

SSH_CLIENT='XXX.XXX.XXX.XXX 54284 22'
SSH_CONNECTION='XXX.XXX.XXX.XXX 54284 68.232.126.14 22'
SSH_TTY=/dev/pts/0
TERM=xterm
UID=114
USER=XXXXXXX
XDG_SESSION_COOKIE=740274408c1d635200f7415f00000009-1329686026.470247-1256968508
_=
__grub_script_check_program=grub-script-check
_scp_path_esc='[][(){}<>",:;^&!$=?`|\\'\''[:space:]]'
__expand_tilde_by_ref ()
{
    if [ "${!1:0:1}" = "~" ]; then
        if [ "${!1}" != "${!1//\/}" ]; then
...output truncated...       

Le script auquel vous faites référence est donc une variable shell intelligemment (sinon clairement) échappée. Pour ce qui est de wait,test, et true. Ceux-ci sont tous documentés avec des pages de manuel. Problème man <command> pour en savoir plus à leur sujet. La sortie vierge est le résultat attendu de ces fonctions.


0
2018-02-19 21:43



Merci de répondre. Je ne pense pas. L'exécution de "set | more" ne transforme pas la sortie en une variable shell. Et au fait, as-tu essayé "l'homme attends" toi-même? Vous n'obtenez pas la commande shell bash "wait" quand vous le faites. - Eric Weir
En fait, je n'ai pas essayé wait, J'ai essayé test et true parce que je savais qu'ils étaient tous les deux intégrés. Semble wait n'est pas, mais cela aurait dû être évident parce que man wait donne une entrée de la section 2 (appels système), ce qui explique pourquoi which wait ne renvoie rien. - Huckle
De plus, je n'ai pas dit que cela transformait la sortie en une variable shell, j'ai dit que la sortie de set contenait un script. - Huckle