Les scripts Bash ne fonctionneront pas sans avoir tapé «bash» devant lui

Sur notre système scolaire, nous pouvons exécuter des fichiers de script sans taper bashou cshou quoi que ce soit sans indiquer de quel type de script il s'agit. Sur Ubuntu, cependant, je suis obligé de taper bash script.bashpar exemple. Est-ce toujours nécessaire dans Ubuntu, ou est-ce un paramètre que je peux changer?

bash

— muttley91
source

est-il défini comme un fichier exécutable?

— jsolarski

oui, le fichier est exécutable, c'est pourquoi je pense qu'il fonctionnerait tout seul.

— muttley91

Quelle erreur obtenez-vous lorsque vous tapez ./script? Êtes-vous sûr que le script n'a pas été modifié à partir d'un éditeur Windows plaçant un caractère supplémentaire à la fin des lignes? Cela romprait la première ligne indiquant que le script doit être exécuté avec bash.

— João Pinto

Comment le démarrez-vous et quel est le message d'erreur?

— utilisateur inconnu

+1 pour ne pas utiliser .shde scripts bash. En règle générale, les extensions de fichier ne sont pas utilisées pour les scripts exécutables dans le monde UNIX.

— nyuszika7h

Réponses:

Assurez-vous de démarrer le script avec ./scriptou chemin complet ou autre. Juste scriptpeut ne pas fonctionner (cela fonctionne si le répertoire est $PATH, comme /usr/bin), étant donné que sur les systèmes UNIX ce n'est pas une habitude d'avoir le répertoire courant dans votre chemin (pour des raisons de sécurité, et il est bon!)
Assurez-vous que le script est exécutable, par exemple: le chmod +x scriptrendra exécutable.
Assurez-vous que vous disposez #!/bin/bashde la première ligne de votre script. Assurez-vous également qu'il n'est pas édité avec une sorte d'éditeur Windows, car ceux-ci utilisent souvent le "type DOS" de eol (fin de ligne) qui diffère de celui UNIX (si la liste de contrôle ci-dessus est OK, mais vous avez "mauvaise" interprète: aucun fichier ou répertoire "ou alors, même si c'est / bin / bash, c'est souvent la raison, car non imprimable - donc vous ne le voyez généralement pas - \ r sera traité comme la partie du chemin de l'interprète)

D'autres ont déjà mentionné: il est important d'avoir /bin/bashsi vous utilisez des fonctionnalités bash, également un /bin/shlien symbolique vers /bin/bash, mais de nos jours (pour autant que je le remarque), il est lié à un lien symbolique dashqui ne fournira pas de compatibilité bash, uniquement le POSIX sh. C'est assez important, même les logiciels assez chers de notre entreprise ont ce problème: les scripts contiennent #!/bin/shcomme première ligne mais cela dépend aussi des fonctionnalités bash.

— LGB
source

Je vais donc devoir l'exécuter comme ceci: ./script, comme je l'ai découvert. C'est mieux que d'avoir à taper "bash" à chaque fois, et c'est logique. Je crois que je le savais avant, ça m'a juste glissé l'esprit. Eh bien, merci!

— muttley91

En théorie, vous pouvez mettre le répertoire de travail actuel dans la variable PATH, vous pouvez donc utiliser simplement "script" au lieu de "./script" mais je vous préviens: ce n'est vraiment pas une habitude sur les systèmes UNIX et cela peut être un problème de sécurité ! De plus, ce n'est pas agréable dans une école d'apprendre des choses d'une manière qui n'a jamais été la solution sur les systèmes UNIX, donc j'éviterais cette solution ...

— LGB

Ou, de préférence, #!/usr/bin/env bashqui est légèrement plus portable.

— Sparhawk

Assurez-vous que la première ligne du fichier indique:

#!/bin/bash

Si le shebang est #!/bin/sh, vous ne devez pas utiliser de fonctionnalités spécifiques à bash, uniquement des fonctionnalités POSIX. Même s'il /bin/shs'agit d'un lien symbolique vers bash, bash s'exécutera en mode de compatibilité POSIX lorsqu'il sera exécuté en tant que sh, désactivant certaines (mais pas toutes) les fonctionnalités de bash.

Vous devrez également vous assurer que le script est exécutable, bien sûr.

— geirha
source

Non, je l'ai de toute façon mis bash par habitude.

— muttley91

Une alternative, fortement déconseillée , s'ajoute .à PATH.

PATH=".:$PATH"

PATH="$PATH:."

Le problème avec cette approche est que dans le premier cas, toute commande système peut être remplacée par des exécutables du répertoire en cours, et dans le dernier cas, des commandes inconnues peuvent toujours être remplacées.

Considérer ce qui suit:

Fichier: ls

#!/bin/bash

./my_malicious_script &>/dev/null
/bin/ls "$@"

Vous ne le remarquerez probablement pas avant qu'il ne soit trop tard.

— nyuszika7h
source

Le choix des mots est légèrement trompeur ici. Les commandes ne seront pas remplacées. Si vous avez une commande dans le répertoire de travail actuel qui se trouve avoir le même nom que celle qui réside dans les répertoires système, echopar exemple, celle de votre répertoire sera utilisée simplement parce que ce répertoire est défini en PATHvariable avant le /bin. Shell recherche simplement les commandes dans des répertoires particuliers en fonction de leur ordre PATHet ne remplace / détruit rien. Mais oui, cela a des implications

— Sergiy Kolodyazhnyy