Shell scripting is one of those skills that are absolutely invaluable on especially UNIX and BSD-based systems like the BSDs, the two zillion Linux distributions as well as MacOS. Yet not every shell is the same, and not everybody can be bothered to learn the differences between the sh, bash, ksh, zsh, dash, fish and other shells, which can make a project like Pnut seem rather tempting. Rather than dealing with shell scripting directly, the user writes their code in the Lingua Franca of computing, AKA C, which is then transpiled into a shell script that should run in any POSIX-compliant shell.
The transpiler can be used both online via the main Pnut website, as well as locally using the (BSD 2-clause) open source code on GitHub. Here the main limitations are also listed, which mostly concern the C constructs that do not map nicely to a POSIX shell. These are: no support for floating point numbers and unsigned integers, no goto and switch nor taking the address of a variable with &. These and preprocessor-related limitations and issues are largely to be expected, as especially POSIX shells are hardly direct replacements for full-blown C code.
As a self-professed research project, Pnut seems like an interesting project, although if you are writing shell scripts for anything important, you probably just want to buckle down and learn the ins and outs of POSIX shell scripting and beyond. Although it’s a bit of a learning curve, we’d be remiss if we said that it’s not totally worth it, if only because it makes overall shell usage even beyond scripting so much better.
This looks pretty usefull. Would be extra usefull If it were to compile into windows shell scripts as well.
“Aaaaaack! Pfft!”
-Bill the Cat
B^)
Somehow I had never realized that POSIX shell doesn’t have goto. Finally something that DOS is better at!
There are ways to fake GOTO in SH but they don’t always benefit readability.
Python for linux shell!
Now on animal planet😂
LOL!
python seemed like an easy language for coding noobs that they never seem to grow out of.
of course im a lua guy so i have my biases (i started with c though).
It’s called xonsh
No support for unsigned integers?
I am not even sure which languages are installed by default on my linux (20.3) box. At least I have Ruby, Perl, Python, GCC and the shell scripts, but there probably are more. I guess rust may have been added in newer
One thing I would like sometimes is to have a C interpreter (not a compiler) It does not have to be fully ANSI-C compliant, I could manage with some missing features. But this transpiler seems nice. I never really managed to bite though and learn the shell scripting syntax. I would also need a “useful project” to start programming at all. Writing some simple scripts in C, and then studying the this transpiler output can help in coughing up some motivation to learn the syntax. On the other side. C is not a great language for text and file manipulation. That may be a part of the reason that C interpreters (some do exist) have never gained much traction. It also make me wonder how this transpiler handles things that are a bit cumbersome to do in C, but easy in a shell script. For example using helper programs such as sed.
Have a look at tiny-cc. It’s still a compiler, but if used via `#!/path/to/tcc -run` as first line of the source, you can forget the compile step and using C boils down to edit/run cycles like in script languages.
https://repo.or.cz/w/tinycc.git
Btw.: Have a look at https://github.com/udem-dlteam/ribbit which drives that to some more dimensions.
try csh?
What do you get a tranpilled C program with pointers? A HellScript.
i understand the real purpose is a novelty. but i don’t see any utility to this. if you don’t want to learn the special limitations of your shell, you sure don’t want to learn the special limitations of a pidgin C-like language! in fact, that’s why csh and tcsh are universally reviled. they’re not good shells *and* they’re not good C.
in fact, i do sometimes use C to write things that seem more like they should be shell scripts. i do it mostly when i need to do byte-by-byte manipulation of strings. and in that case, compiling it to extremely slow shell code would be the last thing i’d want to do!
personally i have mostly avoided learning too much about shells but i have lately had to write some shell scripts that have to run everywhere and i run into a few bashisms that have crept into my dialect: {x,y} sequence expressions and [ ] instead of test. i appreciate that modern debian defaults to some decently-basic shell (lately, dash). i used to use bash for shell scripts and that really encouraged some bad habits, some embrace-and-extend