Discussion :

[Hibou57]

re-Coucou,

BusyBox n'est pas une distribution, mais je pense que la meilleur place pour ce topic est dans « distribution », car busybox est associé à certaines formes de distributions, et il est d'ailleur une sorte d'environnement.

Je veux créer un script qui commence par la ligne « #!/bin/bash ». Mais quand je démarre le script, j'ai systématiquement le message « applet not found », et l'execution s'arrête. Les scripts ne fonctionnent qu'avec « #!/bin/sh ». Ce BusyBox implémente pourtant bash. Et le bash fonctionne bien en ligne de commande, puisque que « alias ls="ls --color" » est normalement executée (c'est cette commande que je veux intégrer au script, raison pour laquelle je ne peux pas le laisser interpréter par sh, ou plutôt busybox en mode sh... alias n'est pas une fonction de sh, mais seulement de bash).

Pourquoi le bash de BusyBox fonctionne t-il en ligne de commande, mais ne peut pas être spécifié pour l'interprétation d'un script ?

[gnto]

re-Coucou,

BusyBox n'est pas une distribution, mais je pense que la meilleur place pour ce topic est dans « distribution », car busybox est associé à certaines formes de distributions, et il est d'ailleur une sorte d'environnement.

Je veux créer un script qui commence par la ligne « #!/bin/bash ». Mais quand je démarre le script, j'ai systématiquement le message « applet not found », et l'execution s'arrête. Les scripts ne fonctionnent qu'avec « #!/bin/sh ». Ce BusyBox implémente pourtant bash. Et le bash fonctionne bien en ligne de commande, puisque que « alias ls="ls --color" » est normalement executée (c'est cette commande que je veux intégrer au script, raison pour laquelle je ne peux pas le laisser interpréter par sh, ou plutôt busybox en mode sh... alias n'est pas une fonction de sh, mais seulement de bash).

Pourquoi le bash de BusyBox fonctionne t-il en ligne de commande, mais ne peut pas être spécifié pour l'interprétation d'un script ?

Quel est le chemin de bash ?

which bash

[Hibou57]

Salut, ... merci pour ta réponse

Le bash est dans le même chemin que le sh : /bin/bash et /bin/sh, qui sont tous deux des liens vers BusyBox qui les implémente, et qui se comporte comme l'un ou l'autre selon l'appel.

BusyBox fourni certaines fonctionnalités, qui dépendent de sa configuration à la compilation. Ors, j'ai bien vérifié qu'il reconnais « alias », et que le problème ne vient donc pas de là.

Je vais peut-être en dire plus, pour être plus claire...

En fait, je cré un fichier .bash_login, et dans ce fichier, je voulais ajouter « alias ls="ls --color" ». Je place le fichier dans le home de mon root, et je redémarre. Je tente ls : ko, pas de couleur. Je copie le fichier dans la racine. Idem, same story. Je retape la commande d'alias à l'invite : ça marche pourtant bien. Je tente alors d'executer directement le fichier .bash_login, et là, j'ai le message « .bash_login: applet not found ». Ce message signifie que bash (implémenté par busybox), ne reconnais pas la fonction « .bash_login ». Mais le hic, c'est que ce n'est pas une fonction de bash, puisque c'est le script que j'appel.

C'est vraiment perturbant.

N.b. J'utilise busybox pour une solution légère.

[gnto]

sur le busybox de openwrt V1.00 je n'ai pas de /bin/bash mais j'ai /bin/sh et /bin/ash

Quelle version de busybox as tu ?

Et le bash fonctionne bien en ligne de commande, puisque que « alias ls="ls --color" » est normalement executée (c'est cette commande que je veux intégrer au script, raison pour laquelle je ne peux pas le laisser interpréter par sh, ou plutôt busybox en mode sh... alias n'est pas une fonction de sh, mais seulement de bash).

Comment expliques-tu que je n'ai pas de /bin/bash mais j'ai alias ?

[Hibou57]

Comment expliques-tu que je n'ai pas de /bin/bash mais j'ai alias ?

Comme on se retrouve mon ami

