Comment lire un fichier ou stdin en Bash?

En Perl, le code suivant va lire à partir du fichier spécifié sur la ligne de commande args ou à partir de stdin:

while (<>) {
   print($_);
}

C'est très pratique. Je veux juste savoir quelle est la façon la plus simple pour lire à partir du fichier ou de l'entrée standard stdin dans bash.

InformationsquelleAutor Dagang | 2011-08-08
  1. 347

    La solution suivante se lit à partir d'un fichier si le script est appelé à
    avec un nom de fichier en tant que premier paramètre $1 autrement qu'à partir de l'entrée standard. 

    while read line
do
  echo "$line"
done < "${1:-/dev/stdin}"

    La substitution ${1:-...} prend $1 si défini autrement
    le nom de fichier de l'entrée standard du processus est utilisé.

    • De Nice, il fonctionne. Une autre question est de savoir pourquoi vous ajoutez un devis pour elle? "${1:-/proc/${$}/fd/0}"
    • Le nom de fichier que vous fournissez sur la ligne de commande pourrait avoir des blancs.
    • joli et utile +1/+1
    • Quelle est la différence entre l'utilisation de /proc/$$/fd/0 et /dev/stdin? J'ai remarqué que le dernier semble être plus fréquente et semble plus simple.
    • Non seulement est /dev/stdin plus simple, c'est aussi portables (ne nécessite pas le /proc système de fichiers): < "${1:-/dev/stdin}"
    • Mieux ajouter -r à votre read de commande, de sorte qu'il n'est pas accidentellement manger \ caractères; utilisation while IFS= read -r line pour préserver attaque et de fuite des espaces.
    • Plus portable? Je reçois /dev/stdin: No such file or directory utiliser Ubuntu 14.04.3 LTS ...
    • C'est curieux, j'ai juste vérifié qu'il fonctionne sur la plate-forme, même lors de l'utilisation de /bin/sh - êtes-vous en utilisant un shell est autre que le bash ou sh?
    • cela ne fonctionne pas pour moi seulement quand mon script de lecture de /dev/stdin est alimenté par un tuyau de dans un autre script. Je reçois le No such file or directory erreur. Le script fonctionne très bien appelé en ligne de commande mais.
    • Dans une grande majorité des cas, vous devriez éviter cela. Si tout ce que vous voulez faire, c'est l'écho de l'entrée de retour à la sortie, cat le fait déjà. Très souvent, le traitement pourrait prendre place dans un script Awk et la coquille while read boucle juste complique les choses. Évidemment, il y a des situations où vous avez besoin pour traiter une ligne à la fois à partir d'un fichier dans une boucle shell, mais si vous avez juste trouvé cette réponse dans Google, vous devez être conscient que c'est une newbie antipattern.
    • Je me suis basé sur cette réponse à des informations de processus à partir de tube et ou fichier. Aussi, j'ai besoin de fusionner les choses de canalisations d'entrée (ou le fichier), alors je l'ai fait cat < "${1:-/dev/stdin}" > ${INPUT_FILE} afin de l'utiliser dans plus d'une ocassion dans le script.

    InformationsquelleAutor Fritz G. Mehner
  2. 95

    Peut-être la solution la plus simple est de rediriger l'entrée standard avec une fusion de redirection de l'opérateur:

    #!/bin/bash
less <&0

    Stdin est le fichier descripteur de zéro. Le ci-dessus envoie l'entrée de canalisation à votre script bash en moins de stdin.

    Lire plus sur le descripteur de fichier de redirection.

    • Je souhaite avoir plus de upvotes à vous donner, j'ai été à la recherche de cette années.
    • Il n'y a aucun avantage à l'utilisation <&0 dans cette situation - votre exemple de travail sera le même avec ou sans elle - apparemment, les outils vous appelez depuis un script bash par défaut, voir la même stdin que le script lui-même (sauf si le script, il consomme en premier).
    • Donc, si un outil de lit de la moitié de la mémoire tampon d'entrée, sera l'outil suivant, j'invoque le repos?
    • "Manquant de nom de fichier ("moins de --help" pour obtenir de l'aide)" quand je fais cela... Ubuntu 16.04
    • où est le "ou à partir du fichier" dans le cadre de cette réponse?
    • Juste ce dont j'avais besoin! J'ai envoyé tout CLI arguments trop: less "$@" <&0
    • Pas sûr que l'on... less -+S ; cat je ne reçois stdin les canalisations de à moins, ce qui est agréable, mais rien de cat. <&0 Semble potentiellement astuce utile si vous voulez vous assurer que certains de commande obtient les canalisations...cependant je ne sais pas dans quelle situation que ce serait utile, comme mes expériences semblent indiquer que le premier programme gets stdin et il n'a pas d'action ou de scission entre invoquée programmes.

    InformationsquelleAutor Ryan Ballantyne
  3. 64

    Ici est la façon la plus simple:

    #!/bin/sh
