rm -rf права root запрещены

Enfaticemos aún más que xxd -pes irrelevante, no estamos hablando de su salida . Ni siquiera ha visto la entrada debido al almacenamiento en búfer de línea en el lado del kernel y, por lo tanto, no ha producido ninguna salida. Por lo que vale, también podría ser un cato un sleep 100000o lo que sea. Estamos hablando de cómo el kernel (la disciplina de línea )repite la entrada.

Si vuelve a cambiar a UTF -8 y luego presiona Enter a xxd -p, su salida es como fffe6100fffe6100. Así que se confirma little endian (o probablemente sea el orden de bytes nativo de la arquitectura ), pero sorprendentemente, hay una lista de materiales antes de cada carácter. Me hace sospechar que los desarrolladores de Konsole no lo pensaron correctamente, simplemente invocaron ciegamente iconv con UTF -16 (sin BE o LE especificado )como el conjunto de caracteres de destino, para cada fragmento de entrada como pasa a estar disponible e iconv lo coloca allí.

Veamos stracekonsole para ver qué hace en su descriptor de archivo conectado a/dev/ptmx:

write(..., "\377\376a\0", 4)             = 4
[...]
read(..., "\377\376a^@", 5)              = 5

El byte NUL (0x00 )regresa como literal ^@, es decir, 0x5e seguido de 0x40.

Junto cona(0x61 ), esto le da U+5e61, que es exactamente el primer glifo que ve aparecer. Además, te equivocarás por un byte, es decir, el siguiente byte supuestamente bajo se interpretará como un byte alto y viceversa.

Para el byte 0x00, el kernel simplemente modifica la forma en que se repite. Para algunos otros bytes, también realiza otras acciones. Por ejemplo, el byte0x03(^C)generalmente activa una interrupción que se enviará al proceso de primer plano,0x15(^U)borra los datos que ha ingresado hasta el momento, 0x0ay/o 0x0d(, es decir, la nueva línea )vacía el datos a su aplicación, etc. Todos estos bytes pueden (y )ocurrir legalmente dentro de la representación de caracteres UTF -16, y seguramente no desea que ocurra nada de esto mientras escribe su entrada.

Para poder usar UTF -16 en el discípulo de línea, el kernel necesitaría brindar soporte explícito para esto y se le tendría que informar que esta codificación se está usando (algo similar a unstty utf16). Que yo sepa, esto no está implementado (afortunadamente, sería una pérdida total de recursos del desarrollador ). El núcleo espera que se utilice una codificación compatible con ASCII -, que no es UTF -16.

Incluso si se implementara UTF -16 en el kernel para la línea tty, todo el ecosistema sería necesariamente bastante frágil. El terminal puede recibir datos de múltiples fuentes simultáneamente, y no hay forma de garantizar que todos los productores de datos y todos los transportadores (p. ssh )siempre puede mantener los bytes acoplados en pares. Una vez que se apaga por un byte (como se ve arriba ), el resto es inutilizable.

Ahora estoy aún más seguro de que el desarrollador de Konsole no lo pensó bien. En mi opinión, UTF -16 debería eliminarse de su lista de codificaciones ofrecidas, o al menos debería mostrarse una advertencia. He enviado error de Konsole 395171 .