¿Los shells que no sean Bash y Zsh admiten cotizaciones ANSI-C? por ejemplo $ 'string'

13

Tengo un script de shell que utiliza lo siguiente para imprimir una marca de verificación verde en su salida:

col_green="\e[32;01m"
col_reset="\e[39;49;00m"

echo -e "Done ${col_green}✓${col_reset}"

Después de leer acerca de las citas ANSI-C de Bash , me di cuenta de que podía usarlo al configurar mis variables de color y eliminar la -ebandera de mi eco .

col_green=$'\e[32;01m'
col_reset=$'\e[39;49;00m'

echo "Done ${col_green}✓${col_reset}"

Esto parece atractivo, ya que significa que el mensaje se imprime correctamente si se pasa al eco incorporado de Bash o al util externo /bin/echo(estoy en macOS).

¿Pero esto hace que el script sea menos portátil? Sé que Bash y Zsh admiten este estilo de citas, pero no estoy seguro acerca de los demás.

— ivan
fuente

Sí, desde cuando solo ksh y sus variaciones lo soportan por ahora. Pero IIRC, la cita ANSI-C estará en la próxima especificación POSIX.

— Cuonglm

ksh doc: debian ksh (1)

— Arthur2e5

12

$'…'es una característica de ksh93 que también está presente en zsh, bash, mksh, FreeBSD sh y en algunas compilaciones de BusyBox sh (BusyBox ash construido con ENABLE_ASH_BASH_COMPAT). Todavía no está presente en el lenguaje POSIX sh. Los shells comunes tipo Bourne que no lo tienen incluyen dash (que /bin/shpor defecto está en Ubuntu entre otros), ksh88, el shell Bourne, NetBSD sh, yash, derivados de pdksh que no sean mksh y algunas compilaciones de BusyBox.

Se debe utilizar una forma portátil de analizar la barra diagonal inversa y la barra diagonal inversa como caracteres de control printf. Está presente en todos los sistemas compatibles con POSIX.

esc=$(printf '\033') # assuming an ASCII (as opposed to EBCDIC) system
col_green="${esc}[32;01m"

Tenga en cuenta que \eno es portátil. Es compatible con muchas implementaciones de printfpero no con la del tablero¹. Use el código octal en su lugar.

Supported _{Es compatible con Debian y derivados que se envían al menos 0.5.8-2.4, por ejemplo, desde Debian stretch y Ubuntu 17.04.}

— Gilles 'SO- deja de ser malvado'
fuente

¿estás seguro de \eno ser admitido dash? dash -c 'printf "\e[1;31m"; type printf; printf "\e[m"'se imprimirá printf is a shell builtinen negrita aquí (guión-0.5.8). Un shell que no es compatible \ees yash.

— mosvy

@mosvy Imprime \e[1;31mprintf is a shell builtin \e[maquí. Ubuntu 16.04, guión 0.5.8-2.1ubuntu2. Imprime en rojo en Ubuntu 18.04 con el guión 0.5.8-2.10. Parece que Ubuntu hizo un parche para soportarlo.

— Gilles 'SO- deja de ser malvado'

Sí, lo siento, parece que es un parche de Debian (9.7 estiramiento). Aquí está el original.

— mosvy

0

El grado de $'...'soporte también debe tenerse en cuenta al portar. La propuesta de la gente POSIX de poner esto en POSIX menciona una en particular:

stephane: ksh93 es el shell $ '...' proviene de (mientras que $'\uxxxx'[ y$'\Uxxxxxxxx' ] proviene de zsh: http://www.zsh.org/mla/workers/2003/msg00223.html ) [^]

Por lo que obtuve aquí en mi diana de Debian, el ksh2020de AT&T entiende $'\U1F600'. Este es el único shell Korn "oficial" que puedo obtener en esta nueva distribución.

mkshlo analizó pero lo estropeó por completo con un U + FFFE. Como no se quejó de un error de sintaxis, tiene que haber algo mal con su comprensión de Unicode. Se maneja $'\U01F60'bien.

— Arthur2e5
fuente

Desafortunadamente, como efecto de un reciente golpe de estado, ksh2020 ha desaparecido. Pero sí, el ksh93 original es compatible $'...'e iirc fue el primero que lo hizo.

— mosvy

@ Arthur2e5. ksh2020No es de AT&T. Un par de personas, una de Red Hat, esencialmente secuestró el árbol de github AST de AT&T hace unos años y reclamó el control del ksh93desarrollo futuro

— fpmurphy