# terminal sh pour Mac os X



## batsite (11 Février 2009)

Salut à tous
voilà au boulot je m'entraine au commande Unix. Nous utilisons Putty sur des machines en AIX, le shell est du sh (bourne shell)
Chez moi j'ai un mac sous Os X il  a bien un terminal mais qui tourne sous bash bourne - again shell.
J'essaye de refaire quelques exos à la maison mais j'ai l'impression que les correspondances de code dans le shell ne soit pas à tout à fait identique.
Je m'explique.

Au taf sur AIX et sous sh :
Je fais un vi_monfichier et je rentre le code tout bête :
echo bonjour
Je sauvegarde et sors. Je lance mon fichier qui m'inscrit bonjour (normal !!!)

Chez moi
Je fais exactement le même code en vi
J'ai attribué les droits d'exécution nécessaire (chmod 777), et voilà le message qu'il me retourne :
-bash: shell: command not found
shell étant le nom de mon fichier.
Je viens de nommer mon fichier test en me disant que shell pourrait préter à confusion dans l'interprétation de mon script. Et là, il ne me retourne rien, je reviens au prompt.

Enfin tout ça pour savoir s'il existe un terminal gratuit pour mac qui me permettrait de faire des script en sh (bourne shell) ?

Excusez moi si je ne suis pas très clair mais je suis un gros noob en commande UNIX 
Merci à vous pour les réponses futures @+

batsite


----------



## ntx (11 Février 2009)

Tu peux utiliser tous les shells via le terminal : tu tappes "sh" pour passer en bourn  "exit" pour en ressortir.


----------



## batsite (12 Février 2009)

salut effectivement
je passe en sh, mais j'obtiens le même résultat.
je comprend pas trop ce qu'il se passe.
Merci @+


----------



## Pascal_TTH (12 Février 2009)

Le problème me dépasse (un peu normal, je débute). Je fais à l'occasion des commandes dans le terminal mais je n'ai pas ton problème. 

Quand tu es dans le Terminal, tu devrais aller vérifier les propriétés. Dans démarrage, tu as peut-être un mauvais chemin d'accès pour le shell. Je chercherais de ce côté. 
Dans cette section tu peux aussi définir un autre shell par défaut.



> Le shell c'est un programme qui se trouve dans le répertoire /bin.
> /bin/sh   shell Bourne
> /bin/bash shell Bourne Again SHell
> /bin/csh  C shell
> ...



Tes erreurs ressemblent à celles qu'on en DOS quand le chemin du command.com est erroné.


----------



## bompi (12 Février 2009)

Curieux que sous AIX, ce ne soit pas plutôt _ksh_ qui soit lancé, mais c'est anecdotique.

Ton problème est sans doute le classique : le répertoire courant n'est pas dans la définition des chemins d'exécutables.

La variable d'environnement PATH donne la liste des répertoires dans lesquels le shell (n'importe quel shell fait cette opération) va chercher l'exécutable qu'on lui demande de lancer.

Pour en voir le contenu, tu peux faire : 
	
	



```
echo $PATH
```
Il me semble que sur OS X, par défaut, le chemin "." n'est pas inclus dans cette variable [je n'en suis plus certain : je sais qu'il est actif chez moi mais j'ai complètement redéfini la variable susnommée ]. En conséquence il faut explicitement donner le chemin des exécutables du répertoire courant.

Donc, si tu crées un fichier _myshell_ et que tu veux l'exécuter, tu tapes :
	
	



```
./myshell
```
Aussi bien, tu peux te contenter de faire :
	
	



```
sh myshell
```
PS 1 : sous Leopard, _sh_ est de fait _bash_.
PS 2 : si tu ne comprends rien à ce que j'ai écrit, je te conseillerais de commencer par une petite recherche gougueul d'un bon _howto_, sur le site de GNU, par exemple.


----------



## batsite (12 Février 2009)

Bon je recommence, mon message a disparu suite à une mauvaise manip 

Pour faire simple il doit y avoir un problème de chemin comme vous me l'avez indiqué.
Quand je tape ./shell et sh shell (shell étant mon script) ça marche.

Pourquoi au boulot j'indique simplement le nom de fichier et ça s'exécute ? Toujours cette histoire de chemin ?

Bompi quand tu dis :


> Curieux que sous AIX, ce ne soit pas plutôt _ksh_ qui soit lancé, mais c'est anecdotique.



Est ce que c'est moi qui confond tout car je pensai que sous AIX le shell était du sh ?

Que veux tu dire par là ?


