terminal sh pour Mac os X

[batsite]

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]

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

 

[batsite]

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]

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
/bin/ksh Korn shell
/bin/tcsh C shell amélioré
/bin/zsh Z shell

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

 

[bompi]

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]

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]

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]

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]

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]

sh-3.2$ shell
sh: shell: command not found
sh-3.2$ export PATH=".ATH"
sh-3.2$ shell
bonjour
date
sh-3.2$ mv shell script1
sh: mv: command not found

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]

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]

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]

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

 

[Pascal_TTH]

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]

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]

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]

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]

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]

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]

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.