web-dev-qa-db-fra.com

"/ dev / fd / 63 Aucun fichier ou répertoire de ce type"

J'ai essayé d'exécuter une commande dans chroot (assez nouveau pour cela), et j'obtiens la sortie suivante.

root@hostname:~ # bash <(wget -q0 https://raw.githubusercontent.com/ubports/unity8-desktop-install-tools/master/install.sh) 
bash: /dev/fd/63: No such file or directory root
2
Radu

TL; DR: copiez le dossier /root hors chroot dans le répertoire chroot

L'opérateur <(...) est appelé substitution de processus et constitue un moyen d'exécuter une commande dont la sortie passe dans un canal anonyme. C'est ce que/dev/fd/63 est. L'idée est de permettre à une commande externe (ici bash) de traiter une autre sortie de commande comme s'il s'agissait d'un fichier. Généralement, la forme serait d'utiliser < pour rediriger cet objet de pseudo-fichier dans le flux d'entrée de bash.

bash < <(wget -q0 https://raw.githubusercontent.com/ubports/unity8-desktop-install-tools/master/install.sh)

Ce n'est généralement pas différent de wget https://stuff.com/blah | bash. Dans les deux cas, il est généralement déconseillé d'utiliser ces commandes, sauf si vous êtes sûr à cent pour cent que le script que vous téléchargez ne provient pas d'une source fragmentaire et n'est pas un logiciel malveillant.

Cependant, puisque vous avez mentionné l'exécution de la commande dans chroot et que le script génère No such file or directory root, et parce que bash permet l'exécution de scripts en tant que bash script.sh, votre script est en cours d'exécution, mais il n'y a pas de répertoire nommé root dans votre chroot. Vous pouvez simplement le réparer via Sudo cp -R /root chrootdir. Pour obtenir de meilleurs résultats, je vous suggèrerais de commencer par lire le script, voir ce dont il a besoin, et le copier dans le dossier chroot, puis seulement exécuter le script localement dans le dossier. Pas besoin d'exécuter wget plusieurs fois

Donc, le script fonctionne. Erreurs dans les scripts de shell généralement sous la forme <Shell>: <command user typed>: error message alors le script étant temporairement stocké sous le nom/dev/fd/63 et exécuté, il ne trouve tout simplement pas ce dont il a besoin.

Voir également,

0