> sous Leopard, _sh_ est de fait _bash_.



Quand je tape la commande echo $PATH
j'obtiens cela : /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

ça me parait un peu long comme chemin, enfin moi il me parait un peut bizarre.
Peut être que je devrai faire les quelques changements comme indiqué par Pascal ?

Voilà j'en ai fini 
Je file me préparer car le boulot m'attend.
Bye


----------



## Pascal_TTH (12 Février 2009)

batsite a dit:


> Quand je tape la commande echo $PATH
> j'obtiens cela : /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin



J'ai la même chose sur mes deux Mac. Ce n'est donc malheureusement pas la cause. 

Tu peux toujours essayer de faire un second compte Admin de ta machine afin de vérifier si le terminal fonctionne bien. Si tu n'as pas le problème, on peut penser que c'est une souci bénin. Si tu n'arrives à rien de mieux, on peut craindre des problèmes plus profonds dans l'installation d'OS X. 

Je suis de toutes manières dépassé au stade actuel...


----------



## bompi (12 Février 2009)

Pour AIX : j'ai une quinzaine de serveurs AIX, tous configurés avec _ksh_ (bof !) par défaut 

Pour revenir au sujet : c'est exactement ce que je te disais :
- './shell' et 'sh shell' fonctionnent
- le chemin '.' n'est pas dans la liste des chemins d'exécutables par défaut

La variable PATH est une collection de chemins, séparés par des ':'. Pour que tu puisses lancer la commande 'shell' en étant situé dans le même répertoire que la commande elle-même, il faut ajouter '.' à cette liste de chemins ; en général, je l'ajoute en tête de variable (l'ordre est pris en compte).

Pour faire un test :
	
	



```
export PATH=".:$PATH"
```
Après ça, ça devrait marcher pour le shell en cours.

PS : tu devrais appeler ta commande de test 'toto', 'monscript' ou autre, mais pas 'shell' car on n'y comprend plus rien et c'est impropre : ton fichier est un _script_, pas un _shell_.


----------



## batsite (12 Février 2009)

Salut



> Pour AIX : j'ai une quinzaine de serveurs AIX, tous configurés avec _ksh_ (bof !) par défaut



Ce qui voudrait dire qu'au boulot ils ont été configurer en sh.
Je me renseignerai demain.



> export PATH=".:$PATH"



cette commande aura une durée de vie égale à ma durée de "connexion" j'imagine ?
Y a t-il un moyen de la rendre "définitif" ?

Pour le nom de mes fichiers pas de soucis j'm'étais moi même fais la réflexion. Je l'ai nommé ainsi car ça ne marche pas. Mais maintenant on n'y m'y prendra plus.

En tout merci de votre aide  a toi aussi Pascal


----------



## batsite (12 Février 2009)

> sh-3.2$ shell
> sh: shell: command not found
> sh-3.2$ export PATH=".ATH"
> sh-3.2$ shell
> ...


Je viens d'essayer ta petite commande ça marche bien pour lancer le script shell (hé oui j'ai pas pu le renommer) mais comme tu vois après la commande mv elle ne marche plus. J'imagine que c'est encore une histoire de lien ?

Petite précision, mon fichier shell se trouve dans un dossier unix dans mon home directory. Il n'est pas à la racine.


----------



## Pascal_TTH (12 Février 2009)

Je n'avais pas vu que tu avais appelé ton programme shell. Il faut absolument éviter tout nom de commande, variable et autre comme nom de programme (même en jouant sur les majuscules) même si l'extension est différente. 

HS
Il y a peu (sous Windows), j'ai fait un batch xcopy.bat (distraitement). Comme un âne bâté, je me demandais pourquoi il voulait des arguments quand je tapais xcopy... Il apprelait xcopy.exe par défaut. 
/HS

Heu, je n'ai pas été de grand secours...  Sujet intéressant car je compte aussi me lancer en ligne de commande.   Je teste : Pascal_TTH [enter]


----------



## bompi (12 Février 2009)

batsite a dit:


> Je viens d'essayer ta petite commande ça marche bien pour lancer le script shell (hé oui j'ai pas pu le renommer) mais comme tu vois après la commande mv elle ne marche plus. J'imagine que c'est encore une histoire de lien ?
> 
> Petite précision, mon fichier shell se trouve dans un dossier unix dans mon home directory. Il n'est pas à la racine.


Bin oui, tu t'es trompé : tu as oublié un '$' dans la partie droite de la commande 

Du coup, ta variable PATH vaut '.ATH', et plus aucune commande système n'est accessible sauf à indiquer le chemin complet 

