Dividir la cadena en una matriz en Bash

En un script Bash, me gustaría dividir una línea en pedazos y almacenarlos en una matriz.

La línea:

Paris, France, Europe

Me gustaría tenerlos en una matriz como esta:

array[0] = Paris
array[1] = France
array[2] = Europe

Me gustaría usar un código simple, la velocidad del comando no importa. ¿Cómo puedo hacerlo?

IFS=', ' read -r -a array <<< "$string"

Tenga en cuenta que los personajes $IFSson tratados de forma individual como separadores de manera que en este caso los campos se pueden separar por cualquiera una coma o un espacio en lugar de la secuencia de los dos caracteres. Curiosamente, sin embargo, los campos vacíos no se crean cuando el espacio de coma aparece en la entrada porque el espacio se trata especialmente.

Para acceder a un elemento individual:

echo "${array[0]}"

Para iterar sobre los elementos:

for element in "${array[@]}"
do
    echo "$element"
done

Para obtener tanto el índice como el valor:

for index in "${!array[@]}"
do
    echo "$index ${array[index]}"
done

El último ejemplo es útil porque las matrices de Bash son escasas. En otras palabras, puede eliminar un elemento o agregar un elemento y luego los índices no son contiguos.

unset "array[1]"
array[42]=Earth

Para obtener el número de elementos en una matriz:

echo "${#array[@]}"

Como se mencionó anteriormente, las matrices pueden ser dispersas, por lo que no debe usar la longitud para obtener el último elemento. Así es como puedes hacerlo en Bash 4.2 y versiones posteriores:

echo "${array[-1]}"

en cualquier versión de Bash (desde algún lugar después de 2.05b):

echo "${array[@]: -1:1}"

Las compensaciones negativas más grandes se seleccionan más lejos del final de la matriz. Tenga en cuenta el espacio antes del signo menos en la forma anterior. Es requerido.

Todas las respuestas a esta pregunta son incorrectas de una forma u otra.

Respuesta incorrecta # 1

IFS=', ' read -r -a array <<< "$string"

1: Esto es un mal uso de $IFS. El valor de la $IFSvariable no se toma como un único separador de cadena de longitud variable , sino que se toma como un conjunto de separadores de cadena de un solo carácter , donde cada campo que readse separa de la línea de entrada puede ser terminado por cualquier carácter en el conjunto (coma o espacio, en este ejemplo).

En realidad, para los fanáticos reales, el significado completo de $IFSes un poco más complicado. Del manual de bash :

El shell trata cada carácter de IFS como un delimitador, y divide los resultados de las otras expansiones en palabras usando estos caracteres como terminadores de campo. Si IFS no está configurado, o su valor es exactamente <space><tab> <newline> , el valor predeterminado, entonces las secuencias de <space> , <tab> y <newline> al principio y al final de los resultados de las expansiones anteriores se ignoran, y cualquier secuencia de caracteres IFS que no se encuentre al principio o al final sirve para delimitar palabras. Si IFS tiene un valor diferente al predeterminado, entonces las secuencias de los caracteres de espacio en blanco <space> , <tab> y <se ignoran al principio y al final de la palabra, siempre que el carácter de espacio en blanco esté en el valor de IFS (un carácter de espacio en blanco de IFS ). Cualquier carácter en IFS que no sea espacio en blanco IFS , junto con cualquier carácter de espacio en blanco IFS adyacente , delimita un campo. Una secuencia de caracteres de espacio en blanco IFS también se trata como un delimitador. Si el valor de IFS es nulo, no se divide la palabra.

Básicamente, para valores no predeterminados no nulos de $IFS, los campos se pueden separar con (1) una secuencia de uno o más caracteres que pertenecen al conjunto de "caracteres de espacio en blanco IFS" (es decir, cualquiera de <space> , <tab> y <newline> ("nueva línea", que significa avance de línea (LF) ) están presentes en cualquier lugar $IFS), o (2) cualquier carácter de "espacio en blanco IFS" que esté presente en$IFS junto con los "caracteres de espacio en blanco IFS" que lo rodean en la línea de entrada.

Para el OP, es posible que el segundo modo de separación que describí en el párrafo anterior sea exactamente lo que quiere para su cadena de entrada, pero podemos estar bastante seguros de que el primer modo de separación que describí no es correcto en absoluto. Por ejemplo, ¿qué pasa si su cadena de entrada era 'Los Angeles, United States, North America'?

IFS=', ' read -ra a <<<'Los Angeles, United States, North America'; declare -p a;
## declare -a a=([0]="Los" [1]="Angeles" [2]="United" [3]="States" [4]="North" [5]="America")

2: Incluso si usted fuera a utilizar esta solución con un separador de un solo carácter (como una coma por sí mismo, es decir, sin espacio siguiente u otro equipaje), si el valor de la $stringvariable de pasa para contener cualquier LF, a continuación, readse deje de procesar una vez que encuentre el primer LF. El readbuiltin solo procesa una línea por invocación. Esto es cierto incluso si está canalizando o redirigiendo la entrada solo a la readdeclaración, como lo estamos haciendo en este ejemplo con el mecanismo here-string , y por lo tanto se garantiza que la entrada no procesada se perderá. El código que impulsa el readincorporado no tiene conocimiento del flujo de datos dentro de su estructura de comando que contiene.

Podría argumentar que es poco probable que esto cause un problema, pero aún así, es un peligro sutil que debe evitarse si es posible. Es causada por el hecho de que la readconstrucción en realidad hace dos niveles de división de entrada: primero en líneas, luego en campos. Dado que el OP solo quiere un nivel de división, este uso del readbuiltin no es apropiado, y debemos evitarlo.

3: Un problema potencial no obvio con esta solución es que readsiempre elimina el campo final si está vacío, aunque de lo contrario conserva los campos vacíos. Aquí hay una demostración:

string=', , a, , b, c, , , '; IFS=', ' read -ra a <<<"$string"; declare -p a;
## declare -a a=([0]="" [1]="" [2]="a" [3]="" [4]="b" [5]="c" [6]="" [7]="")

Tal vez el OP no se preocuparía por esto, pero sigue siendo una limitación que vale la pena conocer. Reduce la robustez y generalidad de la solución.

