Diferencia entre $ '$ foo' y $ “$ foo”

9

Tengo dificultades para descubrir algunos matices entre comillas simples y dobles dentro de un contexto variable

Yo defino:

foo=pwd

luego ejecute estos:

echo $'$foo'

Qué ecos $foo(es decir, el primero $en mi comando echo se descarta)

echo $"$foo"

Este eco pwd(lo que significa que bash se expande $foo, mi variable, a su valor)

echo $`$foo`

Finalmente este eco $~/scripts(esperaba que se imprimiera ~/scriptsy no $~/scripts)

¿Alguien puede ayudarme a descubrir estas diferencias?

command-line bash scripts

— Ilan
fuente

11

echo $'$foo': el $'[...]'token alrededor $foo interpreta $fooliteralmente (como $foo) e intenta expandir las secuencias de escape de tipo ANSI C que no están presentes, por lo que echoproduce $foo;
echo $"$foo": el $"[...]"token se $foo expande $fooa su valor ( pwd) e intenta traducirlo si el entorno local actual no es POSIX / C ; esto no sucede porque la configuración regional actual es POSIX / C o no hay una traducción pwddisponible, por lo que se echoobtiene pwd;
echo $`$foo`: el `[...]`token alrededor $foopermite la expansión de $foo, por lo que $foose expande a su valor ( pwd); el valor expandido se ejecuta en una subshell, cuya salida ( ~/scripts) reemplaza el `[...]`token completo , por lo que echoproduce el $token seguido por el ~/scriptstoken ( $~/scripts).

Finalmente, el último se imprime $~/scriptsporque $`foo`es una combinación de un literal $seguido de una sustitución de comando; por lo tanto, el inicio $se interpreta como un literal $y el final `$foo`como una sustitución de comando.

— kos
fuente

He quitado las etiquetas de código y sustituye con sólo `` `` `` `` caracteres etc. no dude de revertir si se prefiere las etiquetas de código

— Tim

@Tim Gracias, no estoy seguro de lo que hice exactamente, pero por alguna razón después de que editaste la publicación apareció tan perturbada como en mi primera revisión, así que la volví a tirar ... Y ahora veo que se ve bien en la revisión. No estoy seguro de lo que sucedió, probaré esto en el entorno limitado de formato antes de volver a su versión, ya que me temo que podría interrumpir la publicación nuevamente. De todos modos, gracias por el esfuerzo.

— kos

Claro, no hay problemas. El mío usa espacios de ancho cero, así que ten cuidado al editar.

— Tim

2

Primer caso:

echo $'$foo'
Qué ecos $foo(es decir, el primero $en mi comando echo se descarta)

El primero $se ejecuta como un comando. Echo no requiere espacios entre argumentos, solo los toma.

Entonces echo se $'$foo'expande para ejecutar el comando $(que no es un comando, por lo que lo ignora) y luego echo '$foo'. Todo lo que ''se toma se toma al pie de la letra, no lo expande ni nada. Puedes poner lo que quieras '' y no pasa nada.

Si reemplaza el $con $$ella, se hace eco del ID del proceso.

Segundo:

echo $"$foo"
Este eco pwd(lo que significa que bash se expande $foo, mi variable, a su valor)

Eso es porque ""no evita que se expanda. ""normalmente se usa para garantizar que haya un valor con el que comparar.

Si tiene una variable que podría estar vacía (por ejemplo, es de un grepresultado), entonces desea compararla con otro valor / variable, debe ingresar la primera variable "". Esto asegura que siempre haya una comparación para verificar, en lugar de solo una sección vacía de código (como ve bash) que da un error.

Finalmente, el número 3. Esto es interesante.

echo $`$foo`
Este eco $~/scripts(esperaba que se imprimiera ~/scriptsy no $~/scripts)

Eso es porque (en este caso) echo está imprimiendo el $personaje primero. Poner algo en los backticks hace que el valor de la variable se ejecute como un comando (la mejor manera de hacerlo en versiones más recientes de bash es $(command))

Entonces, primero se hace eco, $luego se expande `$foo`a lo `pwd`que se ejecuta y regresa ~/Scripts. Pero teníamos la $impresión antes, así que todo el resultado es $~/Scripts.

— Tim
fuente

¡Buen trabajo en un formato muy difícil!

— Arronical

1

@Arronical Gracias :) No puedes verlo, pero hay algunos espacios de ancho cero para la última oración. ¡Las cosas que hago por puntos imaginarios de internet ...!

— Tim

1

+1 Buena respuesta. Solo agregaría que las variables de cotización deberían ser las predeterminadas a menos que tenga una razón específica para no hacerlo, no solo para manejar posibles valores nulos. Visite unix.stackexchange.com/questions/171346/… para obtener más de lo que siempre quiso saber sobre esto. ;)

— Joe