summaryrefslogtreecommitdiff
path: root/.rubocop.yml
diff options
context:
space:
mode:
authorBundlerbot <bot@bundler.io>2019-04-29 21:01:59 +0000
committerBundlerbot <bot@bundler.io>2019-04-29 21:01:59 +0000
commit896269a45902f587bb722ebbd50dbf1eeee9d25b (patch)
treea3bbed61edcf231ecc23cc0eb83021142ba4c066 /.rubocop.yml
parentbf75350506d0b6bc8b7f545d1d478ff7095516db (diff)
parenta7d54670f2be0ae31569028d759739f44fd23c8a (diff)
downloadbundler-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