Leggi i valori in una variabile shell da una pipe

Sto cercando di ottenere bash per elaborare i dati dallo stdin che viene reindirizzato, ma senza fortuna. Quello che voglio dire è nessuno dei seguenti lavori:

echo "hello world" | test=($(< /dev/stdin)); echo test=$test
test=

echo "hello world" | read test; echo test=$test
test=

echo "hello world" | test=`cat`; echo test=$test
test=

dove voglio che sia l'output test=hello world. Ho provato a mettere "" virgolette in giro "$test"che non funziona neanche.

Uso

IFS= read var << EOF
$(foo)
EOF

È possibile ingannare readad accettare da un tubo in questo modo:

echo "hello world" | { read test; echo test=$test; }

o addirittura scrivere una funzione come questa:

read_from_pipe() { read "$@" <&0; }

Ma non ha senso: le assegnazioni delle variabili potrebbero non durare! Una pipeline può generare una subshell, in cui l'ambiente è ereditato dal valore, non dal riferimento. Ecco perchéread non si preoccupa dell'input da una pipe: non è definito.

Cordiali saluti, http://www.etalabs.net/sh_tricks.html è una raccolta nifty dell'innesto necessario per combattere le stranezze e incompatibilità di bourne shell, sh.

se vuoi leggere molti dati e lavorare su ciascuna riga separatamente puoi usare qualcosa del genere:

cat myFile | while read x ; do echo $x ; done

se vuoi dividere le righe in più parole puoi usare più variabili al posto di x in questo modo:

cat myFile | while read x y ; do echo $y $x ; done

in alternativa:

while read x y ; do echo $y $x ; done < myFile

Ma non appena inizi a voler fare qualcosa di veramente intelligente con questo genere di cose, farai meglio ad usare un linguaggio di scripting come il Perl, dove potresti provare qualcosa del genere:

perl -ane 'print "$F[0]\n"' < myFile

C'è una curva di apprendimento piuttosto ripida con il perl (o immagino che una di queste lingue) ma a lungo andare sarà molto più semplice se vuoi fare altro che il più semplice degli script. Consiglierei il Perl Cookbook e, ovviamente, The Perl Programming Language di Larry Wall et al.

readnon leggerà da una pipe (o forse il risultato andrà perso perché la pipe crea una subshell). Puoi, tuttavia, usare una stringa qui in Bash:

$ read a b c <<< $(echo 1 2 3)
$ echo $a $b $c
1 2 3

Ma vedi la risposta di @ chepner per informazioni su lastpipe.

Questa è un'altra opzione

$ read test < <(echo hello world)

$ echo $test
hello world

Non sono un esperto di Bash, ma mi chiedo perché questo non sia stato proposto:

stdin=$(cat)

echo "$stdin"

Prova di una riga che funziona per me:

$ fortune | eval 'stdin=$(cat); echo "$stdin"'

bash4.2 introduce l' lastpipeopzione, che consente al codice di funzionare come scritto, eseguendo l'ultimo comando in una pipeline nella shell corrente, anziché in una shell secondaria.

shopt -s lastpipe
echo "hello world" | read test; echo test=$test

La sintassi per una pipe implicita da un comando shell in una variabile bash è

var=$(command)

o

var=`command`

Nei tuoi esempi, stai eseguendo il piping dei dati a un'istruzione di assegnazione, che non prevede alcun input.

Il primo tentativo è stato abbastanza vicino. Questa variazione dovrebbe funzionare:

echo "hello world" | { test=$(< /dev/stdin); echo "test=$test"; };

e l'output è:

test = ciao mondo

Sono necessarie parentesi graffe dopo il tubo per racchiudere il compito da testare e l'eco.

Senza le parentesi graffe, l'assegnazione da testare (dopo la pipe) è in una shell e l'eco "test = $ test" è in una shell separata che non conosce tale assegnazione. Ecco perché stavi ottenendo "test =" nell'output anziché "test = ciao mondo".

Ai miei occhi il modo migliore per leggere da stdin in bash è il seguente, che ti consente anche di lavorare sulle linee prima della fine dell'input:

while read LINE; do
    echo $LINE
done < /dev/stdin

Perché mi innamoro di questo, vorrei lasciare un messaggio. Ho trovato questo thread, perché devo riscrivere un vecchio script sh per essere compatibile con POSIX. Ciò significa sostanzialmente aggirare il problema pipe / subshell introdotto da POSIX riscrivendo il codice in questo modo:

some_command | read a b c

in:

read a b c << EOF
$(some_command)
EOF

E codice come questo:

some_command |
while read a b c; do
    # something
done

in:

while read a b c; do
    # something
done << EOF
$(some_command)
EOF

Ma quest'ultimo non si comporta allo stesso modo con input vuoti. Con la vecchia notazione il ciclo while non viene inserito su input vuoto, ma nella notazione POSIX lo è! Penso che sia dovuto alla nuova riga prima dell'EOF, che non può essere omessa. Il codice POSIX che si comporta più come la vecchia notazione è simile al seguente:

while read a b c; do
    case $a in ("") break; esac
    # something
done << EOF
$(some_command)
EOF

Nella maggior parte dei casi questo dovrebbe essere abbastanza buono. Ma sfortunatamente questo non si comporta esattamente come la vecchia notazione se some_command stampa una riga vuota. Nella vecchia notazione viene eseguito il corpo while e nella notazione POSIX ci rompiamo davanti al corpo.

Un approccio per risolvere questo problema potrebbe apparire così:

while read a b c; do
    case $a in ("something_guaranteed_not_to_be_printed_by_some_command") break; esac
    # something
done << EOF
$(some_command)
echo "something_guaranteed_not_to_be_printed_by_some_command"
EOF

Uno script intelligente in grado di leggere sia i dati da PIPE sia gli argomenti della riga di comando:

#!/bin/bash
if [[ -p /proc/self/fd/0 ]]
    then
    PIPE=$(cat -)
    echo "PIPE=$PIPE"
fi
echo "ARGS=$@"

Produzione:

$ bash test arg1 arg2
ARGS=arg1 arg2

$ echo pipe_data1 | bash test arg1 arg2
PIPE=pipe_data1
ARGS=arg1 arg2

Spiegazione: Quando uno script riceve dati tramite pipe, lo stdin / proc / self / fd / 0 sarà un collegamento simbolico a una pipe.

/proc/self/fd/0 -> pipe:[155938]

In caso contrario, punterà al terminale corrente:

/proc/self/fd/0 -> /dev/pts/5

L' [[ -popzione bash può verificare che sia pipe o no.

cat -legge il da stdin.

Se usiamo cat -quando non c'è stdin, aspetterà per sempre, ecco perché lo mettiamo nella ifcondizione.

Il piping di qualcosa in un'espressione che coinvolge un compito non si comporta così.

Invece, prova:

test=$(echo "hello world"); echo test=$test

Il seguente codice:

echo "hello world" | ( test=($(< /dev/stdin)); echo test=$test )

funzionerà anche, ma aprirà un'altra nuova shell secondaria dopo la pipe, dove

echo "hello world" | { test=($(< /dev/stdin)); echo test=$test; }

non lo faranno.

Ho dovuto disabilitare il controllo del lavoro per utilizzare il metodo chepnars (stavo eseguendo questo comando dal terminale):

set +m;shopt -s lastpipe
echo "hello world" | read test; echo test=$test
echo "hello world" | test="$(</dev/stdin)"; echo test=$test

Bash Manual dice :

lastpipe

Se impostato e il controllo del lavoro non è attivo , la shell esegue l'ultimo comando di una pipeline non eseguita in background nell'ambiente di shell corrente.

Nota: il controllo del lavoro è disattivato per impostazione predefinita in una shell non interattiva e quindi non è necessario l' set +minterno di uno script.

Penso che stavi provando a scrivere uno script di shell che potesse ricevere input dallo stdin. ma mentre lo stai provando a farlo in linea, ti sei perso cercando di creare quella variabile test =. Penso che non abbia molto senso farlo in linea, ed è per questo che non funziona come ti aspetti.

Stavo cercando di ridurre

$( ... | head -n $X | tail -n 1 )

per ottenere una riga specifica da vari input. così potrei digitare ...

cat program_file.c | line 34

quindi ho bisogno di un piccolo programma shell in grado di leggere da stdin. come fai tu.

22:14 ~ $ cat ~/bin/line 
#!/bin/sh

if [ $# -ne 1 ]; then echo enter a line number to display; exit; fi
cat | head -n $1 | tail -n 1
22:16 ~ $ 

ecco qua.

Cosa ne pensi di questo:

echo "hello world" | echo test=$(cat)