Je venais justement faire une remarque à ce sujet : je crois qu'en fait alias est peut-être également une fonction de ash. Ou alors, c'est BusyBox qui étend ash avec cette fonction (parce que jusque maintenant, je n'ai jamais entendu parler de alias que sous le shell bash).

Je viens de remarquer une autre chose : j'ai pensé que je pourrais peut-être essayer de spécifier bash comme shell initial (dans inittab). Et là, au redemarrage, BusyBox se bloque sur un message d'aide listant les fonctions implémentées. Y figure : sh, ash et ... bash (pourtant). ... Etrange

Donc bash est implémenté, mais ne peut pas être utilisé comme shell (!). Peut-être alors bash n'est-il que partiellement implémenté.

Peut-être est-ce la raison pour laquelle BusyBox me renvoyait le message « .bash_login : applet not found » : ceci signalerais qu'il ne prend pas en charge la lecture de .bash_login au démarrage (note : je l'executait pourtant manuellement lorsque j'obtint ce résultat). Ceci peut être confirmé par une autre découverte : si je renome .bash_login en test et que je lance test, je n'ai alors plus de message d'erreur (bien que l'alias ne fonctionne toujours pas.. j'y reviens plus loin).

La reconnaissance de l'invocation de bash par BusyBox, semble donc n'être qu'un placeholder.

Question 1 : alias est-il une fonction de bash que BusyBox ajoute à ash par commidité, ou alias est-il aussi une fonction de ash ? Je vérifierai, et je posterai la réponse ici.

Question 2 : si seul ash (qui est plus étendu que sh, sauf erreur, et donc plus interessant quand-même) peut-être utilisé comme shell sous un environnement BusyBox, alors existe-il pour ash, un fichier équivalent à .bash_login, qui soit executé au démarrage du shell ?

Question 3 : Concernant la fonction alias, j'ai fait un teste. J'ai ajouté dans le script (alors renomé en test), une commande alias sans paramètres, afin d'afficher les alias actifs pendant l'execution du script. J'y retrouve bien l'alias de ls précédement défini (sur la ligne exactement précédente). Mais quand le script se termine, la commande alias alors executée sous le shell, ne me retourne plus aucun alias actifs. Il y a apparament un phénomène d'exportation qui s'applique aux effets de la commande alias (ce qui m'a surpris, car sur le serveur Debian de Cegetel, sur lequel je me connecte en SSH, je place sans plus de chose, alias dans .bash_login, et l'alias reste actif même à la sortie du script, sous le shell d'invocation). Existe-il une commande permettant d'exporter les alias définis sous ash pour qu'ils restent actifs même à la sortie du script ?

BusyBox ne supporte pas pleinement bash : Retenons en tous cas, comme tu le dis Gnto, que BusyBox n'implémente pas correctement bash, même s'il le donne pourtant comme implémenté dans son écran d'aide.

[Hibou57]

En ce qui concerne la fonction alias, elle est reconnue par sh, ash et bash (et pas seulement par bash comme je le pensais).

Pour l'équivalent de .bash_login, on pourra employé /etc/profile et $HOME/.profile. Je suppose qu'il sont lus l'un aprés l'autre, même si ce n'est pas dit explicitement. Ces deux fichiers sont lus seulement quand ash est invoqué par le nom « -ash ». Ceci se produit dans inittab. Mais alors qu'en est-il du shell spécifié dans /etc/passwd ?

Comme bash est censé être compatible avec ash, alors .profile et profile sont surement reconnu par bash également. C'est à se demander pourquoi .bash_login a été ajouté, vu que .profile et profile auraient suffit.

Je me demande d'ailleurs comment le shell peut être invoqué comme « -ash », puisqu'il n'existe pas de lien de ce nom... C'st pourtant bien les entrés que l'on trouve dans inittab.

Pour l'exportation des alias, je n'ai rien trouvé.

Par contre, une petite question annexe : je ne trouve rien qui détail les chaînes du prompt de ash, je ne trouve ces informations que pour bash. C'est normal ?

[Hibou57]

Je suis perdu ... je n'y comprends plus rien ...

Cette page : ici, dis que ash n'a pas de support pour les alias ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
if [ ! "$SHELL" = "/bin/ash" ]; then # ash doesn't have aliases
   alias net='term < /dev/modem > /dev/modem 2> /dev/null&'
fi

Et pourtant Ici, il est question des alias avec ash.

Aliases are exported and imported in a similar fashion to variables. The actual appearance of an alias in an environment is quite different though. Each alias exported creates a string in the environment of the form:

ALIAS_magic=name~value
where magic is some meaningless string used to keep the apparent name of the entries distinct.

So what ? Qu'en est-il vraiment ???

[vosaray]

Ca ne va pas vous aider beaucoup, mais j'ai travaillé sur un Linux embarqué qui utlisait la busybox, et le seul shell dispo etait sh.

[Hibou57]

Ca ne va pas vous aider beaucoup, mais j'ai travaillé sur un Linux embarqué qui utlisait la busybox, et le seul shell dispo etait sh.

Beh Vosaray, ça dépend de la configuration qui précéde la compilation. Mais le miens supporte bel et bien ash... Mais je fais une excuse à Gnto : j'ai carrément halluciné... mon BusyBox ne supporte pas bash (une inattention), mais il y a un lien bash qui pointe sur ash qui lui même pointe sur BusyBox. J'ai fait une recherche sur le contenu des fichiers : BusyBox contient la chaîne bash (je ne sais pas pourquoi), ainsi que mount et umount.

Ca ne sert plus à rien maintenant, mais la version est BusyBox v0.60.5 (2003.02.16-05:06+0000)

Le problème initial est maintenant résolu. Je peux placer « alias ls="ls --color" » dans /etc/profile, et je le fait suivre d'un « export ls ». Je marque donc résolu.

Quelques questions soulevées entre-temps, reste tout de même en suspend. Le $HOME/.profile ne semble pas être invoqué au démarrage, mais seulement le /etc/profile. J'ai vérifié les droit, c'est ok... question sans réponse pour le moment.

Concernant le support de alias, c'est ambigu. Même en lisant la documentation de ash (d'ailleurs nomée ae à cet endroit), on y parle d'aliases, mais pas du mot clé alias (qui n'apparait jamais, sauf dans l'exemple, en majuscule, ce qui n'est pas normal, et de plus, suivit d'un blanc souligné tout accolé, ce qui est encore moins normal). Et il y a cette exemple de script où il est dit qu'il n'y a pas d'alias avec ash. Alors extention non-standard ou manquement dans la documentation ?