Bash est en train de supprimer des commandes pendant tout ce temps? - bash, remplace

Je ne comprends vraiment pas pourquoi cela se produit, bash semble supprimer les commandes lors de l'exécution dans un while boucle. J'ai le script suivant:

adb shell ls /foo/bar | while read file
do
folder="/foo/bar/$file"
adb pull $folder download
done

quand je lance la commande séparément, cela fonctionne très bien. Mais quand je l’utilise comme ça, j’obtiens le résultat suivant:

" does not existfoo/bar/filesdfsdf.sdf

pour chaque fichier dans / foo / bar.

Alors j'ai essayé de me donner la commande en tant que chaîne, j'ai changé pour echo "adb pull $folder download" et a obtenu la sortie suivante:

 download/foo/bar/fileasdfs.sdf

pour chaque ligne. Il semblerait que bash fasse quelque chose avec la chaîne et remplace des choses ici ... Si j'utilise ", donc pas de remplacement bash aurait lieu, je reçois la sortie correcte.

Qu'est-ce qu'il se passe ici?

EDIT: J'ai compris que non while est directement cassé, c'est la adb shell commande ce qui fait écho à un CRLF à chaque fin de ligne. si j'utilise

adb shell ls /foo/bar | tr -d "15" | while read file
do
folder="/foo/bar/$file"
adb pull $folder download
done

Ça marche! Mais pourquoi bash est-il si allergique au CRLF? Et pourquoi supprime-t-il les commandes?

Réponses:

1 pour la réponse № 1

Je ne sais pas ce que vous entendez par "Pourquoi n'autorise-t-il pas la CR?". La bonne question est "Que fait la lecture avec CR?". Sauf indication contraire, read utilise CR pour le fractionnement des paramètres. Cherchez dans votre manuel bash la variable IFS, et regardez le -d option à lire.

Exemple:

bos:$ echo foo bar gazonk | while read x ; do echo $x ; done
foo bar gazonk

Ici, le CR agit en tant que délimiteur (par défaut) pour read. Maintenant, disons que vous voulez diviser la lecture à chaque mot, alors vous utiliseriez -d " " (en définissant SPC comme délimiteur):

$ echo foo bar gazonk hello 123 | while read -d " " x ; do echo $x ; done
foo
bar
gazonk
hello

Le dos ici est que le dernier paramètre(123) n'est pas sorti car il ne se termine pas par un délimiteur. Imaginez que le délimiteur saisisse tout ce qui reste à GAUCHE, jusqu’à ce qu’il n'inclue pas le prochain délimiteur. Puisque "123" ne se termine pas par un délimiteur, le dernier délimiteur se situe entre "hello" et "123", et - donc - ce qui est saisi est "hello" car il comporte un séparateur à gauche et à droite de celui-ci.

---