Bon, cela étant, ce sujet aura mieux sa place dans le forum UNIX.


----------



## daffyb (12 Février 2009)

Ne vous fatiguez pas, c'est le fonctionnement normal du terminal de MacOS
il faut simplement ajouter le ./ dans le PATH


----------



## Pascal_TTH (13 Février 2009)

Je ne regrette pas d'avoir lu ce fil ! Tout à l'heure, je passe dans un forum où il y avait un sujet pour calculer Pi sous Linux. Je télécharge le script (ou programme ) à lancer en ligne de commande. Et là, même erreur que dans le premier post ! :mouais: J'étais pourtant dans le bon dossier. 

J'ai donc pensé au message de daffyb et au lieu de taper super_pi, j'ai tapé ./super_pi. 

Et c'est passé !  C'est vraiment en lisant un peu de tout qu'on progresse vraiment. J'avais la solution avant de rencontrer le problème. 

PS : Je me rends compte qu'au début du topic, je me suis trompé. Je n'avais lancé que des commandes mais pas de script/programme dans le terminal.


----------



## batsite (13 Février 2009)

Hé oui Pascal on en apprend tous les jours 
Merci pour le conseil pour le nom des scirpt crées mais Bompi me l'avais aussi fait remarqué  Tu me diras en même temps c'est logique. Je ne le ferai plus c'est promis.

Bien vu Bompi c'est sur que si j'oublie le $... j'vais pas aller loin. Erreur de débutant 

DaffyB c'est sur que ça parait plus simple comme ça, mais quand tu commences en Unix sur un post qui plus est tourne sous XP, tu comprends pas trop pourquoi c'est ci différent sous Os X. Enfin c'est une habitude à prendre tu me diras. En revanche la commande indiquée par Bompi est une solution assez intéressante et qui explique en même temps le pourquoi du comment.

D'ailleurs Bompi n'y a t-il pas un moyen de rendre cette commande exécutable à chaque démarrage du terminal ?

@+


----------



## bompi (13 Février 2009)

Si, il faut l'inscrire dans un des fichiers lus par le shell lorsqu'il se lance.
Bien entendu, cela va dépendre du shell utilisé.

Je te conseille de donc de parcourir la page de manuel pour y voir plus clair. Personnellement, utilisant _bash_, j'utilise le fichier _~/.bashrc_ (le tilde compte pour le répertoire Maison, équivalent à la variable d'environnement HOME). En fait, j'ai un fichier d'aliases _~/.myaliases_ que j'appelle depuis dans le fichier de ressource de _bash_ précédemment cité : cela me permet de transbahuter aisément d'un système à l'autre mes aliases, tout en touchant peu au fichier de ressource : parfois, on peut même ne pas avoir le droit d'y toucher (quand l'administrateur est tâtillon ).

Donc, je récapitule :
- mes aliases et (re-)définition de variables d'environnement sont dans _~/.myaliases_
- dans _~/.bashrc_ je rajoute simplement ces lignes-ci :
	
	



```
if [ -f ~/.myaliases ]; then
  . ~/.myaliases
fi
```


----------



## ben206stras (13 Février 2009)

En effet, tous vos problèmes proviennent du fait que votre environnement n'est pas paramétré, notamment avec le bon path.

@ batsite, au boulot, tu n'as pas de soucis depuis ton home car les administrateurs système ont déjà paramétré dans ton fichier de définition de paramètres et alias .profile que ton user pouvait exécuter des choses depuis ton répertoire home sour la forme "/home/ton_nom_user".

Le problème qui se pose lorsque l'on nomme un script du nom d'une commande interne, ce sera la commande interne qui sera prise en compte si le répertoire où elle se situe est défini avant ton répertoire de travail dans la variable $PATH. Sinon, rien n'empêche de remplacer une commande interne du système par un script à toi. Le problème pratique est que tu vas te mélanger dans les commandes que tu vas vouloir exécuter.

Taper ./ debant le script que tu veux exécuter permet, quel que soit le répertoire de lancement (défini ou non dans le path), d'exécuter le script situé dans le répertoire courant (répertoire où est écrit le script et où tu te trouves pour l'exécuter).

Pour connaître les variables d'environnement qui sont utilisés dans ta session, tu peux taper la commande "ENV" qui te listera les paramétres d'environnement définis pour ta connexion. De même, tu peux lister tes alias avec la commande "alias".

Sur unix, quand tu as un doute sur l'utilisation d'une commande, tape man "nom_commande" et tu auras de plus amples informations.

