Spur chokes on return code

[dueyfinster]

Hi @mwilliamson sorry to annoy again, but I've come across another issue in https://gist.github.com/dueyfinster/5249858 (stack trace within)where Spur gets a return code of null and chokes on it. I'm not sure why this particular server does that (all the rest work fine). I've checked profile, bashrc, cshrc etc

I can use https://gist.github.com/dueyfinster/5249878 to get on to the same server though. Strange

[mwilliamson]

It seems that the call to which isn't working on that server. What happens if you try running which ls manually over SSH?

Before running the command in question, spur runs which to check that the command exists, the idea being that this gives clearer error messages when things go wrong. In retrospect, this might turn out to have been a bad choice given the issues using which causes. Alternatives:

• Only run which if a command fails i.e. use which to determine the cause of failure rather than running which beforehand
• Don't bother trying to detect commands that don't exist when using SSH, and assume that the error message that the shell provides will be good enough
• When connecting, run a command that's guaranteed not to exist (such as a random UUID), and use that to detect when commands don't exist. This isn't foolproof in the sense that an application with that name might also print exactly the same message, but this seems sufficiently unlikely not to be a concern. More concerning is the assumption that error messages when commands don't exist are consistent enough that they can be automatically detected (for instance, Ubuntu also checks to see if there's a package containing that command)

[dueyfinster]

Hi @mwilliamson , I've run that:

test@localhost:~$ ssh root@testserver -p 22 -i /home/test/.ssh/id_rsa "which ls"
ls:      aliased to ls -F
test@localhost:~$

I'm familiar with the ubuntu messages - this is solaris again. I'm not sure of the best approach either. Thanks for the reply - if I can provide any more info, let me know.

[mwilliamson]

Hmm, looking a little more closely at the error, it seems that there's an unexpected blank line in the output that I can't explain. Anyway, I've just uploaded 0.3.5 which ignores blank lines when it's expecting a echoed return code, so that might solve your issue. I've also switched to using the POSIX compliant command -v instead of which, although I'm not sure that has anything to do with the error in this case.

If it's still not working, we can try investigating further. Hope that helps!

[dueyfinster]

I have tested it and am getting proper error codes on other servers. Still a similar issue with this one server though (SuSe Linux), it seems to stall on (with key login):

shell.run(["echo", "$0"])

(or any command). Could also be something stupid I'm doing. I'll look in to it more. Thanks for the updates, error messages are a lot clearer.

[mwilliamson]

Closing since there doesn't seem much to be done -- please feel free to reopen if you're still having trouble or can provide error messages.