Live data from Hacker News

Pnut: A C to POSIX shell compiler you can trust

pnut.sh

81–90 of 124 posts

Re: Pnut: A C to POSIX shell compiler you can trust

#81

Earlier quoted context omitted.

Shell is just one way. There’s nothing that says we can’t do better than shell, but what it’s good at is saving programmer time when the need isn’t there for more, and Rust is definitely not good at that.

My rule of thumb: Shell: 500 lines Although to be honest I'd be perfectly happy if Shell was restricted to single line commands only. I've wasted a lot of time and energy deciphering undebuggable shell scripts that were written to "save programmer time". Not a fan.

My rule (and the code review policy I impose) emphasizes complexity instead - a 50 line shell script is great if it doesn't use if or case. (It's not so much of a strict rule as "once you're nesting conditionals, or using any shell construct that really needs a comment to explain the shell and not your code, you should probably already have switched to python." This is in parallel with "error handling in this case is critical, do you really think your bash is accurate enough?")

I wasn't the strictest reviewer (most feared, sure, but not strictest) at least partly because my personal line for "oh that bit of shell is obvious" is way too high.

Re: Pnut: A C to POSIX shell compiler you can trust

#82
post #72

Earlier quoted context omitted.

It would actually be interesting to see how much faster dash is than everything else.

Why is Dash frequently touted as so much faster than Bash? What is different?

It is much simpler (and therefore less resource-hungry) than bash.

Re: Pnut: A C to POSIX shell compiler you can trust

#83
post #19

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, 1, SEEK_HOLE); -> invalid code (uses undefined _lseek) socket(AF_UNIX, SOCK_STREAM, 0); -> same (uses undefined _socket) looking closer at "cp" and "cat" examples, write() call does not handle errors at all. Forget about partial writes, it does not even return -…

There seems to be libc in the repo but many functions are TODO 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

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.

Re: Pnut: A C to POSIX shell compiler you can trust

#84

When I'm told that "I can trust" something that I feel like I had no reason to distrust, it makes me feel even more suspicious of it

Perhaps you're old enough to remember the Sledge's[1] motto: “Trust me… I know what I'm doing.” HHBS Perusing the pnut site I did not understand either why this is software I can trust.

[1] https://www.imdb.com/title/tt0090525/

Re: Pnut: A C to POSIX shell compiler you can trust

#85
post #72

Earlier quoted context omitted.

It would actually be interesting to see how much faster dash is than everything else.

From our experience, ksh is generally faster, and dash sits between ksh and bash. One reason is that dash stores variables using a very small hash table with only 37 entries[0] meaning variable access quickly becomes linear as memory usage grows. But even with that, dash is still surprisingly fast -- when compiling `pnut.c` with `pnut.sh`, dash comes in second place: ksh93: 31s dash: 1m06s bash: 1m19s zsh: >15m [0]:…

People still use KornShell?

Re: Pnut: A C to POSIX shell compiler you can trust

#86

I love things like these because they shake our perception of normal loose. And who said our perception of normal doesn't deserve a good shake? A C to shell compiler might seem impractical, but you know what is even more impractical? Having a separate language for a build system. And yet, here we are. Using Shell, Make or CMake to build a C program is only acceptable because is has always been so. It's a "perceived n…

Have you tried Zig? Its build system is configured in the language. It’s actually a binary you build and run to build your project. Obviously the standard library has facilities for making building easy.

Re: Pnut: A C to POSIX shell compiler you can trust

#87
I am sorry if this comes off to be negative, but with every example provided on the site, when compiled and then fed into ShellCheck¹, generates warnings about non-portable and ambiguous problems with the script. What exactly are we supposed to trust?

¹ https://www.shellcheck.net

Re: Pnut: A C to POSIX shell compiler you can trust

#88
Also see this related submission from May, 2024:

Amber: Programming language compiled to Bash https://news.ycombinator.com/item?id=40431835 (318 comments)

---

Pnut doesn't seem to differentiate between `int' and `int*' function parameters. That's weird, and doesn't come across as trustworthy at all! Shouldn't the use of pointers be disallowed instead?

  int test1(int a, int len) {
    return a;
  }
  
  int test2(int* a, int len) {
    return a;
  }
Both compile to the exact same thing:

  : $((len = a = 0))
  _test1() { let a $2; let len $3
    : $(($1 = a))
    endlet $1 len a
  }
  
  : $((len = a = 0))
  _test2() { let a $2; let len $3
    : $(($1 = a))
    endlet $1 len a
  }
The "runtime library" portion at the bottom of every script is nigh unreadable.

Even still, it's a cool concept.

Re: Pnut: A C to POSIX shell compiler you can trust

#89
post #54

Earlier quoted context omitted.

Why would you need a screwdriver or a glass cutter if you already have a hammer?

With C, you have the whole toolbox and the toolbox factory.

> So we stopped selling those [hammer factory] schematics and started selling hammer-factory-building factories.

https://web.archive.org/web/20180722051250/http://discuss.jo...

Post reply on HN