
Ctypes.sh – A foreign function interface for bash - afics
http://ctypes.sh/
======
1amzave
Neat...and on a somewhat similar note (bash enable -f hacks), some bash FUSE
bindings I wrote a few years back:
[https://github.com/zevweiss/booze](https://github.com/zevweiss/booze)

I initially wrote it basically just for giggles, but was rather pleased a few
months ago when I realized I could use it for something I actually needed, and
it was just the right thing (presenting a mount point that acted as a view of
the differences between two rsnapshot-style hard-link trees -- only took a few
dozen lines of very simple code).

------
AndyKelley
The problem with this project is that somebody might use it. I argue that if
you need to do something in bash that involves more than a sequence of
commands, including a simple if statement, then you should switch from bash to
a proper scripting language (python, perl, ruby, nodejs, take your pick.)

~~~
adrusi
I disagree. Shell scripts are great for automating system tasks — for
sysadminy type stuff, including tasks with high complexity with nested loops
and conditionals.

A scripting language like those you mentioned is great for if you need to run
your script on systems you don't control, or you need it to be cross platform,
or you'd describe what you're doing as creating software rather than
automating tasks.

No scripting language can ever integrate with the host system quite as well as
shell scripts can. Sure, shell scripts make it easy to shoot yourself in the
foot, but then can't you say the same of at least perl and ruby?

I don't really see many good use cases for this library though. By the time
you'd use it you should probably move on to something else.

~~~
AndyKelley
Can you give a shell script example of something that perl/python/ruby/nodejs
can't do?

~~~
e12e
> Can you give a shell script example of something that
> perl/python/ruby/nodejs can't do?

Install perl/python/ruby _and_ nodejs -- requiring just the shell to be
installed?

Snark aside (it's not _only_ snark - pretty much every system will have
something like a posix shell), proper posix portable shell is hard - it's an
old gnarly language -- but it's what we've got. And with a bit of discipline
and good practices -- it doesn't have to be bad. That said, a lot of real-
world shell scripts _are_ bad.

I tend to agree with the overall sentiment; shell isn't a great language. As
soon as you start to mix awk (which awk is that, do you need GNU awk?), sed
and perhaps a bit of egrep (or grep -E -- are both available? Does it accept
only BSD-style parameters?) -- one should consider moving "up".

And for eg: setting up a python package/program -- I'd generally prefer a
python script -- hopefully one that handles different file-paths (eg: / vs \ )
and other cross-platform stuff. If you already depend on python, why _add_
dependency on shell?

~~~
AndyKelley
> Install perl/python/ruby and nodejs -- requiring just the shell to be
> installed?

I just meant using any one of them, not all of them. And you can pretty much
always rely on python and perl being installed.

But my point is that if you're doing something other than a one-off thing,
then it belongs to some project and you're probably going to commit that
script to that project's codebase. That means it has to be maintained. Do
future you and whoever else has to maintain the project a favor and use one of
the popular scripting languages that has reasonable syntax and semantics.

~~~
e12e
Many minimal distributions have only the shell installed - which make it
(still) relevant for provisioning/bootstrap etc.

Personally I'd much rather maintain a shell script than a perl script - but
that's just because I know shell better. Maybe shell is the first language
people would program without learning it (js being the second)?

------
mzs
Some earlier discussion, people porting to FreeBSD and what not:
[https://news.ycombinator.com/item?id=9959628](https://news.ycombinator.com/item?id=9959628)

------
eximius
What could go wrong? /s

All sarcasm aside, a very interesting idea. I'm not sure what the proper use
case is, but I'm sure someone will love this.

~~~
eric_the_read
The best use-case I can think of is using bash as a REPL for C libraries. Many
times in the past, I've made library calls that either misinterpreted the
parameters or the result value. I would have loved the ability to prototype
those calls in bash until I understood them enough to call them properly.

~~~
michaelhoffman
You can use gdb as an REPL for C.

~~~
sea6ear
This blew my mind the first time some one showed me, and is one of the reasons
I currently prefer C to other mainstream compiled languages.

Edit: I suppose it is possible to get some version of a repl with C++
(Cling?), Java (Beanshell, Java 9?), C# (Mono, but not currently .Net?). But
each of those seems generally a bit harder to get access to than simply
calling gdb on a binary with debugging symbols enabled.

~~~
wvenable
C# has REPL in the immediate window when the debugger is running; so it's kind
of like using GDB as a REPL for C. Although it is somewhat limited in what you
can do.

~~~
sea6ear
That's actually really good to know about.

Visual Studio's a little bit heavyweight, but if you're programming C#,
there's a good chance that's what you're using anyway.

