Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pnut: A C to POSIX shell compiler you can trust

pnut.sh

Post reply on HN
Print view View original

71–80 of 124 posts

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

#71

Post by hnlmorg »

actionfromafar wrote: post #69
hnlmorg wrote: post #47

Earlier quoted context omitted.

> I cant run cosmolibc on Android, for example. You can: https://justine.lol/cosmo3/ > After nearly one year of development, I'm pleased to announce our version 3.0 release of the Cosmopolitan library. [...] we invented a new linker that lets you build fat binaries which can run on these platforms: AMD ... ARM64 https://github.com/jart/cosmopolitan/releases/tag/3.5.3 > This release fixes Android support. You can now…

Can you run it on RISCV Android?!

No, but Android on RISC-V isn’t even considered stable. So you’ll be manually compiling a fair chunk of code to get it running. Adding a few extra tools to your build pipeline isn’t going to be a deal breaker.

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

#73

Post by [deleted] »

wahern wrote: post #14

This is very cool, regardless of how serious it was intended to be taken. Before base-64 encoders/decoders became more common as preinstalled commands in the environments I found myself on, I wrote a base64 utility in mostly pure POSIX shell: https://25thandClement.com/~william/2023/base64.sh If this project had existed I might have opted to compile my C-based base-64 encoder and decoder routines, suitably tweaked fo…

[deleted]

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

#74

Post by hun3 »

oguz-ismail wrote: post #36
PhilipRoman wrote: post #28

Earlier quoted context omitted.

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

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/V... >). I doubt non-GNU implementations support it though.

I think dd might be more reliable. (Is dd POSIX?)

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

#75

Post by throwaway2037 »

chasil wrote: post #72
itvision wrote: post #62

Instantly make your C code 200 times slower without any effort!

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?

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

#76

Post by MobiusHorizons »

luism6n wrote: post #12
forrestthewoods wrote: post #7

Hrmmm. But why? Quite frankly I think Bash scripting is awful and frequently wish shell scripts were written in a real and debuggable language. For anything non-trivial that is. I feel like I’d rather write C and compile it with Cosmopolitan C to give me a cross-platform binary than this. Neat project. Definitely clever. But it’s headed in the opposite direction from what I’d prefer...

I'm not the OP, but I think the goal is to make it cross architecture. Cross platform C compiler would give you cross OS compatibility, but chip architecture would still be fixed, I think. I.e., you can take your compiled.sh and run in an obscure processor with an obscure OS, as long as it's POSIX, it should work...

I believe the goal is to defeat the compiler trust thought exercise where a malicious compiler could replicate itself when being asked to compile the compiler. Since this produces human readable code instead of assembly, the idea is it allows bootstrapping a trusted compiler, since pnut.sh and any output shell executables are directly auditable.

I suppose the trust moves to the shell executable then, but at least you could run the bootstrapping with multiple shells and expect identical output.

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

#77

Post by throwaway2037 »

voidUpdate wrote: post #39

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

Yeah, I cringed when I saw that too. It violates an important rule of selling: Never tell the customer "Trust me".

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

#78

Post by laurenth »

chasil wrote: post #72
itvision wrote: post #62

Instantly make your C code 200 times slower without any effort!

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]: https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/...

EDIT: ksh93, not ksh

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

#79

Post by taviso »

laurenth wrote: post #3
o11c wrote: post #2

It's a bad sign when I immediately look at the screenshot and see quoting bugs.

Author here, Because all shell variables in code generated by pnut are numbers, variables never contain whitespace or special characters and don't need to be quoted. We considered quoting all variable expansions as this is generally seen as best practice in shell programming, but thought it hurt readability and decided not to. If you think there are other issues, please let me know!

I think they're talking about the cp example, doesn't seem like it would handle filenames with spaces!

Super neat project, btw!

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

#80

Post by eichin »

okaleniuk wrote: post #51

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…

DSLs ("microlanguages", at the time) were a big idea in the late 80s - by being expressive in ways closer to the problem, they could leave out irrelevant things and the bugs they lead to. (Do you really want to have to explicitly call malloc() in your build tools? and does gdb really feel like the right tool for debugging one?)
Post reply on HN