¿Cómo canalizar un documento aquí a través de un comando y capturar el resultado en una variable?

Question

Ahora esto produce el valor que necesito en stdout. ¿Cómo puedo capturarlo en una variable para poder usarlo en el resto del script?

Requisitos:

• El script necesita ser todo en un solo archivo.
• Preferiría no escribir ningún archivo temporal, si es posible.

.

#!/bin/bash 

cat << EOF | xsltproc - ../pom.xml | tail -1 
<?xml version="1.0"?> 
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> 
<xsl:template match="/"><xsl:value-of select="/project/version"/></xsl:template> 
</xsl:stylesheet> 
EOF 

Answer 1

Esto parece funcionar (según la respuesta de Ignacio). Al usar una subshell, el documento aquí se canaliza correctamente en xsltproc mientras se pasa a través de tail after.

VERSION=$((xsltproc - ../pom.xml | tail -1) << EOF 
<?xml version="1.0"?> 
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> 
<xsl:template match="/"><xsl:value-of select="/project/version"/></xsl:template> 
</xsl:stylesheet> 
EOF 
) 

Answer 2

No es necesario el cat ... |.

foo=$(sed 's/-/_/g' << EOF 
1-2 
3-4 
EOF 
) 

Answer 3

He estado jugando con heredocs por una semana o dos. He aquí un extracto de mi respuesta a Is there a way to get actual (uninterpreted) shell arguments in a function or script? en Unix Pila de Exchange que podrían ayudar a ilustrar su uso un poco para su caso:

... EXTRACTO: ...

Probablemente se dio cuenta de la diferencia entre los dos heredocs en el segundo ejemplo. El heredoc EOF terminador dentro de la función no está citado, mientras que el que se alimentó para leer está entre comillas simples. De esta forma, el intérprete de comandos recibe instrucciones para realizar una expansión en el heredoc con un terminador sin comillas, pero no para hacerlo cuando se cita su terminador. No se rompe al expandir el heredoc sin comillas en la función porque el valor de la variable que expande ya está establecido como una cadena entre comillas y no lo analiza dos veces.

Probablemente lo que quiere hacer es conectar su ruta de Windows desde la salida de un comando a la entrada de otra dinámicamente. la sustitución de comandos dentro de un heredoc lo hace posible:

% _stupid_mspath_fix() { 
> sed -e 's@\\@/@g' -e 's@\(.\):\(.*\)@/drive/\1\2@' <<_EOF_ 
>> ${1} 
>> _EOF_ 
> } 
% read -r _stupid_mspath_arg <<'_EOF_'      
> c:\some\stupid\windows\place 
> _EOF_ 
% _stupid_mspath_fix ${_stupid_mspath_arg} 
/drive/c/some/stupid/windows/place  
% read -r _second_stupid_mspath_arg <<_EOF_      
> $(printf ${_stupid_mspath_arg}) 
> _EOF_ 
% _stupid_mspath_fix ${_second_stupid_mspath_arg} 
/drive/c/some/stupid/windows/place 

Así que, básicamente, si es posible de manera fiable la salida de las barras invertidas alguna aplicación (que utilizan printf arriba), a continuación, ejecutar ese comando dentro de $ (...) y que encierra que dentro de un heredoc sin cita pasó a otra aplicación que puede aceptar confiablemente las barras diagonales inversas como entrada (como leer y sed más arriba) pasará por alto el análisis del shell de las barras diagonales inversas por completo. Ya sea que las aplicaciones puedan manejar o no las barras diagonales inversas como entrada/salida, es algo que tendrá que descubrir por sí mismo.

-Mike