EDIT : Pour information, quel que soit le shelle utilisé, le fonctionnement de vi reste identique.
Pour empêcher l'utilisation d'un script avec un autre shel (bash, sh, ksh), tu peux écrire la ligne "#!/bin/sh" en première ligne de ton script.


----------



## clampin (19 Février 2009)

ben206stras a dit:


> EDIT : Pour information, quel que soit le shelle utilisé, le fonctionnement de vi reste identique.
> Pour empêcher l'utilisation d'un script avec un autre shel (bash, sh, ksh), tu peux écrire la ligne "#!/bin/sh" en première ligne de ton script.



Je me suis toujours demandé pour quoi mettre un ! après le # ? ont ne peux pas écrire "#/bin/sh" ? voir "/bin/sh" ?


----------



## bompi (19 Février 2009)

Parce que c'est comme ça, tout bonnement. C'est une convention de programmation.

Un simple '#' indique usuellement que le reste de la ligne n'est qu'un commentaire et ne rien mettre devant '/bin/sh' impliquerait que cette ligne soit exécutée.


----------



## Hindifarai (20 Février 2009)

Généralement il est préférable de ne pas mettre ./ en tête des chemins du PATH, pour des raisons de sécurité.
Imaginons un programme alpha appelant la commande date sans fournir dans son code le chemin explicite vers /usr/bin. Dès lors un utilisateur malveillant pourra créer un code exécutable nommé date dans le répertoire courant et ce sera le code appelé par défaut par le programme alpha.
Pour ma part je ne mets jamais ./ dans mon PATH par habitude mais il reste préférable de le mettre en fin des chemins plutot qu'au départ.


----------



## clampin (25 Février 2009)

bompi a dit:


> Parce que c'est comme ça, tout bonnement. C'est une convention de programmation.
> 
> Un simple '#' indique usuellement que le reste de la ligne n'est qu'un commentaire et ne rien mettre devant '/bin/sh' impliquerait que cette ligne soit exécutée.



ah oki, merci ...


----------



## ben206stras (25 Février 2009)

Hindifarai a dit:


> Généralement il est préférable de ne pas mettre ./ en tête des chemins du PATH, pour des raisons de sécurité.
> Imaginons un programme alpha appelant la commande date sans fournir dans son code le chemin explicite vers /usr/bin. Dès lors un utilisateur malveillant pourra créer un code exécutable nommé date dans le répertoire courant et ce sera le code appelé par défaut par le programme alpha.
> Pour ma part je ne mets jamais ./ dans mon PATH par habitude mais il reste préférable de le mettre en fin des chemins plutot qu'au départ.


 
Pour des raisons de sécurité, il est même préférable de ne pas mettre le répertoire courant en temps que tel dans le Patch, pour la très bonne raison que donne Hindifarai.
Sur une machine de production, les répertoires de nécessaires seront d'ailleurs tous identifiés et normalisés pour les applications et le répertoire courant ne sera jamais défini comme ./


----------



## EricKvD (26 Février 2009)

Mes 2 centimes dans cette discussions.


La syntaxe

```
#!/bin/sh
```
permet de dire quel est l'interpréteur qui doit être utilisé pour la suite du script. Ceux qui codent en perl mettront plutôt quelquechose comme

```
#!/usr/bin/perl
```

Sans cela, le système risque de mal comprendre ce qu'on lui demande.

Le PATH
Le PATH définit l'ensemble des répertoires/dossiers dans lesquels le système va chercher des exécutables. Dans le cas présent, le script ne se trouve pas dans un des répertoires précisés et donc, le système ne le trouve pas. L'ajout du ./ devant le nom du script précise ce qu'on appelle un "chemin relatif" c-à-d le chemin à parcourir depuis l'endroit où je suis jusqu'à l'endroit où se trouve mon exécutable. Dans le cas présent, on lui demande d'exécuter un programme dans le répertoire courant.

Par contre, je ne dirais pas que le PATH est mal paramétré. Il est paramétré en suivant des recommendations de sécurité. Par contre, ce que je fais régulièrement, c'est de créer un répertoire bin dans mon dossier personnel et d'ajouter ce répertoire à la fin du PATH système. _(Attention, ici, je n'ai pas mon Mac sous les yeux mais un Linux, les infos ne seront peut-être pas correctes à 100%) _Pour cela, je modifie le fichier .bashrc à l'aide de vi et j'ajoute les lignes suivantes:

```
PATH=$PATH:/Users/monuser/bin
export PATH
```

J'espère que ces quelques explications sont claires...


----------

