Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
geoff-codes opened this Issue · 3 comments

2 participants

Geoff Nixon Eric Hodel
Geoff Nixon

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>
Geoff Nixon

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.

Eric Hodel
Owner

The documentation on guides.rubygems.org 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.

Eric Hodel drbrain added this to the 2.3 milestone
Geoff Nixon

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

Geoff Nixon geoff-codes referenced this issue in github/hub
Closed

hub + gh = GitHub CLI #475

3 of 3 tasks complete
Geoff Nixon 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 guides.rubygems.org 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`.
6016ad4
Eric Hodel drbrain closed this in c7c0452
Zachary Scott zzak referenced this issue from a commit in zzak/rubygems
Eric Hodel drbrain Document that executable may only be ruby scripts
Fixes #830
709c5aa
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.