diff options
author | Bundlerbot <bot@bundler.io> | 2019-04-29 21:01:59 +0000 |
---|---|---|
committer | Bundlerbot <bot@bundler.io> | 2019-04-29 21:01:59 +0000 |
commit | 896269a45902f587bb722ebbd50dbf1eeee9d25b (patch) | |
tree | a3bbed61edcf231ecc23cc0eb83021142ba4c066 /.rubocop.yml | |
parent | bf75350506d0b6bc8b7f545d1d478ff7095516db (diff) | |
parent | a7d54670f2be0ae31569028d759739f44fd23c8a (diff) | |
download | bundler-896269a45902f587bb722ebbd50dbf1eeee9d25b.tar.gz |
Merge #7140
7140: Get `bundle exec` respecting proc titles r=deivid-rodriguez a=deivid-rodriguez
### What was the end-user problem that led to this PR?
The problem was that `bundle exec` would not respect custom proctitles inside scripts.
### What was your diagnosis of the problem?
My diagnosis was that the previous code was using the third form of `Kernel.exec`, documented as:
> In the third form (exec(["command", "argv0"], "arg1", ...)), starting a two-element array at the beginning of the command, the first element is the command to be executed, and the second argument is used as the argv[0] value, which may show up in process listings.
See https://ruby-doc.org/core-2.6.3/Kernel.html#method-i-exec.
However, since this form messes with proc titles, it seems to affect scripts settting their own proc titles.
### What is your fix for the problem, implemented in this PR?
My fix is to use the simpler form:
> In the second form (exec("command1", "arg1", ...)), the first is taken as a command name and the rest are passed as parameters to command with no shell expansion.
We were not passing any special proc title, so I don't think we need the third form, and this simpler form allows custom proc titles inside scripts to work just fine.
### Why did you choose this fix out of the possible options?
I chose this fix because I couldn't figure out a better one.
Closes #7135.
Co-authored-by: David RodrÃguez <deivid.rodriguez@riseup.net>
Diffstat (limited to '.rubocop.yml')
0 files changed, 0 insertions, 0 deletions