5 ms·

They should have used my (dumb?) library, ctypes.sh: https://github.com/taviso/ctypes.sh https://github.com/taviso/ctypes.sh Then they can access libm, poll()

by taviso 3y ago

They should have used my (dumb?) library, ctypes.sh: https://github.com/taviso/ctypes.sh https://github.com/taviso/ctypes.sh Then they can access libm, poll(), select() and so on from bash :)

lagniappe 3y ago
woah that's cool :) also hello tavis
MrBuddyCasino 3y ago
I‘m not sure you should have done that, but it is impressive for the sheer chuzpa of it. Like reanimating Frankenstein.
jethro_tell 3y ago
Lol, holy shit what did I just read? Amazing, installing now. I want to be part of the problem.
Brian_K_White 3y ago
Awesome, but beside the point of writing something in bash that never needed to be in bash for any technical reason. Meaning if it requires bash plus some specially installed compiled c code, then it might as well require c or python or anything else and there is no point in calling it "written in bash", or writing it in mostly-bash-plus-special-plugin. I do know who I'm speaking to so please assume I say this respectfully. :) I have no problem with a "pointless" project like that as I'll show in a second. That said, this minecraft project itself relies on externals like xxd when it doesn't need to, so using ctypes.sh would be no worse in this case, so you are right, in this case they might as well have. But for the record it is possible to read, store, manipulate, do math on, and output binary in pure bash without anything like dd or xxd. 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/c1413d0e3de6c54524ddae890fe8d705 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/ddde771cc85fdd888c7ec74953193d66 https://gist.github.com/bkw777/ddde771cc85fdd888c7ec74953193... Used in anger: https://github.com/bkw777/pdd.sh 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]}}
captainbland 3y ago
I mean if it's good enough for python...
synergy20 3y ago
would love to see how poll() and select() etc work this way
- taviso 3y ago
  Here are some examples! https://github.com/taviso/ctypes.sh/blob/master/test/select.sh https://github.com/taviso/ctypes.sh/blob/master/test/select.... https://github.com/taviso/ctypes.sh/blob/master/test/poll.sh https://github.com/taviso/ctypes.sh/blob/master/test/poll.sh Yes, it is crazy :)

by taviso 3y ago

They should have used my (dumb?) library, ctypes.sh: https://github.com/taviso/ctypes.sh https://github.com/taviso/ctypes.sh Then they can access libm, poll(), select() and so on from bash :)

lagniappe 3y ago

woah that's cool :) also hello tavis

MrBuddyCasino 3y ago

I‘m not sure you should have done that, but it is impressive for the sheer chuzpa of it. Like reanimating Frankenstein.

jethro_tell 3y ago

Lol, holy shit what did I just read? Amazing, installing now. I want to be part of the problem.

Brian_K_White 3y ago

Awesome, but beside the point of writing something in bash that never needed to be in bash for any technical reason. Meaning if it requires bash plus some specially installed compiled c code, then it might as well require c or python or anything else and there is no point in calling it "written in bash", or writing it in mostly-bash-plus-special-plugin. I do know who I'm speaking to so please assume I say this respectfully. :) I have no problem with a "pointless" project like that as I'll show in a second. That said, this minecraft project itself relies on externals like xxd when it doesn't need to, so using ctypes.sh would be no worse in this case, so you are right, in this case they might as well have. But for the record it is possible to read, store, manipulate, do math on, and output binary in pure bash without anything like dd or xxd. 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/c1413d0e3de6c54524ddae890fe8d705 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/ddde771cc85fdd888c7ec74953193d66 https://gist.github.com/bkw777/ddde771cc85fdd888c7ec74953193... Used in anger: https://github.com/bkw777/pdd.sh 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]}}

captainbland 3y ago

I mean if it's good enough for python...

synergy20 3y ago

would love to see how poll() and select() etc work this way

taviso 3y ago
Here are some examples! https://github.com/taviso/ctypes.sh/blob/master/test/select.sh https://github.com/taviso/ctypes.sh/blob/master/test/select.... https://github.com/taviso/ctypes.sh/blob/master/test/poll.sh https://github.com/taviso/ctypes.sh/blob/master/test/poll.sh Yes, it is crazy :)