Forum Linux.debian/ubuntu Nécessité de préciser "sh script.sh"

Posté par charlieecho le 02 avril 2005 à 19:22.

Étiquettes : aucune

avr.

2005

Je "débute" sous Debian, et j'ai un pb que je n'arrive pas à résoudre (mais que je n'avais pas sous Mdk).

Mes scripts (script.sh) commencent par
#!/bin/sh

quand je tape dans un xterm : ./script.sh, j'ai l'erreur
/bin/sh: bad interpreter: Permission non accordée
quand je tape : sh ./script.sh , ça se passe bien.
Et évidemment, sh est bien en /bin/sh

Ca m'embête surtout parce que je ne peux plus "cliquer" sur un script pour le lancer : il faut passer par la fenêtre de commandes.

Que se passe-t-il ?
Merci

# Droits

Posté par Pinaraf le 02 avril 2005 à 19:23. Évalué à 2.

Tu dois faire un chmod +x script.sh (ou donner les droits d'exécution dans ton gestionnaire de fichiers)
- [^] # Re: Droits
  
  Posté par charlieecho le 02 avril 2005 à 19:26. Évalué à 3.
  
  C'est pas ça...
  J'aurais du préciser effectivement, mais les droits sont ok.
# sh

Posté par Matthieu Moy (site web personnel) le 02 avril 2005 à 19:40. Évalué à 3.

Vérifie que "which sh" donne bien /bin/sh
- [^] # Re: sh
  
  Posté par charlieecho le 02 avril 2005 à 19:45. Évalué à 2.
  
  Oui, which sh donne bien /bin/sh.
  - [^] # Re: sh
    
    Posté par nikitae le 02 avril 2005 à 23:07. Évalué à 2.
    
    utilise bash à la place de sh (->/bin/bash)
    
    sh est un alias de bash
    
    j'irais même jusqu'à dire d'utiliser ksh(korn shell)
    je le trouve plus cohérent et un peu plus puissant
    - [^] # Re: sh
      
      Posté par Matthieu Moy (site web personnel) le 03 avril 2005 à 21:40. Évalué à 2.
      
      > sh est un alias de bash
      
      Pas toujours. Et /bin/ksh n'existe pas sur tous les systèmes que j'ai utilisés jusqu'ici. Donc, pour être portable, le mieux est encore /bin/sh.
      - [^] # Re: sh
        
        Posté par nikitae le 04 avril 2005 à 10:53. Évalué à 3.
        
        pour etre portable..il devrait mettre un espace en # et le reste de la premiere ligne
# /etc/shells

Posté par Obsidian le 02 avril 2005 à 20:45. Évalué à 3.

Peut-être faut-il que « /bin/sh » se trouve dans /etc/shells ...
- [^] # Re: /etc/shells
  
  Posté par daggett le 03 avril 2005 à 08:41. Évalué à 1.
  
  /etc/shells n'est utilisé que pour autoriser le shell de connexion (celui qui a son entrée dans /etc/passwd), ça n'a aucun impact sur des interpréteurs ou shells qu'on lancerait à la main par la suite.
# mount + noexec ?

Posté par kolter (site web personnel, Mastodon) le 03 avril 2005 à 01:18. Évalué à 4.

j'ai l'impression (99% de chance) que ton script "script.sh" est enregistré sur une partition qui est monté avec l'option "noexec".

tapes "mount" dans un terminal pourvoir les partitons montées ainsi que leurs options puis modifies ton fstab !!!

pour comprendre l'utilité ou la non-utilité de noexec => man mount !!

M.
- [^] # Re: mount + noexec ?
  
  Posté par kolter (site web personnel, Mastodon) le 03 avril 2005 à 01:23. Évalué à 1.
  
  j'en profite pour poser une autre question, les seuls cas ou j'ai vu l'option noexec (explicitement mis pas une distrib) , c'était par ubuntu pour le /home mais jamais chez Debian !!!
  
  d'ou ma question tu utilises une vraie debian, une ubuntu,ou une distrib basé sur debian ?
  
  (àmoins que sarge ne fasse ce genre de choses mais je m'en souviens pas!)
  
  M.
- [^] # Re: mount + noexec ?
  
  Posté par Boa Treize (site web personnel) le 03 avril 2005 à 08:27. Évalué à 2.
  
  noexec, c'est essentiellement une non-utilité, puisqu'il suffit de faire « /bin/sh ./script.sh », « /bin/sh ./script.py » ou « /lib/ld-linux.so.2 ./executable » pour lancer un fichier dont on a les droits en lecture. Le seul moment où c'est utile, c'est quand on a des exécutables compilés statiquement, ce qui n'arrive pas tous les jours.
  - [^] # Re: mount + noexec ?
    
    Posté par Boa Treize (site web personnel) le 03 avril 2005 à 08:29. Évalué à 2.
    
    Évidemment, c'est « /usr/bin/python ./script.py »... Et ld-linux.so.2 ne sert que pour lancer des fichiers au format ELF (mais bon, ça fait des années qu'il n'y a plus que cela).
# Caractères parasites ?

Posté par daggett le 03 avril 2005 à 08:58. Évalué à 2.

Apparemment, ce sont des scripts que tu avais écrits, et qui marchaient, sous Mandrake, mais plus sous debian ? Ou bien aussi de nouveaux scripts que tu as fait depuis ta migration ? (quel éditeur de texte utilises-tu ?)

Vérifie que la ligne "#!/bin/sh" contient bien ce que tu crois, et qu'il n'y a pas de caractères invisibles supplémentaires, comme des sauts de lignes "MS-DOS": le kernel tenterait dans ce cas de trouver un /bin/sh^M au lieu de /bin/sh, par exemple.
Tu peux vérifier avec un "head -1 script.sh | od -c" qui doit te donner exactement:
0000000 # ! / b i n / s h \n
0000013

Si tu as par contre (remarque le \r en trop)
0000000 # ! / b i n / s h \r \n
0000013
ça peut venir de là. (par contre chez moi le message d'erreur ne serait pas le même que le tiens, j'ai juste ": bad interpreter: No such file or directory" puisque le \r écrase le début de la ligne)
# La réponse...

Posté par charlieecho le 03 avril 2005 à 14:38. Évalué à 4.

Comme pressenti par Kolter, ma partition était montée avec l'option users ; et c'est ça qui posait problème.

Pour info, c'est une vraie Debian testing.

Merci à tous pour vos idées, et surtout à kolter pour la "bonne".
- [^] # Re: La réponse...
  
  Posté par Jllc le 03 avril 2005 à 16:21. Évalué à 5.
  
  Comme pressenti par Kolter, ma partition était montée avec l'option users ; et c'est ça qui posait problème.
  
  Pour compléter : l'option user (ou users) implique les options noexec, nosuid, et nodev.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.