which: no sudo in ... #1321

Closed
jwfearn opened this Issue Jul 28, 2011 · 14 comments

Projects

None yet

6 participants

@jwfearn
jwfearn commented Jul 28, 2011

Certain Bundler operations generate message: "which: no sudo in.;C:\Ruby187\bin;C:\Ruby187\lib\ruby\gems\1.8\bin;...".

Error seems to be benign (operations appear to complete correctly.) I actually do have an executable named 'which'. Perhaps Bundler is assuming there is no such command on WIndows? The message text above is exactly what one would see if one were to do which sudo on my system.

Example:

$ ruby -v
ruby 1.9.2p290 (2011-07-09) [i386-mingw32]
$ bundle -v
Bundler version 1.0.15
$ bundle install
Fetching source index for http://rubygems.org/
which: no sudo in (.;C:\Ruby192\bin;...
Using rake (0.9.2)
Using multi_json (1.0.3)
...

@jwfearn
jwfearn commented Jul 28, 2011

BTW: the -v flag to bundle is not documented in bundle help

@Zequez
Zequez commented Aug 19, 2011

Just change the name or delete the which.exe from cygwin/bin, worked for me ^^

@sandrods

having the same problem here, in a Gentoo box

@indirect
Member

Bundler is looking for sudo. If there is some way to suppress the error that is printed, I would be happy to do that.

@indirect indirect closed this Sep 18, 2011
@jwfearn
jwfearn commented Sep 18, 2011

Perhaps Bundler is using the existence of 'which' as a way to test if it's running on a Unix-like system? As mentioned, bug occurs on a WINDOWS system that also happens to have installed a program called WHICH.EXE that works like its Unix equivalent. If the logic is to call 'which' and assume existence of such a command indicates Unix, that logic would be incorrect.

@indirect
Member

No, that's not what's going on. Bundler is using the which command to look for the sudo command. On Windows machines with no sudo (and in fact on ANY machine with no sudo), the which command will print to STDERR. I don't know how to suppress STDERR on Windows machines. Can you patch the requires_sudo? method in bundler.rb to suppress the error printed by which? I would love to apply that patch. Thanks!

@sleeper sleeper added a commit to sleeper/bundler that referenced this issue Nov 3, 2011
@sleeper sleeper Fix issue #1321 -- which output on stderr
bundler checks for sudo availability by using which.
Depending on the platform or distribution, which output an
error message on stderr in case sudo is not found.

This fix redirect stderr to /dev/null. Agreed this is a *nixish way to
fix it, but as on other platforms (Windows) which does not exists anyway
...
22fdc8d
@sleeper
sleeper commented Nov 3, 2011

Hi

I just sent a pull-request to fix this issue (only a warning but odd-one from my point of view).

Regards,

@sleeper sleeper added a commit to sleeper/bundler that referenced this issue Nov 3, 2011
@sleeper sleeper Fix issue #1321 in a ruby-esque way ;) aa3735c
@betelgeuse

@indirect should this issue be reopened as there is now a pull request that is open?

@indirect
Member

I don't think so... The pull request is an issue. We don't need two.

@sleeper
sleeper commented Dec 10, 2011

Totally closed as fixed by pull request #1573 ... Seems like some commiters are luckier than other ... Same fix proposed beg of Dec and merged the very same day ... Mine, opened on beg of Nov, has not even been looked at ... Next time, I'll waste my time on other projects.

@indirect
Member

I haven't had time to look at either pull request yet. Someone else with commit accepted a pull from a well-known open source contributor. It happens.

If this comment is representative of your attitude towards people donating their time to maintain OSS, please work exclusively on other projects. Thanks.

On Dec 9, 2011, at 2:10 PM, Frederick Rosreply@reply.github.com wrote:

Totally closed as fixed by pull request #1573 ... Seems like some commiters are luckier than other ... Same fix proposed beg of Dec and merged the very same day ... Mine, opened on beg of Nov, has not even been looked at ... Next time, I'll waste my time on other projects.


Reply to this email directly or view it on GitHub:
#1321 (comment)

@sleeper
sleeper commented Dec 10, 2011

No, it is not representative ... but it just that I've been astonished that my first pull request has been rejected the minute following its creation ... the second one has been closed by myself 1 month after.

@indirect
Member

I appreciate your willingness to rework your patch into something that I could accept -- I have been especially swamped with other work for the last 5 or 6 weeks, and haven't been able to review any patches during that time. I can't speak for any other committers, but I was planning on testing and merging your patch when my schedule opened up next week.

I'm sorry that you feel like you wasted your time, sometimes things just work out that way I guess. :(

@sleeper
sleeper commented Dec 10, 2011

Agreed.. but my remark was not directed toward anybody specially. I know that this is hard work contributing to a project. In the end, what matters is that the bug has been fixed and the performances improved ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment