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

51–60 of 124 posts

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

#51

Post by okaleniuk »

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 normality" in the C world.

There is no good reason, however, CMake isn't a C library. With build system being a library, we could write, read, and, most importantly, debug build scripts just like any other part of the buildable. We already have includeOS, why not includeMake?

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

#52

Post by osmsucks »

n_plus_1_acc wrote: post #48
osmsucks wrote: post #42

Earlier quoted context omitted.

Since I experimented with something similar in the past to mimick multidimensional arrays: depending on the implementation this can absolutely _kill_ performance. IIRC, Dash does a linear lookup of variable names, so when you create tons of variables each lookup starts taking longer and longer.

I hope you're not compiling C to sh for performance reasons.

It's not about performance, it's about viability. If the result is so slow that it's unusable, it doesn't matter how portable it ends up being.

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

#53

Post by blueflow »

teo_zero wrote: post #33

Just to be clear, the input must be written in a subset of C, because many constructs are not recognized, like unsigned types, static variables, [] arrays, etc. Is there a plan to remove such limitations?

These are restrictions of the target language and there isn't much pnut can do about this.

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

#54

Post by bregma »

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…

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

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

#55

Post by okaleniuk »

bregma wrote: post #54
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…

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.

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

#56

Post by defrost »

okaleniuk wrote: post #55
bregma wrote: 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.

Both the tweezers and the bit flipping magnet .. and who would want anything more?

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

#57

Post by RHSeeger »

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…

> you know what is even more impractical? Having a separate language for a build system

Why is it you think that?

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

#58

Post by Someone »

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.

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/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

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

#59

Post by rwmj »

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.

head was used for this purpose in the xz backdoor.
Post reply on HN