search

taviso / ctypes.sh

A foreign function interface for bash.
MIT License
2.11k stars 92 forks source link

support for bash without exported symbols #23

Open taviso opened 9 years ago

taviso commented 9 years ago

It may be possible to support incorrectly built bash binaries that are very stable (for example, Apple's). We could hash the binary, and if it matches a binary we know about it use a pre-generated symbol.map.

Is it worth all the extra complexity to support OS X? On the one hand, this is an Apple bug that they should fix (they built bash incorrectly, a feature that is supposed to work doesn't) - on the other hand, it seems unlikely they'll fix a bug in such an obscure feature for at least a few years.

cemeyer commented 9 years ago

Hm, where would you get such a symbol.map for it? Or do Apple ship debug symbols you could generate such a thing with?

taviso commented 9 years ago

Yes, I think using debug symbols will work, will just have to create a bunch of pointers to the symbols we need. It's a bit ugly, and I don't know if many Mac users are interested in this...

cemeyer commented 9 years ago

That's cute. I'm for it. Seems to be much in the spirit of ctypes.sh ;).

I wonder if instead of changing the code too much, we could just add a bash-compat.c shim that only weakly provides the bash exported symbols and looks them up and proxies the calls if actually invoked?

taviso commented 9 years ago

OK, let's try to get support for OS X in the first release (or at least investigate the possibility...) :)

block #17