Je suppose que cela devrait fonctionner en bash :
source <(curl -s https://example.com/script.sh)o
bash <(curl -s https://example.com/script.sh)o
curl -s https://example.com/script.sh | source /dev/stdinMais ça ne marche pas pour moi. Télécharger vers un fichier, sourcer le fichier et ensuite supprimer le fichier fait travail. Je suis curieux de savoir pourquoi aucun des one liners ne fonctionne.
Vous avez raison de dire que vos deux premières lettres de rappel devrait fonctionne selon bash sémantique de la substitution de processus . Sur mon tests ( bash 3.2 sur OS X 10.8.2), la seconde le fait, alors que la première ne le fait pas.
Dans le cas de votre première phrase, il semble que vous vous heurtiez à l'une des limites de la substitution de processus. En citant le Page Wikipedia sur la substitution de processus :
La substitution de processus présente certaines limites : les "fichiers" créés ne sont pas consultables, ce qui signifie que le processus qui lit ou écrit dans le fichier ne peut pas effectuer d'accès aléatoire ; il doit lire ou écrire une fois du début à la fin. Les programmes qui vérifient explicitement le type d'un fichier avant de l'ouvrir peuvent refuser de fonctionner avec la substitution de processus, car le "fichier" résultant de la substitution de processus n'est pas un fichier ordinaire.
- si source est une commande qui présente des difficultés à cet égard (du moins en bash 3.2), ce qui expliquerait son incapacité à fonctionner avec la substitution de processus.
La deuxième ligne semble échouer parce qu'elle exécute le code dans un sous-shell au lieu d'en faire la source. Si vous vous attendez à ce qu'il définisse des alias et des fonctions, cela ne fonctionnera pas, car ceux-ci ne sont pas reportés dans le shell parent lorsqu'ils sont définis dans un sous-shell.
La troisième ligne ne fonctionne pas parce que source ne traite pas stdin - uniquement des fichiers (voir page de manuel de bash ).
Eh bien, cela fonctionne bien pour moi (au moins la deuxième), donc je soupçonne que quelque chose d'autre ne va pas pour le demandeur.
@patrix Oui, c'est difficile à diagnostiquer sans savoir ce que le fichier source est censé faire. À en juger par les fils de commentaires, il est destiné à configurer des alias et des fonctions de complétion, qui ne seront pas transférés d'un sous-shell, bien sûr. J'ai modifié ma formulation pour refléter cela.
Je doute que ce soit parce que la substitution de processus ne fonctionne pas, étant donné la réponse acceptée ici : superuser.com/questions/255260/bash-source-from-url
Je ne sais pas ce que vous aimez faire mais si vous aimez télécharger un script (ou autre), utilisez.
curl -s -L https://example.com/script.sh -o script.shpour plus de détails, voir
man curl dans le terminal. -s silencieux, -L emplacement de la cible, y compris la redirection vers une nouvelle cible, -o fichier de sortie, si vous ne l'utilisez pas alors curl utilise le nom du fichier sur la cible (-o est souvent très utile).
Pour exécuter le script utilisez
./script.sh
Tant que vous ne répondrez pas à la question de savoir ce que vous avez fait et ce que vous aimez faire, personne ne pourra y répondre. L'avez-vous téléchargé ? Avez-vous obtenu une erreur de curl ? Si vous avez téléchargé le script comme décrit ci-dessus, rendez-le exécutable en utilisant chmode +x FILENAME et copiez-le quelque part dans votre PATH sudo mv FILENAME /usr/local/bin puis vous pouvez l'exécuter dans le terminal. Ou que voulez-vous dire ?
@nawi-at-mac La beauté des <() La construction est que vous n'avez pas besoin de créer un fichier temporaire manuellement, donc je comprends pourquoi le demandeur veut l'utiliser. Mais sans informations supplémentaires sur l'erreur/la défaillance spécifique, il sera difficile de répondre à la question.
LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.
1 votes
Comment ça, ça ne marche pas ? Essayez-vous d'exécuter ceci dans un bash script ou ?
0 votes
Obtenez-vous un message d'erreur quelconque ?
0 votes
Je veux le mettre dans mon ~/.bashrc, j'ai essayé de l'exécuter à une invite bash aussi. Aucun message d'erreur. Seulement les alias qu'il contient ne sont pas disponibles, la complétion bash des noms d'hôtes SSH qu'il configure ne fonctionne pas, etc.
0 votes
Bien sûr, il n'y a pas de message d'erreur, car le programme
-sLe commutateur metcurlen mode silencieux. Essayez de le faire fonctionner avec le-sSà la place et voyez quel message d'échec vous obtenez.0 votes
Il n'y a pas de problème avec la boucle. Comme dans le post original, un téléchargement séparé en trois lignes, la source et ensuite la suppression du fichier temporaire fonctionne.
0 votes
Ouais, c'est ma faute, désolé de ne pas avoir lu le post assez attentivement. En fait, le problème semble être le fait
sourcene lit que dans fichiers pas à partir de stdin - selon la page de manuel de bash, c'est-à-dire.0 votes
La construction <() utilise un fichier spécial ; /dev/fd/63.
0 votes
Ce n'est pas un fichier ordinaire, c'est un descripteur de fichier, comme stdin, stderr et stdout. Vous ne pouvez pas l'utiliser directement à la place d'un fichier car vous êtes tuyauterie son contenu dans
sourceet non en le transmettant comme un fichier. Essayez d'utiliser un fichier temporaire créé avecmktemp(qui est disponible sur OS X et atténue les problèmes de sécurité lors de l'exécution de code à partir d'un fichier qui n'est pas sous votre contrôle ; de plus, vous pouvez et devriez laisser le nettoyage à la purge du système d'exploitation de l'application/tmp).0 votes
Sûrement que la première ligne est en le transmettant comme un fichier, et non en le faisant passer par un tuyau ?
0 votes
Hmm, en lisant sur la substitution de processus, oui, il semble que c'est ce qui devrait se produire - il semble que je me trompe. La seule chose à laquelle je peux penser est que vous rencontrez un problème de retard asynchrone, car la substitution de processus place son travail en arrière-plan.
0 votes
Pour ma défense, Même le TLDP est confus quand il s'agit de la sémantique de la substitution de processus. . Après avoir parcouru Stack Overflow, il semble que je pourrais avoir accidentellement à moitié raison : certains programmes ne gèrent apparemment pas bien le fait que le "fichier" qui leur est transmis est un descripteur de fichier ou un tube nommé. (l'implémentation sous-jacente dépend du système d'exploitation).
sourcepourrait être l'un d'entre eux.