J'ai un simple script bash qui prend des entrées et affiche quelques lignes avec celles-ci
fortinetTest.sh
read -p "Enter SSC IP: $ip " ip && ip=${ip:-1.1.1.1}
printf "\n"
#check IP validation
if [[ $ip =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
echo "SSC IP: $ip"
printf "\n"
else
echo "Enter a valid SSC IP address. Ex. 1.1.1.1"
exit
fi
J'ai essayé de les télécharger sur mon serveur, puis d'essayer de l'exécuter via curl
Je ne sais pas pourquoi l'invite de saisie ne se déclenche jamais lorsque j'utilise cURL/wget.
Est-ce que je manque quelque chose?
Comment peut-on s'y prendre et déboguer plus loin?
Je suis ouvert à toute suggestion en ce moment.
Toute astuce/suggestion/aide sur ce sera sera très apprécié!
Avec la forme curl ... | bash
, stdin de bash lit le script et stdin n'est donc pas disponible pour la commande read
.
Essayez d’utiliser un Process Substitution pour appeler le script distant comme un fichier local:
bash <( curl -s ... )
Votre problème peut être simplement reproduit en exécutant le script comme ci-dessous
$ cat test.sh | bash
Enter a valid SSC IP address. Ex. 1.1.1.1
Cela est dû au fait que la bash que vous lancez avec une pipe
ne reçoit pas une TTY
; lorsque vous faites un read -p
, il est lu à partir de stdin
qui est le contenu du test.sh
dans ce cas. Donc, le problème n'est pas avec curl. La question ne lit pas du tty
Donc, la solution est de vous assurer que vous êtes prêt à partir de tty
read < /dev/tty -p "Enter SSC IP: $ip " ip && ip=${ip:-1.1.1.1}
printf "\n"
#check IP validation
if [[ $ip =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
echo "SSC IP: $ip"
printf "\n"
else
echo "Enter a valid SSC IP address. Ex. 1.1.1.1"
exit
fi
Une fois que vous aurez fait cela, même curl
commencera à fonctionner
vagrant@vagrant:/var/www/html$ curl -s localhost/test.sh | bash
Enter SSC IP: 2.2.2.2
SSC IP: 2.2.2.2
Personnellement, je préfère l'option source <(curl -s localhost/test.sh)
. Bien que similaire à bash ...
, la différence significative réside dans la gestion des processus.
bash
entraînera la création d'un nouveau processus qui évoquera les commandes du script.source
utilisera en revanche le processus en cours pour évoquer les commandes du script.
Dans certains cas, cela peut jouer un rôle clé. J'avoue que ce n'est pas très souvent cependant.
Pour démontrer, procédez comme suit:
### Open Two Terminals
# In the first terminal run:
echo "sleep 5" > ./myTest.sh
bash ./myTest.sh
# Switch to the second terminal and run:
ps -efjh
## Repeat the same with _source_ command
# In the first terminal run:
source ./myTest.sh
# Switch to the second terminal and run:
ps -efjh
Les résultats devraient ressembler à ceci:
Avant exécution:
En cours bash
(principal + deux sous-processus):
En cours source
(principal + un sous-processus):
UPDATE:Différence d'utilisation de la variable d'utilisation entre bash
et source
:
La commande source
utilisera votre environnement actuel. Cela signifie qu'à l'exécution, toutes les modifications et déclarations de variable effectuées par le script seront disponibles dans votre invite.
bash
quant à lui se déroulera comme un processus différent; par conséquent, toutes les variables seront supprimées à la fin du processus.
Je pense que tout le monde conviendra qu'il y a des avantages et des inconvénients à chaque méthode. Vous devez simplement décider lequel convient le mieux à votre cas d'utilisation.
## Test for variables declared by the script:
echo "test_var3='Some Other Value'" > ./myTest3.sh
bash ./myTest3.sh
echo $test_var3
source ./myTest3.sh
echo $test_var3
## Test for usability of current environment variables:
test_var="Some Value" # Setting a variable
echo "echo $test_var" > myTest2.sh # Creating a test script
chmod +x ./myTest2.sh # Adding execute permission
## Executing:
. myTest2.sh
bash ./myTest2.sh
source ./myTest2.sh
./myTest2.sh
## All of the above results should print the variable.
J'espère que ça aide.