5 ms·

Ctypes.sh – A foreign function interface for bash

94 points by afics 11y ago

eximius 11y ago
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 11y ago
  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 11y ago
    You can use gdb as an REPL for C.
    - sea6ear 11y ago
      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 11y ago
        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 11y ago
        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.
      - shanemhansen 11y ago
        beanshell is quite painful. I like using the repl of a jvm language to explore classes and methods. Like slime+clojure or groovysh or jruby.
    - eric_the_read 11y ago
      My gdb-fu is weak, but don't you have to have a binary that you're debugging to do that? I'm thinking of this as more of an exploratory thing-- poking around the edges of an API until I feel comfortable enough with it to start writing real code.
      - michaelhoffman 11y ago
        Sure, but you could compile: #include <my_api.h> int main() { return 0; }
    - jhallenworld 11y ago
      Reminds me of vxworks: the main shell for the operating system is the debugger.
  - shanemhansen 11y ago
    When I need a C repl, I often use python and ctypes.
- geofft 11y ago
  There are a couple of weird APIs like unshare(2) where it matters that you do things in the shell itself, not in a process spawned by a shell. (chdir(2) might be an even better example, come to think of it.) I once wrote a bash plugin for playing with unshare(2) specifically. That said, unshare(1) now supports `-r` with `-U`, which was the thing I needed.
1amzave 11y ago
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).
mzs 11y ago
Some earlier discussion, people porting to FreeBSD and what not: https://news.ycombinator.com/item?id=9959628 https://news.ycombinator.com/item?id=9959628
AndyKelley 11y ago
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 11y ago
  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.
  - dragonwriter 11y ago
    > No scripting language can ever integrate with the host system quite as well as shell scripts can. What is the basis for this? Shell script is a scripting language (more precisely, a set of scripting languages with similar features.) The difference between shell scripting languages and other scripting languages is that the former are optimized around the need to scale down to a convenient line-by-line way to work with the system in a REPL; while the others may support work in a REPL it is not what they are optimized for. There's no real reason why other scripting languages can't integrate with the system as well as shell languages.
    - AnimalMuppet 11y ago
      >> No scripting language can ever integrate with the host system quite as well as shell scripts can. > What is the basis for this? Shell script is a scripting language (more precisely, a set of scripting languages with similar features.) The difference between shell scripting languages and other scripting languages is that the former are optimized around the need to scale down to a convenient line-by-line way to work with the system in a REPL; while the others may support work in a REPL it is not what they are optimized for. Disagree. The defining characteristic of shell scripting languages is that they are a shell that can be scripted. What's a shell? It's a program designed to be a layer around the OS, exposing all of the capabilities of the OS to the user in a convenient form. So the only way a non-shell scripting language can become that powerful is to become a shell scripting language.
deleted 11y ago
[deleted]

94 points by afics 11y ago

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 11y ago
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 11y ago
  You can use gdb as an REPL for C.
  - sea6ear 11y ago
    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 11y ago
      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 11y ago
        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.
    - shanemhansen 11y ago
      beanshell is quite painful. I like using the repl of a jvm language to explore classes and methods. Like slime+clojure or groovysh or jruby.
  - eric_the_read 11y ago
    My gdb-fu is weak, but don't you have to have a binary that you're debugging to do that? I'm thinking of this as more of an exploratory thing-- poking around the edges of an API until I feel comfortable enough with it to start writing real code.
    - michaelhoffman 11y ago
      Sure, but you could compile: #include <my_api.h> int main() { return 0; }
  - jhallenworld 11y ago
    Reminds me of vxworks: the main shell for the operating system is the debugger.
- shanemhansen 11y ago
  When I need a C repl, I often use python and ctypes.
geofft 11y ago
There are a couple of weird APIs like unshare(2) where it matters that you do things in the shell itself, not in a process spawned by a shell. (chdir(2) might be an even better example, come to think of it.) I once wrote a bash plugin for playing with unshare(2) specifically. That said, unshare(1) now supports `-r` with `-U`, which was the thing I needed.

1amzave 11y ago

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).

mzs 11y ago

Some earlier discussion, people porting to FreeBSD and what not: https://news.ycombinator.com/item?id=9959628 https://news.ycombinator.com/item?id=9959628

AndyKelley 11y ago

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 11y ago
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.
- dragonwriter 11y ago
  > No scripting language can ever integrate with the host system quite as well as shell scripts can. What is the basis for this? Shell script is a scripting language (more precisely, a set of scripting languages with similar features.) The difference between shell scripting languages and other scripting languages is that the former are optimized around the need to scale down to a convenient line-by-line way to work with the system in a REPL; while the others may support work in a REPL it is not what they are optimized for. There's no real reason why other scripting languages can't integrate with the system as well as shell languages.
  - AnimalMuppet 11y ago
    >> No scripting language can ever integrate with the host system quite as well as shell scripts can. > What is the basis for this? Shell script is a scripting language (more precisely, a set of scripting languages with similar features.) The difference between shell scripting languages and other scripting languages is that the former are optimized around the need to scale down to a convenient line-by-line way to work with the system in a REPL; while the others may support work in a REPL it is not what they are optimized for. Disagree. The defining characteristic of shell scripting languages is that they are a shell that can be scripted. What's a shell? It's a program designed to be a layer around the OS, exposing all of the capabilities of the OS to the user in a convenient form. So the only way a non-shell scripting language can become that powerful is to become a shell scripting language.

deleted 11y ago

[deleted]