cat -

    Utilisation:

    $ echo test | sh my_script.sh
test

    À attribuer stdin à la variable, vous pouvez utiliser: STDIN=$(cat -) ou tout simplement STDIN=$(cat) que l'opérateur n'est pas nécessaire (comme par @mklement0 commentaire).

    À analyser chaque ligne de la entrée standard, essayez le script suivant:

    #!/bin/bash
while IFS= read -r line; do
  printf '%s\n' "$line"
done

    À lire à partir du fichier ou de stdin (si l'argument n'est pas actuellement), vous pouvez l'étendre à d':

    #!/bin/bash
file=${1-- } # POSIX-compliant; ${1:-- } can be used either.
while IFS= read -r line; do
  printf '%s\n' "$line" # Or: env POSIXLY_CORRECT=1 echo "$line"
done < <(cat -- "$file")

    Notes:

    - read -r - Ne pas traiter un caractère barre oblique inverse en quelque façon que ce soit. Considérer chaque barre oblique inverse pour faire partie de la ligne de saisie.

    - Sans réglage de IFS, par défaut, les séquences de Espace et Tab au début et à la fin de la lignes sont ignorées (garnis).

    - Utiliser printf au lieu de echo afin d'éviter l'impression des lignes vides lorsque la ligne se compose d'un seul -e, -n ou -E. Cependant, il existe une solution de contournement en utilisant env POSIXLY_CORRECT=1 echo "$line" qui exécute votre externe GNU echo qui la soutient. Voir: Comment puis-je echo "-e"?

    Voir: Comment lire stdin quand aucun argument n'est passé? à stackoverflow SE

    • Vous pouvez simplifier [ "$1" ] && FILE=$1 || FILE="-" à FILE=${1:-- }. (Chipoter: mieux vaut éviter les majuscules shell variables pour éviter les collisions de noms avec environnement variables.)
    • Mon plaisir; en fait, ${1:-- } est POSIX, donc cela devrait fonctionner dans tous les POSIX, comme des coquillages. Ce qui ne fonctionne pas dans toutes ces coquilles est un processus de substitution ( <(...) ), il va travailler dans bash, ksh, zsh, mais pas dans le tableau de bord, par exemple. Aussi, il vaut mieux ajouter -r à votre read de commande, de sorte qu'il n'est pas accidentellement manger \ caractères; ajouter IFS= pour préserver attaque et de fuite des espaces.
    • Hmm... while IFS= read -r line doit travail - ce que le shell que vous utilisez? Remarque l'espace après le =; ce que ce n'est définie $IFS à la chaîne vide pour la read commande uniquement, qui est, le mondial $IFS valeur ne change pas, ce qui est l'intention. En revanche, votre version - while IFS=; read -r line - t modifier mondiale (parce que IFS=; est séparée de la commande, pas un par commande temporaire-environnement-variable-réglage du préambule).
    • Heureux de l'entendre; et oui, le non cotées $line dans le echo commande a été le problème.
    • En fait, votre code encore des pauses à cause de echo: si une ligne est constituée de -e, -n ou -E, il ne sera pas montré. Pour résoudre ce problème, vous devez utiliser printf: printf '%s\n' "$line". Je n'ai pas l'inclure dans mon édition précédente... trop souvent mes modifications sont rollbacked quand j'ai corrigé cette erreur :(.
    • Nan ce n'est pas en panne. Et le -- est inutile si le premier argument est '%s\n'
    • Votre réponse est bien pour moi (je veux dire, il n'y a pas de bugs ou les fonctionnalités indésirables, je suis conscient de plus)—si elle ne permet pas de traiter de multiples arguments que Perl n'. En fait, si vous souhaitez gérer plusieurs arguments, vous finirez par l'écriture de Jonathan Leffler est excellente réponse—en fait le vôtre serait mieux depuis que vous souhaitez utiliser IFS= avec read et printf au lieu de echo. :).

    InformationsquelleAutor kenorb
  4. 14

    Je pense que c'est le straight-forward façon:

    $ cat reader.sh
#!/bin/bash
while read line; do
  echo "reading: ${line}"
done < /dev/stdin

    --

    $ cat writer.sh
#!/bin/bash
for i in {0..5}; do
  echo "line ${i}"
done

    --

    $ ./writer.sh | ./reader.sh
reading: line 0
reading: line 1
reading: line 2
reading: line 3
reading: line 4
reading: line 5
    • Cela ne correspond pas à l'exigence de l'affiche pour la lecture soit à partir de stdin ou un fichier en argument, ce lit depuis l'entrée standard.
    • Laissant @nash objection valable à part: read lit l'entrée standard stdin par défaut, donc pas besoin pour < /dev/stdin.
    InformationsquelleAutor Amir Mehler
  5. 13

    La echo solution consiste à ajouter de nouvelles lignes à chaque fois que IFS rompt le flux d'entrée. @mgf réponse peut être un peu modifié:

    cat "${1:-/dev/stdin}" > "${2:-/dev/stdout}"
    • Pourriez-vous nous expliquer ce que vous entendez par "echo solution consiste à ajouter de nouvelles lignes à chaque fois que FI rompt le flux d'entrée"? Dans le cas où vous faisiez référence à readcomportement: tout read t potentiellement divisé en plusieurs jetons par les chars. contenues dans $IFS, il retourne uniquement un unique jeton si vous ne spécifiez qu'un unique nom de la variable (mais les mic et de l'attaque et de fuite des espaces par défaut).
    • Je suis d'accord à 100% avec vous sur le comportement de read et $IFS - echo lui-même ajoute de nouvelles lignes sans le -n drapeau. "L'écho utilitaire écrit de toute opérandes, séparés par un espace simple (` ') caractères et suivie par un retour à la ligne (`\n') de caractères sur la sortie standard."
    • L'a obtenu. Cependant, pour émuler le Perl boucle besoin la fuite \n ajouté par echo: Perl $_ comprend la ligne fin \n à partir de la ligne de lire, alors que bash est read ne le fait pas. (Cependant, comme @gniourf_gniourf points d'ailleurs, le plus robuste approche consiste à utiliser printf '%s\n' en lieu et place de echo).
    InformationsquelleAutor David Souther
  6. 7

    Le Perl boucle dans le lit de la question de tous le nom du fichier arguments sur la ligne de commande, ou de l'entrée standard si aucun fichier n'est spécifié. Les réponses que je vois tous semblent processus d'un seul fichier ou l'entrée standard si il n'existe pas de fichier spécifié.

    Bien que souvent tourné en dérision précisément que UUOC (Inutile d'Utiliser de cat), il ya des moments où cat est le meilleur outil pour le travail, et il est permis de penser que c'est l'un d'entre eux:

    cat "$@" |
while read -r line
do
    echo "$line"
done

    Le seul inconvénient c'est qu'il crée un pipeline dans un sous-shell, donc les choses comme des assignations de variables dans le while boucle ne sont pas accessibles à l'extérieur de la canalisation. Le bash moyen de contourner cela est Processus De Substitution:

    while read -r line
do
    echo "$line"
done < <(cat "$@")

    Ce qui laisse la while boucle dans la coque principale, de sorte que les variables définies dans la boucle sont accessibles en dehors de la boucle.

    • L'Excellent point concernant plusieurs fichiers. Je ne sais pas ce que les ressources et les implications sur les performances, mais si vous n'êtes pas sur bash, ksh, ou zsh, et donc ne pouvez pas utiliser le processus de substitution, vous pouvez essayer un ici-doc avec la substitution de commande (réparties sur 3 lignes) >>EOF\n$(cat "$@")\nEOF. Enfin, un bémol: while IFS= read -r line est une meilleure approximation de ce que while (<>) n'en Perl (conserve attaque et de fuite blanc, bien que Perl garde aussi les de fuite \n).
    InformationsquelleAutor Jonathan Leffler
  7. 4

    Perl comportement, avec le code donné dans l'OP peut prendre aucune ou plusieurs arguments, et si un argument est un seul trait d'union - cela est compris comme stdin. En outre, il est toujours possible d'avoir le nom de fichier avec $ARGV.
    Aucune des réponses apportées jusqu'à présent vraiment imiter Perl comportement dans ces domaines. Voici un pur Bash possibilité. L'astuce est d'utiliser exec de façon appropriée.

    #!/bin/bash

(($#)) || set -- -
while (($#)); do
   { [[ $1 = - ]] || exec < "$1"; } &&
   while read -r; do
      printf '%s\n' "$REPLY"
   done
   shift
done

    Nom de fichier est disponible en $1.

    Si aucun argument n'est donné, nous artificiellement fixé - que le premier paramètre de position. Nous avons ensuite une boucle sur les paramètres. Si un paramètre n'est pas -, nous rediriger l'entrée standard de nom de fichier avec exec. Si cette redirection réussit, nous boucle avec un while boucle. Je suis l'aide de la norme REPLY variable, et dans ce cas, vous n'avez pas besoin de réinitialiser IFS. Si vous voulez un autre nom, vous devez réinitialiser IFS comme (à moins, bien sûr, vous ne voulez pas que et savez ce que vous faites):

    while IFS= read -r line; do
    printf '%s\n' "$line"
done
    InformationsquelleAutor gniourf_gniourf
  8. 2

    Avec plus de précision...

    while IFS= read -r line ; do
    printf "%s\n" "$line"
done < file
    • Je suppose que c'est essentiellement un commentaire sur stackoverflow.com/a/6980232/45375, pas de réponse. Pour faire le commentaire explicite: l'ajout de IFS= et -r à la read de commande fait en sorte que chaque ligne est en lecture non modifié (y compris l'attaque et de fuite des espaces).
    InformationsquelleAutor Sorpigal
  9. 2

    S'il vous plaît essayer le code suivant:

    while IFS= read -r line; do
    echo "$line"
done < file
    • Notez que, même modifiée, ce ne sera pas lire à partir de l'entrée standard, ou à partir de plusieurs fichiers, donc ce n'est pas une réponse complète à la question. (Il est également surprenant de voir deux modifications dans une affaire de minutes de plus que 3 ans après la réponse a d'abord été soumis.)
    • désolé pour l'édition d'une ancienne (et vraiment pas la bonne) réponse... mais je ne pouvais pas supporter de voir ce pauvre read sans IFS= et -r, et les pauvres $line sans ses citations.
    • Je n'aime pas le read -r notation. OMI, POSIX se trompe; l'option devrait permettre à la signification spéciale pour la fuite des barres obliques inverses, ne désactivez pas, de sorte que les scripts existants (avant POSIX existé) n'aurait pas à se casser à cause de la -r a été omis. J'observe, cependant, que c'était une partie de l'IEEE 1003.2 1992, qui a été la première version du shell POSIX et les utilitaires standard, mais il a été marqué comme une outre, même alors, donc, c'est de râler sur le long-gone possibilités. Je n'ai jamais couru dans le pétrin parce que mon code n'utilisez pas -r; je dois avoir de la chance. Ignorez-moi.
    • J'ai vraiment d'accord que -r devrait être la norme. Je suis d'accord qu'il est peu probable d'être dans les cas où il n'utilise pas conduit à des problèmes. Bien que, de code cassé est cassé le code. Mon montage a été déclenchée pour la première fois par cette pauvre $line variable qui a gravement manqué à ses citations. J'ai corrigé le read alors que j'étais à elle. Je n'ai pas corrigé le echo parce que c'est le genre de montage qui obtient annulée. :(.
    InformationsquelleAutor Webthusiast
  10. 1

    Code ${1:-/dev/stdin} aurez simplement à comprendre au premier argument, donc, comment à ce sujet.

    ARGS='$*'
if [ -z "$*" ]; then
  ARGS='-'
fi
eval "cat -- $ARGS" | while read line
do
   echo "$line"
done
    InformationsquelleAutor Takahiro Onodera
  11. 1

    Je ne trouve pas l'une de ces réponses acceptables. En particulier, l'on a accepté la réponse ne gère que le premier paramètre de ligne de commande et ignore le reste. Le programme en Perl que c'est en essayant d'imiter gère tous les paramètres de ligne de commande. Si l'on a accepté la réponse n'a même pas de répondre à la question. D'autres réponses utilisez bash extensions, ajouter inutiles "chat", les commandes, ne fonctionne que pour le cas simple d'écho à l'entrée à la sortie, ou sont tout simplement inutilement compliqué.

    Cependant, je dois leur donner un peu de crédit, car ils m'ont donné quelques idées. Voici la réponse:

    #!/bin/sh

if [ $# = 0 ]
then
        DEFAULT_INPUT_FILE=/dev/stdin
else
        DEFAULT_INPUT_FILE=
fi

# Iterates over all parameters or /dev/stdin
for FILE in "$@" $DEFAULT_INPUT_FILE
do
        while IFS= read -r LINE
        do
                # Do whatever you want with LINE here.
                echo $LINE
        done < "$FILE"
done
    InformationsquelleAutor Gungwald
  12. 0

    Les œuvres suivantes de la norme sh (Testé avec dash sur Debian) et est tout à fait lisible, mais c'est une question de goût:

    if [ -n "$1" ]; then
    cat "$1"
else
    cat
fi | commands_and_transformations

    De détails: Si le premier paramètre est non-vide, alors cat ce fichier, d'autre cat l'entrée standard. Alors la sortie de l'ensemble de la if instruction est traitée par le commands_and_transformations.

    • À mon humble avis la meilleure réponse, car il pointe à la vraie solution: cat "${1:-- }" | any_command. La lecture de variables shell et en écho à eux peuvent travailler pour de petits fichiers, mais ne l'est pas si bien.
    • Le [ -n "$1" ] peut être simplifié à [ "$1" ].
    InformationsquelleAutor Notinlist
  13. 0

    J'ai cumulé toutes les réponses ci-dessus, et a créé une fonction shell qui répondrait à mes besoins. C'est à partir d'un terminal cygwin de mes 2 Windows10 machines où j'ai eu un dossier partagé entre eux. J'ai besoin d'être en mesure de gérer les suivantes:

    • cat file.cpp | tx
    • tx < file.cpp
    • tx file.cpp

    Où un nom de fichier est spécifié, j'ai besoin d'utilisé le même nom de fichier lors de la copie. Où les flux de données d'entrée a été canalisée par, alors j'ai besoin de générer un nom de fichier temporaire ayant les heures, minutes et secondes. L'partagé mainfolder a des sous-dossiers de la les jours de la semaine. C'est pour des raisons d'organisation.

    Voici, l'ultime script pour mes besoins:

    tx ()
{
  if [ $# -eq 0 ]; then
    local TMP=/tmp/tx.$(date +'%H%M%S')
    while IFS= read -r line; do
        echo "$line"
    done < /dev/stdin > $TMP
    cp $TMP //$OTHER/stargate/$(date +'%a')/
    rm -f $TMP
  else
    [ -r $1 ] && cp $1 //$OTHER/stargate/$(date +'%a')/ || echo "cannot read file"
  fi
}

    Si il n'y a aucun moyen que vous pouvez voir à optimiser ce, je voudrais savoir.

    InformationsquelleAutor typelogic
  14. -1

    Comment sur

    for line in `cat`; do
    something($line);
done
    • S'il vous plaît ajouter quelques détails au sujet de votre code.
    • La sortie de cat sera placé dans la ligne de commande. La ligne de commande a une taille maximale. Aussi ce ne sera pas le lire ligne par ligne, mais mot par mot.
    InformationsquelleAutor Charles Cooper