3 ms·

If you are wondering how it handles C-only functions.. it does not. open(..., O_RDWR | O_EXCL) -> runtime error, "echo "Unknow file mode" ; exit 1" lseek(fd,

• PhilipRoman 2y ago
  Implementation issues aside, while technically it should be possible to seek a file descriptor from shell through a suitable helper program in C, I believe none of the POSIX utilities provide this facility
  • oguz-ismail 2y ago
    head, read, and sed can be used for seeking forward according to POSIX (see the INPUT FILES section here <https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap01.html#tag_18_04 https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V...>). I doubt non-GNU implementations support it though.
    • rwmj 2y ago
      head was used for this purpose in the xz backdoor.
    • Someone 2y ago
      If it’s in POSIX, chances are the BSDs implement it, too. I think seeking a specific number of bytes and then writing data there will be a problem, though. For seeking n bytes, read nor sed will work; they work with lines. sed is the only one of those that can write, and POSIX doesn’t appear to have the -i option for in-place editing (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s...) So, I think head for seeking followed by sed (or ed or vi, but sed is the simpler tool, I think) for replacing the first n characters, redirecting to a temp file and then doing a mv is your only option. Advantage will be that writes will be atomic; disadvantage that it will be slow
    • hun3 2y ago
      I think dd might be more reliable. (Is dd POSIX?)
      • rmwaite 2y ago
        Yep: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/d...
• x5a17ed 2y ago
  maybe access to libc functions can be achieved through something like <https://github.com/taviso/ctypes.sh https://github.com/taviso/ctypes.sh>. Although that very specific implementation seems to require explicitly bash and is not broadly POSIX Shell compatible as Pnut wants to be.
• Cloudef 2y ago
  There seems to be libc in the repo but many functions are TODO https://github.com/udem-dlteam/pnut/tree/main/portable_libc https://github.com/udem-dlteam/pnut/tree/main/portable_libc Otherwise the builtins seems to be here https://github.com/udem-dlteam/pnut/blob/main/runtime.sh https://github.com/udem-dlteam/pnut/blob/main/runtime.sh FYI all your functions are not "C functions", but rather POSIX functions. I did not expect it to be complete, but it's still impressive for what it is.
  • westurner 2y ago
    There are Linux ports of the plan9 `syscall` binary, which is presumably necessary to implement parts of libc with shell scripts: https://stackoverflow.com/questions/10196395/os-system-calls-from-bash-script/76524660#76524660 https://stackoverflow.com/questions/10196395/os-system-calls... I don't remember there being a way to keep a server listening on a /dev/tcp/$ip/$port port, for sockets from shell scripts with shellcheck at least
• vlovich123 2y ago
  I suspect the “trust” is a reference to Ken Thompson’s Turing Award speech “Reflections on trusting trust” where he laid out the concern of a back door in a compiler that survives updates to the compiler. In other words, the compiler injects a back door into future versions of itself in addition into your programs that source level analysis of the code will never reveal. I think the pitch here is that it can compile TCC which can then compile GCC which makes it much more difficult for a backdoor to survive potentially, especially if the shell code is easier to read and verify than the corresponding assembly. Within that context, an incomplete libc is irrelevant.