Skip to content


Subversion checkout URL

You can clone with
Download ZIP


`gem install --wrappers` parses scripts written in languages other than ruby. #830

geoff-codes opened this Issue · 3 comments

2 participants


It appears that the way gem install -w wrappers are implemented, gem tries to parse and load scripts written in other languages, even with an explicit non-ruby shebang.

I wasn't sure if this was a bug (i.e., if one were even allowed to add a shell script to executables),
but the docs read:

The executable file itself just needs a shebang in order to figure out what program to run it with.

This affects this pull request of mine to linguist.

If you install without using wrappers, it works fine, but with them:

/usr/local/ruby/bin/shebangalang:23:in `load': /usr/local/ruby/gems/github-linguist-2.10.11/bin/shebangalang:12: syntax error, unexpected ';', expecting :: or '[' or '.' (SyntaxError)
for last; do :; done # So we can put a newline between files.
/usr/local/ruby/gems/github-linguist-2.10.11/bin/shebangalang:15: syntax error, unexpected tGVAR, expecting ']'
[ "$(language "$0")" = "sh" ] || return 1; [ $# = 0 ] && return 0
    from /usr/local/ruby/bin/shebangalang:23:in `<main>

I just realized this is kind of a once-in-a-lifetime, mutually recursive bug/fix:

In a sense, the bug occurs in a file that was written (completely coincidentally) to address the very same issue it caused (more generally). It could basically patch itself. Too bad linguist has so many deps.


The documentation on is incorrect here. Entries in a Gem::Specification's executables list must be ruby scripts. I will leave this open as a reminder to update the documentation.

@drbrain drbrain added this to the 2.3 milestone

Ah ok. That had been my first guess. But that "just needs a shebang" line seemed to directly say the opposite.

@geoff-codes geoff-codes referenced this issue in github/hub

hub + gh = GitHub CLI #475

3 of 3 tasks complete
@geoff-codes geoff-codes referenced this issue from a commit in pullreq/rubygems
Geoff Nixon Support arbitrary `executables` with bin-wrappers.
This PR is a proposal to address issue #830.

With due respect, I'd like to [question](rubygems#830 (comment)):
> The documentation on is incorrect here. Entries in a Gem::Specification's executables list must be ruby scripts.

Unless this is an intentional change to implement a restriction, this definitely seems more likely implementation rather than documentation. I took some time and examined all the executables installed to `bin` from the ~350 gems I have installed, and there are more than a few that install linked binaries, not scripts. With the wording in the documentation, and the fact that this isn't an issue without bin-wrappers, I thought I'd look at the code, and it seems to me that the change I propose here would fix my issue without affecting the execution of ruby executables. I've changed all the bin wrappers I have installed to `exec` instead of `load` like this, and tested with IO, args, etc., and there appears to be no difference in behavior -- is there some reason why `load` must be used that I'm missing?

If not, this would really be a great feature/patch for me -- while I can, of course, put scripts in other languages in heredocs and exec them myself, this basically means I have to write my own wrappers, just to support `wrappers`.
@drbrain drbrain closed this in c7c0452
@zzak zzak referenced this issue from a commit in zzak/rubygems
@drbrain drbrain Document that executable may only be ruby scripts
Fixes #830
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.