Este problema se puede resolver agregando un delimitador final falso a la cadena de entrada justo antes de alimentarlo read, como demostraré más adelante.

Respuesta incorrecta # 2

string="1:2:3:4:5"
set -f                     # avoid globbing (expansion of *).
array=(${string//:/ })

Idea similar:

t="one,two,three"
a=($(echo $t | tr ',' "\n"))

(Nota: agregué los paréntesis faltantes alrededor de la sustitución del comando que el respondedor parece haber omitido).

Idea similar:

string="1,2,3,4"
array=(`echo $string | sed 's/,/\n/g'`)

Estas soluciones aprovechan la división de palabras en una asignación de matriz para dividir la cadena en campos. Curiosamente, al igual readque la división de palabras general también utiliza la $IFSvariable especial, aunque en este caso se da a entender que se establece en su valor predeterminado de <space><tab> <newline> y, por lo tanto, cualquier secuencia de uno o más IFS los caracteres (que ahora son todos espacios en blanco) se consideran un delimitador de campo.

Esto resuelve el problema de dos niveles de división cometidos por read, ya que la división de palabras por sí misma constituye solo un nivel de división. Pero al igual que antes, el problema aquí es que los campos individuales en la cadena de entrada ya pueden contener $IFScaracteres y, por lo tanto, se dividirían incorrectamente durante la operación de división de palabras. Este no es el caso para ninguna de las cadenas de entrada de muestra proporcionadas por estos respondedores (qué conveniente ...), pero por supuesto eso no cambia el hecho de que cualquier base de código que usara este idioma correría el riesgo de explotar si alguna vez se viola esta suposición en algún momento. Una vez más, considere mi contraejemplo de 'Los Angeles, United States, North America'(o 'Los Angeles:United States:North America').

También, la división de palabras es normalmente seguido por la expansión de nombre de archivo ( aka expansión nombre de ruta aka globbing), que, si se hace, se palabras potencialmente corruptos que contienen los caracteres *, ?o [seguido de ](y, si extglobse establece, los fragmentos entre paréntesis precedido de ?, *, +, @, o !) al compararlos con objetos del sistema de archivos y expandir las palabras ("globos") en consecuencia. El primero de estos tres respondedores ha socavado hábilmente este problema al ejecutar de set -fantemano para desactivar el bloqueo. Técnicamente esto funciona (aunque probablemente debería agregarset +f luego para volver a habilitar el globbing para el código posterior que puede depender de él), pero no es deseable tener que meterse con la configuración global del shell para hackear una operación básica de análisis de cadena a matriz en código local.

Otro problema con esta respuesta es que todos los campos vacíos se perderán. Esto puede o no ser un problema, dependiendo de la aplicación.

Nota: Si va a usar esta solución, es mejor usar la forma de ${string//:/ }"sustitución de patrón" de expansión de parámetros , en lugar de tener que molestarse en invocar una sustitución de comando (que bifurca el shell), iniciar una canalización y ejecutando un ejecutable externo ( tro sed), ya que la expansión de parámetros es puramente una operación interna del shell. (Además, para las soluciones try sed, la variable de entrada debe estar entre comillas dobles dentro de la sustitución del comando; de lo contrario, la división de palabras tendría efecto en el echocomando y potencialmente alteraría los valores del campo. Además, la $(...)forma de sustitución del comando es preferible a la anterior`...` formulario ya que simplifica el anidamiento de las sustituciones de comandos y permite un mejor resaltado de sintaxis por parte de los editores de texto).

Respuesta incorrecta # 3

str="a, b, c, d"  # assuming there is a space after ',' as in Q
arr=(${str//,/})  # delete all occurrences of ','

Esta respuesta es casi la misma que la n . ° 2 . La diferencia es que el respondedor ha asumido que los campos están delimitados por dos caracteres, uno de los cuales está representado por defecto $IFSy el otro no. Ha resuelto este caso bastante específico eliminando el carácter no representado por IFS utilizando una expansión de sustitución de patrón y luego utilizando la división de palabras para dividir los campos en el carácter delimitador representado por IFS sobreviviente.

Esta no es una solución muy genérica. Además, se puede argumentar que la coma es realmente el carácter delimitador "primario" aquí, y que eliminarlo y luego, dependiendo del carácter de espacio para la división de campo, es simplemente incorrecto. Una vez más, tenga en cuenta mis contraejemplo: 'Los Angeles, United States, North America'.

Además, una vez más, la expansión del nombre de archivo podría corromper las palabras expandidas, pero esto se puede evitar deshabilitando temporalmente la asignación con set -fy luego set +f.

Además, nuevamente, se perderán todos los campos vacíos, lo que puede o no ser un problema dependiendo de la aplicación.

Respuesta incorrecta # 4

string='first line
second line
third line'

oldIFS="$IFS"
IFS='
'
IFS=${IFS:0:1} # this is useful to format your code with tabs
lines=( $string )
IFS="$oldIFS"

Esto es similar a # 2 y # 3 en que usa la división de palabras para hacer el trabajo, solo que ahora el código se establece explícitamente $IFSpara contener solo el delimitador de campo de un solo carácter presente en la cadena de entrada. Debe repetirse que esto no puede funcionar para delimitadores de campo de caracteres múltiples, como el delimitador de espacio de coma del OP. Pero para un delimitador de un solo carácter como el LF utilizado en este ejemplo, en realidad se acerca a ser perfecto. Los campos no se pueden dividir involuntariamente en el medio como vimos con respuestas incorrectas anteriores, y solo hay un nivel de división, según sea necesario.

Un problema es que la expansión del nombre de archivo corromperá las palabras afectadas como se describió anteriormente, aunque una vez más, esto se puede resolver envolviendo la declaración crítica en set -fy set +f.

Otro problema potencial es que, dado que LF califica como un "carácter de espacio en blanco IFS" como se definió anteriormente, todos los campos vacíos se perderán, al igual que en # 2 y # 3 . Por supuesto, esto no sería un problema si el delimitador no es un "carácter de espacio en blanco IFS" y, dependiendo de la aplicación, puede no importar de todos modos, pero sí vicia la generalidad de la solución.

En resumen, suponiendo que tiene un delimitador de un carácter y que no es un "carácter de espacio en blanco IFS" o que no le interesan los campos vacíos y ajusta la declaración crítica set -fy set +f, entonces, esta solución funciona , pero por lo demás no.

(Además, por el bien de la información, la asignación de un LF a una variable en bash se puede hacer más fácilmente con la $'...'sintaxis, por ejemplo IFS=$'\n';).

Respuesta incorrecta # 5

countries='Paris, France, Europe'
OIFS="$IFS"
IFS=', ' array=($countries)
IFS="$OIFS"

Idea similar:

IFS=', ' eval 'array=($string)'

Esta solución es efectivamente un cruce entre el n . ° 1 (en que se establece $IFSen espacio de coma) y el n . ° 2-4 (en que usa la división de palabras para dividir la cadena en campos). Debido a esto, sufre la mayoría de los problemas que afectan a todas las respuestas incorrectas anteriores, algo así como el peor de todos los mundos.

Además, con respecto a la segunda variante, puede parecer que la evalllamada es completamente innecesaria, ya que su argumento es un literal de cadena entre comillas simples y, por lo tanto, es estáticamente conocido. Pero en realidad hay un beneficio muy obvio de usar evalde esta manera. Normalmente, cuando se ejecuta un comando simple que consiste en una asignación de variable única , es decir, sin una palabra de comando real que le sigue, la asignación tiene efecto en el entorno de shell:

IFS=', '; ## changes $IFS in the shell environment

Esto es cierto incluso si el comando simple involucra múltiples asignaciones de variables; de nuevo, siempre que no haya una palabra de comando, todas las asignaciones de variables afectan el entorno del shell:

IFS=', ' array=($countries); ## changes both $IFS and $array in the shell environment

Pero, si la asignación de variables se adjunta a un nombre de comando (me gusta llamar a esto una "asignación de prefijo"), entonces no afecta el entorno de shell y, en cambio, solo afecta el entorno del comando ejecutado, independientemente de si es una función incorporada o externo:

IFS=', ' :; ## : is a builtin command, the $IFS assignment does not outlive it
IFS=', ' env; ## env is an external command, the $IFS assignment does not outlive it

Cita relevante del manual de bash :

Si no se obtiene un nombre de comando, las asignaciones de variables afectan el entorno actual del shell. De lo contrario, las variables se agregan al entorno del comando ejecutado y no afectan el entorno actual del shell.

Es posible explotar esta característica de asignación de variables para cambiar $IFSsolo temporalmente, lo que nos permite evitar todo el gambito de guardar y restaurar como el que se está haciendo con la $OIFSvariable en la primera variante. Pero el desafío que enfrentamos aquí es que el comando que necesitamos ejecutar es en sí mismo una mera asignación de variables, y por lo tanto no implicaría una palabra de comando para hacer que la $IFSasignación sea temporal. Podrías pensar para ti mismo, bueno, ¿por qué no simplemente agregar una palabra de comando no-op a la declaración como : builtinpara hacer que la $IFSasignación sea temporal? Esto no funciona porque luego también haría que la $arrayasignación sea temporal:

IFS=', ' array=($countries) :; ## fails; new $array value never escapes the : command

Por lo tanto, estamos efectivamente en un punto muerto, un poco atrapados. Pero, cuando evalejecuta su código, lo ejecuta en el entorno de shell, como si fuera normal, código fuente estático, y por lo tanto podemos ejecutar la $arrayasignación dentro del evalargumento para que tenga efecto en el entorno de shell, mientras que la $IFSasignación de prefijo que está prefijado al evalcomando no sobrevivirá al evalcomando. Este es exactamente el truco que se está utilizando en la segunda variante de esta solución:

IFS=', ' eval 'array=($string)'; ## $IFS does not outlive the eval command, but $array does

Entonces, como puede ver, en realidad es un truco bastante inteligente, y logra exactamente lo que se requiere (al menos con respecto a la afectación de la asignación) de una manera bastante obvia. En realidad no estoy en contra de este truco en general, a pesar de la participación de eval; solo tenga cuidado de comillas simples la cadena de argumentos para protegerse contra las amenazas de seguridad.

Pero de nuevo, debido a la aglomeración de problemas "lo peor de todos los mundos", esta sigue siendo una respuesta incorrecta a los requisitos del OP.

Respuesta incorrecta # 6

IFS=', '; array=(Paris, France, Europe)

IFS=' ';declare -a array=(Paris France Europe)

¿Um que? El OP tiene una variable de cadena que debe analizarse en una matriz. Esta "respuesta" comienza con el contenido literal de la cadena de entrada pegada en un literal de matriz. Supongo que es una forma de hacerlo.

Parece que el respondedor puede haber asumido que la $IFSvariable afecta a todos los análisis de bash en todos los contextos, lo cual no es cierto. Del manual de bash:

IFS     El separador de campo interno que se usa para dividir palabras después de la expansión y para dividir líneas en palabras con el comando de lectura incorporado. El valor predeterminado es <space><tab> <newline> .

Por lo tanto, la $IFSvariable especial en realidad solo se usa en dos contextos: (1) división de palabras que se realiza después de la expansión (es decir, no al analizar el código fuente de bash) y (2) para dividir las líneas de entrada en palabras por el readincorporado.

Déjame intentar aclarar esto. Creo que podría ser bueno hacer una distinción entre análisis y ejecución . Bash primero debe analizar el código fuente, que obviamente es un evento de análisis , y luego ejecuta el código, que es cuando la expansión entra en escena. La expansión es realmente un evento de ejecución . Además, discrepo con la descripción de la $IFSvariable que acabo de citar arriba; en lugar de decir que la división de palabras se realiza después de la expansión , yo diría que la división de palabras se realiza durante la expansión o, quizás más precisamente, la división de palabras es parte deEl proceso de expansión. La frase "división de palabras" se refiere solo a este paso de expansión; nunca debería usarse para referirse al análisis del código fuente de bash, aunque desafortunadamente los documentos parecen arrojar muchas veces las palabras "dividir" y "palabras". Aquí hay un extracto relevante de la versión linux.die.net del manual bash:

La expansión se realiza en la línea de comando después de que se ha dividido en palabras. Hay siete tipos de expansión lleva a cabo: la expansión de llaves , de tilde de expansión , los parámetros y la expansión de variables , sustitución de orden , expansión aritmética , la división de palabras , y la expansión de nombre de camino .

El orden de las expansiones es: expansión de llaves; expansión de tilde, expansión de parámetros y variables, expansión aritmética y sustitución de comandos (hecho de izquierda a derecha); división de palabras; y expansión de nombre de ruta.

Podría argumentar que la versión GNU del manual funciona un poco mejor, ya que opta por la palabra "tokens" en lugar de "palabras" en la primera oración de la sección Expansión:

La expansión se realiza en la línea de comando después de que se haya dividido en tokens.

El punto importante es $IFSque no cambia la forma en que bash analiza el código fuente. El análisis del código fuente de bash es en realidad un proceso muy complejo que implica el reconocimiento de los diversos elementos de la gramática de shell, como secuencias de comandos, listas de comandos, tuberías, expansiones de parámetros, sustituciones aritméticas y sustituciones de comandos. En su mayor parte, el proceso de análisis de bash no puede ser alterado por acciones a nivel de usuario como asignaciones de variables (en realidad, hay algunas excepciones menores a esta regla; por ejemplo, vea las diversas compatxxconfiguraciones de shell, que puede cambiar ciertos aspectos del comportamiento de análisis sobre la marcha). Las "palabras" / "tokens" ascendentes que resultan de este complejo proceso de análisis se expanden de acuerdo con el proceso general de "expansión" tal como se desglosa en los extractos de documentación anteriores, donde la división de palabras del texto expandido (¿expansivo?) En aguas abajo palabras es simplemente un paso de ese proceso. La división de palabras solo toca el texto que se ha escupido de un paso de expansión anterior; no afecta el texto literal que fue analizado directamente desde la fuente por testream.

Respuesta incorrecta # 7

string='first line
        second line
        third line'

while read -r line; do lines+=("$line"); done <<<"$string"

Esta es una de las mejores soluciones. Tenga en cuenta que hemos vuelto a usar read. ¿No dije antes que eso reades inapropiado porque realiza dos niveles de división, cuando solo necesitamos uno? El truco aquí es que puede llamar readde tal manera que efectivamente solo hace un nivel de división, específicamente al dividir solo un campo por invocación, lo que requiere el costo de tener que llamarlo repetidamente en un bucle. Es un juego de manos, pero funciona.

Pero hay problemas. Primero: cuando proporciona al menos un argumento NAME para read, ignora automáticamente los espacios en blanco iniciales y finales en cada campo que se separa de la cadena de entrada. Esto ocurre independientemente de si $IFSse establece en su valor predeterminado o no, como se describió anteriormente en esta publicación. Ahora, el OP puede no importarle esto por su caso de uso específico, y de hecho, puede ser una característica deseable del comportamiento de análisis. Pero no todos los que quieran analizar una cadena en los campos querrán esto. Sin embargo, hay una solución: un uso algo no obvio de reades pasar cero argumentos NAME . En este caso, readalmacenará toda la línea de entrada que obtiene de la secuencia de entrada en una variable denominada $REPLYy, como beneficio adicional, nosepare los espacios en blanco iniciales y finales del valor. Este es un uso muy robusto readque he explotado con frecuencia en mi carrera de programación de shell. Aquí hay una demostración de la diferencia de comportamiento:

string=$'  a  b  \n  c  d  \n  e  f  '; ## input string

a=(); while read -r line; do a+=("$line"); done <<<"$string"; declare -p a;
## declare -a a=([0]="a  b" [1]="c  d" [2]="e  f") ## read trimmed surrounding whitespace

a=(); while read -r; do a+=("$REPLY"); done <<<"$string"; declare -p a;
## declare -a a=([0]="  a  b  " [1]="  c  d  " [2]="  e  f  ") ## no trimming

El segundo problema con esta solución es que en realidad no aborda el caso de un separador de campo personalizado, como el espacio de coma del OP. Como antes, los separadores de caracteres múltiples no son compatibles, lo cual es una limitación desafortunada de esta solución. Podríamos intentar al menos dividirnos en comas especificando el separador de la -dopción, pero mira lo que sucede:

string='Paris, France, Europe';
a=(); while read -rd,; do a+=("$REPLY"); done <<<"$string"; declare -p a;
## declare -a a=([0]="Paris" [1]=" France")

Como era de esperar, el espacio en blanco circundante no contabilizado se introdujo en los valores de campo y, por lo tanto, esto tendría que corregirse posteriormente mediante operaciones de recorte (esto también podría hacerse directamente en el bucle while). Pero hay otro error obvio: ¡falta Europa! ¿Que le paso a eso? La respuesta es que readdevuelve un código de retorno fallido si llega al final del archivo (en este caso podemos llamarlo final de la cadena) sin encontrar un terminador de campo final en el campo final. Esto hace que el ciclo while se rompa prematuramente y perdamos el campo final.

Técnicamente, este mismo error también afectaba a los ejemplos anteriores; la diferencia es que el separador de campo se consideró LF, que es el valor predeterminado cuando no especifica la -dopción, y el <<<mecanismo ("here-string") agrega automáticamente un LF a la cadena justo antes de que se alimente como entrada al comando. Por lo tanto, en esos casos, solucionamos accidentalmente el problema de un campo final eliminado agregando involuntariamente un terminador ficticio adicional a la entrada. Llamemos a esta solución la solución "dummy-terminator". Podemos aplicar la solución de terminación ficticia manualmente para cualquier delimitador personalizado concatenando contra la cadena de entrada nosotros mismos al instanciarla en la cadena here:

a=(); while read -rd,; do a+=("$REPLY"); done <<<"$string,"; declare -p a;
declare -a a=([0]="Paris" [1]=" France" [2]=" Europe")

Ahí, problema resuelto. Otra solución es solo romper el ciclo while si tanto (1) readdevolvió el error como (2) $REPLYestá vacío, lo que significa que readno pudo leer ningún carácter antes de tocar el final del archivo. Manifestación:

a=(); while read -rd,|| [[ -n "$REPLY" ]]; do a+=("$REPLY"); done <<<"$string"; declare -p a;
## declare -a a=([0]="Paris" [1]=" France" [2]=$' Europe\n')

Este enfoque también revela el LF secreto que el <<<operador de redireccionamiento agrega automáticamente a la cadena aquí . Por supuesto, podría eliminarse por separado a través de una operación de recorte explícita como se describió hace un momento, pero obviamente el enfoque manual de terminador ficticio lo resuelve directamente, por lo que podríamos seguir con eso. La solución manual de terminación ficticia es realmente bastante conveniente ya que resuelve ambos problemas (el problema de campo final descartado y el problema de LF adjunto) de una sola vez.

Entonces, en general, esta es una solución bastante poderosa. Su única debilidad es la falta de soporte para delimitadores de múltiples caracteres, que abordaré más adelante.

Respuesta incorrecta # 8

string='first line
        second line
        third line'

readarray -t lines <<<"$string"

(Esto es en realidad de la misma publicación que # 7 ; el respondedor proporcionó dos soluciones en la misma publicación).

La readarrayconstrucción, que es sinónimo de mapfile, es ideal. Es un comando incorporado que analiza un bytestream en una variable de matriz de una sola vez; sin jugar con bucles, condicionales, sustituciones o cualquier otra cosa. Y no elimina subrepticiamente ningún espacio en blanco de la cadena de entrada. Y (si -Ono se proporciona) borra convenientemente la matriz de destino antes de asignarla. Pero todavía no es perfecto, de ahí mi crítica de ello como una "respuesta incorrecta".

Primero, solo para sacar esto del camino, tenga en cuenta que, al igual que el comportamiento de readcuando se analiza el campo, se readarrayelimina el campo final si está vacío. Nuevamente, esto probablemente no sea una preocupación para el OP, pero podría serlo para algunos casos de uso. Volveré a esto en un momento.

En segundo lugar, como antes, no admite delimitadores de caracteres múltiples. Daré una solución para esto en un momento también.

En tercer lugar, la solución tal como está escrita no analiza la cadena de entrada del OP y, de hecho, no se puede usar como está para analizarla. Ampliaré esto momentáneamente también.

Por las razones anteriores, todavía considero que esto es una "respuesta incorrecta" a la pregunta del OP. A continuación, daré lo que considero la respuesta correcta.

Respuesta correcta

Aquí hay un intento ingenuo de hacer que el # 8 funcione simplemente especificando la -dopción:

string='Paris, France, Europe';
readarray -td, a <<<"$string"; declare -p a;
## declare -a a=([0]="Paris" [1]=" France" [2]=$' Europe\n')

Vemos que el resultado es idéntico al resultado que obtuvimos del enfoque condicional doble de la readsolución de bucle discutido en el n . ° 7 . Casi podemos resolver esto con el truco manual del terminador ficticio:

readarray -td, a <<<"$string,"; declare -p a;
## declare -a a=([0]="Paris" [1]=" France" [2]=" Europe" [3]=$'\n')

El problema aquí es que readarrayconservó el campo final, ya que el <<<operador de redireccionamiento agregó el LF a la cadena de entrada y, por lo tanto, el campo final no estaba vacío (de lo contrario, se habría eliminado). Podemos ocuparnos de esto desarmando explícitamente el elemento de matriz final después del hecho:

readarray -td, a <<<"$string,"; unset 'a[-1]'; declare -p a;
## declare -a a=([0]="Paris" [1]=" France" [2]=" Europe")

Los únicos dos problemas que quedan, que en realidad están relacionados, son (1) el espacio en blanco extraño que necesita ser recortado, y (2) la falta de soporte para delimitadores de caracteres múltiples.

Por supuesto, el espacio en blanco podría recortarse después (por ejemplo, consulte ¿Cómo recortar el espacio en blanco de una variable Bash? ). Pero si podemos hackear un delimitador de múltiples caracteres, eso resolvería ambos problemas de una sola vez.

Desafortunadamente, no hay una forma directa de hacer que funcione un delimitador de caracteres múltiples. La mejor solución que he pensado es preprocesar la cadena de entrada para reemplazar el delimitador de caracteres múltiples con un delimitador de un solo carácter que se garantizará que no colisionen con el contenido de la cadena de entrada. El único carácter que tiene esta garantía es el byte NUL . Esto se debe a que, en bash (aunque no en zsh, por cierto), las variables no pueden contener el byte NUL. Este paso de preprocesamiento se puede realizar en línea en una sustitución de proceso. Aquí se explica cómo hacerlo con awk :

readarray -td '' a < <(awk '{ gsub(/, /,"\0"); print; }' <<<"$string, "); unset 'a[-1]';
declare -p a;
## declare -a a=([0]="Paris" [1]="France" [2]="Europe")

¡Por fin! Esta solución no dividirá erróneamente los campos en el medio, no se cortará prematuramente, no dejará caer campos vacíos, no se corromperá en las expansiones de nombre de archivo, no eliminará automáticamente los espacios en blanco iniciales y finales, no dejará un LF polizón al final, no requiere bucles y no se conforma con un delimitador de un solo carácter.

Solución de corte

Por último, quería demostrar mi propia solución de recorte bastante compleja utilizando la oscura -C callbackopción de readarray. Desafortunadamente, me he quedado sin espacio contra el límite draconiano de 30,000 caracteres de Stack Overflow, por lo que no podré explicarlo. Lo dejaré como ejercicio para el lector.

function mfcb { local val="$4"; "$1"; eval "$2[$3]=\$val;"; };
function val_ltrim { if [[ "$val" =~ ^[[:space:]]+ ]]; then val="${val:${#BASH_REMATCH[0]}}"; fi; };
function val_rtrim { if [[ "$val" =~ [[:space:]]+$ ]]; then val="${val:0:${#val}-${#BASH_REMATCH[0]}}"; fi; };
function val_trim { val_ltrim; val_rtrim; };
readarray -c1 -C 'mfcb val_trim a' -td, <<<"$string,"; unset 'a[-1]'; declare -p a;
## declare -a a=([0]="Paris" [1]="France" [2]="Europe")

Aquí hay una manera sin configurar IFS:

string="1:2:3:4:5"
set -f                      # avoid globbing (expansion of *).
array=(${string//:/ })
for i in "${!array[@]}"
do
    echo "$i=>${array[i]}"
done

La idea es usar reemplazo de cadena:

${string//substring/replacement}

para reemplazar todas las coincidencias de $ substring con espacios en blanco y luego usar la cadena sustituida para inicializar una matriz:

(element1 element2 ... elementN)

Nota: esta respuesta hace uso del operador split + glob . Por lo tanto, para evitar la expansión de algunos caracteres (como *), es una buena idea hacer una pausa en la búsqueda de este script.

t="one,two,three"
a=($(echo "$t" | tr ',' '\n'))
echo "${a[2]}"

Imprime tres

A veces me ocurrió que el método descrito en la respuesta aceptada no funcionó, especialmente si el separador es un retorno de carro.
En esos casos resolví de esta manera:

string='first line
second line
third line'

oldIFS="$IFS"
IFS='
'
IFS=${IFS:0:1} # this is useful to format your code with tabs
lines=( $string )
IFS="$oldIFS"

for line in "${lines[@]}"
    do
        echo "--> $line"
done

La respuesta aceptada funciona para valores en una línea.
Si la variable tiene varias líneas:

string='first line
        second line
        third line'

Necesitamos un comando muy diferente para obtener todas las líneas:

while read -r line; do lines+=("$line"); done <<<"$string"

O el mucho más simple bash readarray :

readarray -t lines <<<"$string"

Imprimir todas las líneas es muy fácil aprovechando la función printf:

printf ">[%s]\n" "${lines[@]}"

>[first line]
>[        second line]
>[        third line]

Esto es similar al enfoque de Jmoney38 , pero usando sed:

string="1,2,3,4"
array=(`echo $string | sed 's/,/\n/g'`)
echo ${array[0]}

Impresiones 1

La clave para dividir su cadena en una matriz es el delimitador de caracteres múltiples de ", ". Cualquier solución usandoIFS para delimitadores de caracteres múltiples es inherentemente incorrecta ya que IFS es un conjunto de esos caracteres, no una cadena.

Si asigna, IFS=", "entonces la cadena se romperá EN ","O O " "cualquier combinación de ellos que no sea una representación precisa del delimitador de dos caracteres de", " .

Puede usar awko sedpara dividir la cadena, con la sustitución del proceso:

#!/bin/bash

str="Paris, France, Europe"
array=()
while read -r -d $'\0' each; do   # use a NUL terminated field separator 
    array+=("$each")
done < <(printf "%s" "$str" | awk '{ gsub(/,[ ]+|$/,"\0"); print }')
declare -p array
# declare -a array=([0]="Paris" [1]="France" [2]="Europe") output

Es más eficiente usar una expresión regular directamente en Bash:

#!/bin/bash

str="Paris, France, Europe"

array=()
while [[ $str =~ ([^,]+)(,[ ]+|$) ]]; do
    array+=("${BASH_REMATCH[1]}")   # capture the field
    i=${#BASH_REMATCH}              # length of field + delimiter
    str=${str:i}                    # advance the string by that length
done                                # the loop deletes $str, so make a copy if needed

declare -p array
# declare -a array=([0]="Paris" [1]="France" [2]="Europe") output...

Con la segunda forma, no hay sub shell y será inherentemente más rápido.

Editar por bgoldst: Aquí hay algunos puntos de referencia que comparan mi readarraysolución con la solución regex de dawg, y también incluí la readsolución para el gusto (nota: modifiqué ligeramente la solución regex para una mayor armonía con mi solución) (también vea mis comentarios debajo del enviar):

## competitors
function c_readarray { readarray -td '' a < <(awk '{ gsub(/, /,"\0"); print; };' <<<"$1, "); unset 'a[-1]'; };
function c_read { a=(); local REPLY=''; while read -r -d ''; do a+=("$REPLY"); done < <(awk '{ gsub(/, /,"\0"); print; };' <<<"$1, "); };
function c_regex { a=(); local s="$1, "; while [[ $s =~ ([^,]+),\  ]]; do a+=("${BASH_REMATCH[1]}"); s=${s:${#BASH_REMATCH}}; done; };

## helper functions
function rep {
    local -i i=-1;
    for ((i = 0; i<$1; ++i)); do
        printf %s "$2";
    done;
}; ## end rep()

function testAll {
    local funcs=();
    local args=();
    local func='';
    local -i rc=-1;
    while [[ "$1" != ':' ]]; do
        func="$1";
        if [[ ! "$func" =~ ^[_a-zA-Z][_a-zA-Z0-9]*$ ]]; then
            echo "bad function name: $func" >&2;
            return 2;
        fi;
        funcs+=("$func");
        shift;
    done;
    shift;
    args=("$@");
    for func in "${funcs[@]}"; do
        echo -n "$func ";
        { time $func "${args[@]}" >/dev/null 2>&1; } 2>&1| tr '\n' '/';
        rc=${PIPESTATUS[0]}; if [[ $rc -ne 0 ]]; then echo "[$rc]"; else echo; fi;
    done| column -ts/;
}; ## end testAll()

function makeStringToSplit {
    local -i n=$1; ## number of fields
    if [[ $n -lt 0 ]]; then echo "bad field count: $n" >&2; return 2; fi;
    if [[ $n -eq 0 ]]; then
        echo;
    elif [[ $n -eq 1 ]]; then
        echo 'first field';
    elif [[ "$n" -eq 2 ]]; then
        echo 'first field, last field';
    else
        echo "first field, $(rep $[$1-2] 'mid field, ')last field";
    fi;
}; ## end makeStringToSplit()

function testAll_splitIntoArray {
    local -i n=$1; ## number of fields in input string
    local s='';
    echo "===== $n field$(if [[ $n -ne 1 ]]; then echo 's'; fi;) =====";
    s="$(makeStringToSplit "$n")";
    testAll c_readarray c_read c_regex : "$s";
}; ## end testAll_splitIntoArray()

## results
testAll_splitIntoArray 1;
## ===== 1 field =====
## c_readarray   real  0m0.067s   user 0m0.000s   sys  0m0.000s
## c_read        real  0m0.064s   user 0m0.000s   sys  0m0.000s
## c_regex       real  0m0.000s   user 0m0.000s   sys  0m0.000s
##
testAll_splitIntoArray 10;
## ===== 10 fields =====
## c_readarray   real  0m0.067s   user 0m0.000s   sys  0m0.000s
## c_read        real  0m0.064s   user 0m0.000s   sys  0m0.000s
## c_regex       real  0m0.001s   user 0m0.000s   sys  0m0.000s
##
testAll_splitIntoArray 100;
## ===== 100 fields =====
## c_readarray   real  0m0.069s   user 0m0.000s   sys  0m0.062s
## c_read        real  0m0.065s   user 0m0.000s   sys  0m0.046s
## c_regex       real  0m0.005s   user 0m0.000s   sys  0m0.000s
##
testAll_splitIntoArray 1000;
## ===== 1000 fields =====
## c_readarray   real  0m0.084s   user 0m0.031s   sys  0m0.077s
## c_read        real  0m0.092s   user 0m0.031s   sys  0m0.046s
## c_regex       real  0m0.125s   user 0m0.125s   sys  0m0.000s
##
testAll_splitIntoArray 10000;
## ===== 10000 fields =====
## c_readarray   real  0m0.209s   user 0m0.093s   sys  0m0.108s
## c_read        real  0m0.333s   user 0m0.234s   sys  0m0.109s
## c_regex       real  0m9.095s   user 0m9.078s   sys  0m0.000s
##
testAll_splitIntoArray 100000;
## ===== 100000 fields =====
## c_readarray   real  0m1.460s   user 0m0.326s   sys  0m1.124s
## c_read        real  0m2.780s   user 0m1.686s   sys  0m1.092s
## c_regex       real  17m38.208s   user 15m16.359s   sys  2m19.375s
##

Solución de delimitador de caracteres múltiples de bash puro.

Como otros han señalado en este hilo, la pregunta del OP dio un ejemplo de una cadena delimitada por comas para ser analizada en una matriz, pero no indicó si él / ella solo estaba interesado en delimitadores de coma, delimitadores de un solo carácter o de varios caracteres. delimitadores

Dado que Google tiende a clasificar esta respuesta en la parte superior de los resultados de búsqueda o cerca de ella, quería proporcionar a los lectores una respuesta sólida a la pregunta de delimitadores de caracteres múltiples, ya que eso también se menciona en al menos una respuesta.

Si está buscando una solución a un problema de delimitador de caracteres múltiples, le sugiero que revise la publicación de Mallikarjun M , en particular la respuesta de gniourf_gniourf, que proporciona esta elegante solución pura de BASH utilizando la expansión de parámetros:

#!/bin/bash
str="LearnABCtoABCSplitABCaABCString"
delimiter=ABC
s=$str$delimiter
array=();
while [[ $s ]]; do
    array+=( "${s%%"$delimiter"*}" );
    s=${s#*"$delimiter"};
done;
declare -p array

Enlace al comentario citado / publicación referenciada

Enlace a la pregunta citada: ¿ Cómo dividir una cadena en un delimitador de varios caracteres en bash?

Esto funciona para mí en OSX:

string="1 2 3 4 5"
declare -a array=($string)

Si su cadena tiene un delimitador diferente, solo reemplace aquellos con espacio:

string="1,2,3,4,5"
delimiter=","
declare -a array=($(echo $string | tr "$delimiter" " "))

Simple :-)

Otra forma de hacerlo sin modificar IFS:

read -r -a myarray <<< "${string//, /$IFS}"

En lugar de cambiar IFS para que coincida con nuestro delimitador deseado, podemos reemplazar todas las apariciones de nuestro delimitador deseado ", "con contenido de $IFSvia "${string//, /$IFS}".

¿Quizás esto sea lento para cadenas muy grandes?

Esto se basa en la respuesta de Dennis Williamson.

Encontré esta publicación cuando buscaba analizar una entrada como: word1, word2, ...

nada de lo anterior me ayudó. lo resolvió usando awk. Si ayuda a alguien:

STRING="value1,value2,value3"
array=`echo $STRING | awk -F ',' '{ s = $1; for (i = 2; i <= NF; i++) s = s "\n"$i; print s; }'`
for word in ${array}
do
        echo "This is the word $word"
done

Prueba esto

IFS=', '; array=(Paris, France, Europe)
for item in ${array[@]}; do echo $item; done

Es simple. Si lo desea, también puede agregar una declaración (y también eliminar las comas):

IFS=' ';declare -a array=(Paris France Europe)

El IFS se agrega para deshacer lo anterior pero funciona sin él en una nueva instancia de bash

Podemos usar el comando tr para dividir la cadena en el objeto de matriz. Funciona tanto en MacOS como en Linux

  #!/usr/bin/env bash
  currentVersion="1.0.0.140"
  arrayData=($(echo $currentVersion | tr "." "\n"))
  len=${#arrayData[@]}
  for (( i=0; i<=$((len-1)); i++ )); do 
       echo "index $i - value ${arrayData[$i]}"
  done

Otra opción es usar el comando IFS

IFS='.' read -ra arrayData <<< "$currentVersion"
#It is the same as tr
arrayData=($(echo $currentVersion | tr "." "\n"))

#Print the split string
for i in "${arrayData[@]}"
do
    echo $i
done

Utilizar este:

countries='Paris, France, Europe'
OIFS="$IFS"
IFS=', ' array=($countries)
IFS="$OIFS"

#${array[1]} == Paris
#${array[2]} == France
#${array[3]} == Europe

ACTUALIZACIÓN: No haga esto, debido a problemas con eval.

Con un poco menos de ceremonia:

IFS=', ' eval 'array=($string)'

p.ej

string="foo, bar,baz"
IFS=', ' eval 'array=($string)'
echo ${array[1]} # -> bar

Aquí está mi truco!

Dividir cadenas por cadenas es algo bastante aburrido de hacer con bash. Lo que sucede es que tenemos enfoques limitados que solo funcionan en algunos casos (divididos por ";", "/", "." Y así sucesivamente) o tenemos una variedad de efectos secundarios en los resultados.

El siguiente enfoque ha requerido una serie de maniobras, ¡pero creo que funcionará para la mayoría de nuestras necesidades!

#!/bin/bash

# --------------------------------------
# SPLIT FUNCTION
# ----------------

F_SPLIT_R=()
f_split() {
    : 'It does a "split" into a given string and returns an array.

    Args:
        TARGET_P (str): Target string to "split".
        DELIMITER_P (Optional[str]): Delimiter used to "split". If not 
    informed the split will be done by spaces.

    Returns:
        F_SPLIT_R (array): Array with the provided string separated by the 
    informed delimiter.
    '

    F_SPLIT_R=()
    TARGET_P=$1
    DELIMITER_P=$2
    if [ -z "$DELIMITER_P" ] ; then
        DELIMITER_P=" "
    fi

    REMOVE_N=1
    if [ "$DELIMITER_P" == "\n" ] ; then
        REMOVE_N=0
    fi

    # NOTE: This was the only parameter that has been a problem so far! 
    # By Questor
    # [Ref.: https://unix.stackexchange.com/a/390732/61742]
    if [ "$DELIMITER_P" == "./" ] ; then
        DELIMITER_P="[.]/"
    fi

    if [ ${REMOVE_N} -eq 1 ] ; then

        # NOTE: Due to bash limitations we have some problems getting the 
        # output of a split by awk inside an array and so we need to use 
        # "line break" (\n) to succeed. Seen this, we remove the line breaks 
        # momentarily afterwards we reintegrate them. The problem is that if 
        # there is a line break in the "string" informed, this line break will 
        # be lost, that is, it is erroneously removed in the output! 
        # By Questor
        TARGET_P=$(awk 'BEGIN {RS="dn"} {gsub("\n", "3F2C417D448C46918289218B7337FCAF"); printf $0}' <<< "${TARGET_P}")

    fi

    # NOTE: The replace of "\n" by "3F2C417D448C46918289218B7337FCAF" results 
    # in more occurrences of "3F2C417D448C46918289218B7337FCAF" than the 
    # amount of "\n" that there was originally in the string (one more 
    # occurrence at the end of the string)! We can not explain the reason for 
    # this side effect. The line below corrects this problem! By Questor
    TARGET_P=${TARGET_P%????????????????????????????????}

    SPLIT_NOW=$(awk -F"$DELIMITER_P" '{for(i=1; i<=NF; i++){printf "%s\n", $i}}' <<< "${TARGET_P}")

    while IFS= read -r LINE_NOW ; do
        if [ ${REMOVE_N} -eq 1 ] ; then

            # NOTE: We use "'" to prevent blank lines with no other characters 
            # in the sequence being erroneously removed! We do not know the 
            # reason for this side effect! By Questor
            LN_NOW_WITH_N=$(awk 'BEGIN {RS="dn"} {gsub("3F2C417D448C46918289218B7337FCAF", "\n"); printf $0}' <<< "'${LINE_NOW}'")

            # NOTE: We use the commands below to revert the intervention made 
            # immediately above! By Questor
            LN_NOW_WITH_N=${LN_NOW_WITH_N%?}
            LN_NOW_WITH_N=${LN_NOW_WITH_N#?}

            F_SPLIT_R+=("$LN_NOW_WITH_N")
        else
            F_SPLIT_R+=("$LINE_NOW")
        fi
    done <<< "$SPLIT_NOW"
}

# --------------------------------------
# HOW TO USE
# ----------------

STRING_TO_SPLIT="
 * How do I list all databases and tables using psql?

\"
sudo -u postgres /usr/pgsql-9.4/bin/psql -c \"\l\"
sudo -u postgres /usr/pgsql-9.4/bin/psql <DB_NAME> -c \"\dt\"
\"

\"
\list or \l: list all databases
\dt: list all tables in the current database
\"

[Ref.: /dba/1285/how-do-i-list-all-databases-and-tables-using-psql]


"

f_split "$STRING_TO_SPLIT" "bin/psql -c"

# --------------------------------------
# OUTPUT AND TEST
# ----------------

ARR_LENGTH=${#F_SPLIT_R[*]}
for (( i=0; i<=$(( $ARR_LENGTH -1 )); i++ )) ; do
    echo " > -----------------------------------------"
    echo "${F_SPLIT_R[$i]}"
    echo " < -----------------------------------------"
done

if [ "$STRING_TO_SPLIT" == "${F_SPLIT_R[0]}bin/psql -c${F_SPLIT_R[1]}" ] ; then
    echo " > -----------------------------------------"
    echo "The strings are the same!"
    echo " < -----------------------------------------"
fi

Para elementos multilínea, ¿por qué no algo como

$ array=($(echo -e $'a a\nb b' | tr ' ' '§')) && array=("${array[@]//§/ }") && echo "${array[@]/%/ INTERELEMENT}"

a a INTERELEMENT b b INTERELEMENT

Otra forma sería:

string="Paris, France, Europe"
IFS=', ' arr=(${string})

Ahora sus elementos se almacenan en la matriz "arr". Para iterar a través de los elementos:

for i in ${arr[@]}; do echo $i; done

Dado que hay muchas maneras de resolver esto, comencemos definiendo lo que queremos ver en nuestra solución.

1. Bash proporciona un incorporado readarraypara este propósito. Vamos a usarlo
2. Evite trucos feos e innecesarios, como cambiar IFS, hacer bucles, usareval o agregar un elemento adicional y luego eliminarlo.
3. Encuentre un enfoque simple y legible que pueda adaptarse fácilmente a problemas similares.

El readarraycomando es más fácil de usar con líneas nuevas como delimitador. Con otros delimitadores, puede agregar un elemento adicional a la matriz. El enfoque más limpio es primero adaptar nuestra entrada a una forma que funcione bien conreadarray antes de pasarla.

La entrada en este ejemplo no tiene un delimitador de caracteres múltiples. Si aplicamos un poco de sentido común, se entiende mejor como entrada separada por comas para la cual cada elemento puede necesitar ser recortado. Mi solución es dividir la entrada por comas en varias líneas, recortar cada elemento y pasarlo todo readarray.

string='  Paris,France  ,   All of Europe  '
readarray -t foo < <(tr ',' '\n' <<< "$string" |sed 's/^ *//' |sed 's/ *$//')
declare -p foo

# declare -a foo='([0]="Paris" [1]="France" [2]="All of Europe")'

Otro enfoque puede ser:

str="a, b, c, d"  # assuming there is a space after ',' as in Q
arr=(${str//,/})  # delete all occurrences of ','

Después de esto, 'arr' es una matriz con cuatro cadenas. Esto no requiere tratar IFS o leer o cualquier otra cosa especial, por lo tanto, mucho más simple y directo.