pdd.sh

ts only displaying the help if the user has currently set verbosity>=2 until further notice. Later down the file it hits a '#v 1' and starts displaying help again... It works but it feels kind of 70's or assembly. #v 1 #h normal help for mortals #h ... #v 2 #h don't confuse the simple folk with this dangerous powerful stuff... #h ... #v 1 #h a few more normal commands #h ... #v 0 #h display this even the user has set verbosity to 0 to request silence #h ...

. The only byte that is a problem is null, and there is a way to deal with that. You can't directly store a null, but you can detect that you read one and store that info, and reconstruct it on output later, or do math on it, use it's numerical value as an array index or byte offset or whatever the byte is for. For a minimal example, just copying a binary file: while LANG=C IFS= read -d '' -r -n 1 x ;do printf '%c' "$x" ;done <bin1 >bin2 That's a bit too minimal since it doesn't show what other kinds of things you can do that are more useful than cat-without-cat. A bit more generic and useful: https://gist.github.com/bkw777/c1413d0e3de6c54524ddae890fe8d... The LANG=C, IFS= , and -d'' all combine to render all bytes accessible except 0x00, and then the return value from read() tells you the difference between "we read a 0x00" and "we didn't read anything" and "input ended" And it doesn't have to use < and > on the overall while() comand either. You can exec 3<>file_or_fifo_or_tty and read -u3 / printf >&3 etc inside the loop instead. An example reading from a serial port: https://gist.github.com/bkw777/ddde771cc85fdd888c7ec74953193... Used in anger: https://github.com/bkw777/pdd.sh see tpdd_read, tpdd_write, file_to_fhex, str_to_shex reading and writing both a serial port and local files and doing all kinds of processing on the data. And these loops are not even subshells let alone externals. You can manipulate variables inside the loop and you are still in the same original context. I'd say parent shell but there are no childern. Those all read a single byte at a time with read -n 1, but they don't have to. You can read without the -n1 and each iteration of the loop will collect as much as it can between nulls instead of always one byte. That would consume less ram and less loop iterations. But the things I'm using them for want to slice & dice the individual bytes and byte-ranges at numerical offsets anyway and the data is always small (by todays standards) so the array-of-hex-pairs is just too convenient where a[n] == byte n, and all bytes are treated the same whether printable, non-printable, or null, and aside from merely storing and regenerating the bytes with printf you can also use the numerical values directly as well by simply prepending 0x, so 0x$n or 0x${a[n]} almost anywhere you would normally have a simple integer. So you can do math on them and use them as array indexes and byte offsets etc. Read the 2nd byte of h[] as a length of the payload to follow, and clip out that payload: ${h[@]:2:0x${h[1]}}

ax. Making bash read one byte at a time for 200k is still nothing today but only because hardware is insane today. But it's possible. And the beginning of the post does say "as a thought experiment". Similarly, you don't need xxd to convert back & forth between raw binary and text encoding. My own similar thought experiment included the idea that, if I'm not going to use any external process I can possibly avoid and only use internal bash features, on the flip side of that, I will squeez bash for all it's worth, allow every bashism possible.