¿Un entorno similar a una concha para el procesamiento binario?

Esta pregunta me llegó un par de veces antes, ahora en respuesta a la pregunta
Recorrer fragmentos de datos binarios de stdin en Bash
Respuestas dadas en https://stackoverflow.com/questions/993434/what -language-is-to-binary-as-perl-is-to-text tampoco fueron satisfactorios.

Estoy buscando un entorno de secuencias de comandos adecuado específicamente para manejar E/S con archivos binarios. Sé que puedo usar uno de los lenguajes de programación completos (c/Python/...) pero tienen una sobrecarga enorme de inicialización y codificación (asignación y fread/fwrite en c, cadenas de bits en Python...) sin mencionar que son menos adecuados para secuencias de comandos (llamar a otras aplicaciones desde él). Perl no es mejor con su unpack funciones, operación orientada a cadenas y sintaxis tonta.

Algo así como od , sino como un idioma.

Lo que espero:

1. establezca o cambie el endianness con un solo interruptor/comando.
2. especificación simple del tipo solicitado (algo así como extender bash read var con int32 var , float var etc.).
3. manejo de conductos binarios, omisión de un número específico de bytes.
4. control de flujo de secuencias de comandos estándar (para/si/...) al que estamos acostumbrados.

Me gustaría procesar datos sin procesar (fotografía, datos científicos, formatos desconocidos y mal documentados) con la misma facilidad y conocimiento que obtiene al inspeccionar archivos ASCII. estoy usando c ahora, pero no es óptimo para secuencias de comandos ad-hoc y no puede ser interactivo.

¿Alguien conoce una herramienta así? Sin software de GUI clicky, por favor, necesita funcionar sobre ssh, desde otros scripts, etc. “No existe” es una respuesta aceptable, pero deprimente.

Respuesta aceptada:

También tengo exactamente el mismo problema que tú durante años.

Para usos simples no interactivos, me gusta usar el editor de bloques binarios BBE.
BBE es a binario como SED es a texto, incluida su sintaxis arcaica y simplicidad, sin embargo, tiene muchas características que faltan de lo que yo a menudo necesito, por lo que tengo que combinarlo con otras herramientas. Por lo tanto, BBE es solo una solución parcial.
También tenga en cuenta que BBE no ha tenido actualizaciones ni mejoras durante años.

Por supuesto, uno puede usar xxd antes y xxd -r después de editar los datos con herramientas basadas en texto, pero eso no funcionará cuando los datos en cuestión sean grandes y se requiera acceso aleatorio, por ejemplo, cuando se procesan dispositivos de bloque.

(Nota:para Windows, existe al menos el costoso lenguaje de secuencias de comandos propietario WinHex, pero eso no nos llevará a ninguna parte).

Para una edición binaria más complicada, suelo recurrir también a Python, aunque a veces es demasiado lento para archivos grandes, que es su principal inconveniente. Espero que Pyston (Python que emplea LLVM para compilar un código de máquina optimizado) algún día madure lo suficiente como para ser utilizable, o incluso mejor, alguien diseñe e implemente un lenguaje de secuencias de comandos de procesamiento binario compacto, rápido y versátil, que AFAIK no existe para Sistemas similares a U*IX todavía.

Relacionado:¿Procesar descendientes?

ACTUALIZAR

También utilizo el ensamblador plano ensamblador Intel x86 de código abierto y casero, o fasm para abreviar, que se convirtió en mucho más que un simple ensamblador.

Tiene un potente preprocesador de macros basado en bloques de texto (en sí mismo un lenguaje completo de Turing) con una sintaxis en la tradición del lenguaje de macros borland turbo ensamblador, pero mucho más avanzada.

Además, tiene un lenguaje de manipulación de datos, que permite incluir binarios en archivos arbitrarios, hacer todo tipo de manipulación binaria y aritmética (solo enteros) en "tiempo de compilación" y escribir el resultado en un archivo de salida. Este lenguaje de manipulación de datos tiene estructuras de control y también está completo.

Es mucho más fácil de usar que escribir un programa que realice alguna manipulación binaria en C y probablemente incluso en python. Además, se carga increíblemente rápido, ya que es un ejecutable de tamaño pequeño que casi no tiene dependencias externas (hay 2 versiones:solo requiere libc o puede ejecutarse como un ejecutable estático directamente en la ABI del kernel de Linux).

Tiene algunos bordes de gorguera, como

1. no es compatible con la concurrencia

2. al estar escribiendo en un ensamblado x86 de 32 bits (aunque funciona en x86_64), probablemente necesite qemu o un emulador similar si desea ejecutarlo en cualquier otra cosa que no sea x86 o x86_64

3. su poderoso lenguaje de preprocesador de macros está completo, esto significa que es mejor que tenga algo de experiencia con lenguajes como Lisp, Haskell, XSLT o probablemente M4 sería la mejor opción.

4. todos los datos que se escribirán en el archivo de salida se ejecutan en un búfer "plano" en la memoria, y este búfer puede crecer pero no reducirse hasta que el archivo de salida se haya escrito y fasm terminado. Esto significa que uno solo puede generar archivos como máximo tan grandes como le queda la memoria principal en una sola ejecución de fasm.

5. los datos solo se pueden escribir en un único archivo de salida para cada ejecución de fasm

6. sí, es casero, aunque realmente bueno e inteligente