Allow execution of hubot command from CLI

[patcon]

I'm interested in programmatically running some quick hubot commands in the interest of auto-generating documentation.

Ideally, would be great to add an argument to the shell adapter that would allow this (with the sample script):

$ bin/hubot -u user1 -e "hubot: hello"
user1: hello!
$ bin/hubot -u user1 -e "and so I says to the guy 'orly you don't say'"
yarly

[patcon]

Or this would be satisfactory, if anyone is aware of a simple tweak to make it work:

$ echo "hubot: hello" | bin/hubot
Hubot> hubot: hello
Hubot> Shell: hello!

[technicalpickles]

Yeah, this would definitely be useful 👍

It'd probably be easier to do this with the -e (or whatever flag). That way, you could invoke it before trying to actually parse send/receive messages from the console.

[patcon]

Awesome. I'll investigate when I get some time!

[bayleedev]

@patcon are you wanting this for testing purposes? If so, I think this can be closed. If not, can you further explain your use case?

[coderofsalvation]

Some good old unix-fu gets it done already:

expect -c 'spawn bin/hubot.coffee;sleep 3;expect "Hubot>";send "hubot help\n";expect eof'

ps1. run 'apt-get install expect' in case you get 'expect: command not found'
ps2. the sleep is needed because hubot/js is asynchonous.

[technicalpickles]

This doesn't directly address the command line execution, but #800 added persisted history to the shell adapter. That way, you can quit and restart hubot, press up to get the last command, and re-run it.

[coderofsalvation]

@technicalpickles nice to meet you, but are you sure you read patcon's request?

"I'm interested in programmatically running some quick hubot commands"

I guess you were more thinking about your own manual usecases?
(because I don't really see how pressing an up-button would forfill patcon's desire)

Anyways, afaik he would like the shell-adapter to accept messages from commandline invocation.
He could try this adapter which can run next to his mainadapter (instead of replacing it).
Another option would be to patch his adapter- or hubotcode himself and use environment variables for it, e.g.:

USER="foo" CMD="hubot help" bin/hubot 

by doing so he can easily use 'process.env.USER' and 'process.env.CMD' in his patch.

[technicalpickles]

@coderofsalvation I am sure I read it, thank you! I only mentioned what I did because it is a similar realm of making hubot development easier.

Supporting something like using the shell adapter is going to be difficult to handle because of the async nature of javascript. Once a message is received in the robot, all the listeners are invoked. Those listeners could do something asynchronously (ie a simple setTimeout). The listener would finish being called, but the asynchronous can still be waiting.

Given that, a single message being processed, there's no good way to know when the listener is really done right now. There's some async libraries out there to help with that (I have one in mind, but can't place it right now), where you call a done function when everything is done, but that would require updating lots of scripts to take advantage of it.

[coderofsalvation]

@technicalpickles Thanks for your reply. I fully agree with your observations. That's why i mentioned the hubot-http-script npm package. It uses hubot's express-implementation, which seems to work around this the async-issue already.

[geoffreyanderson]

I wonder if this might help with problems that folks are encountering from some IDEs when trying to run in debug mode (like #648). At present, you need to run node-inspector and then invoke hubot through coffeescript with a --nodejs --debug flag in order to start walking the code. Having a syntax to directly invoke a command on bot execution (e.g. bin/hubot -e "hubot: ping") might simplify some specific testing/debug cases from an IDE perspective. It's also possible that these IDEs just need to fix their darn debugger integration and then maybe this isn't as necessary.

[ericdorsey]

I would like to see this feature too!

+1 to @coderofsalvation's unix-foo in the meantime, that worked for me (ie, the expect command)

[coderofsalvation]

thnx. For anyone interested, meanwhile i use:

$ ./hubottest mustache me chucknorris

as i turned it into a commandscript hubottest

[technicalpickles]

I mentioned knowing when a script was done was one problem. I mention another over in #904

Adapters must emit a 'connected' event at some point, bin/hubot has a listener for that event to actually load scripts (https://github.com/github/hubot/blob/master/bin/hubot#L128-L133). Feasibly could add another event to robot like 'scriptsLoaded', that the adapter could listen for.

Basically, hubot doesn't currently know when the scripts are loaded, so that it could robot.receive a message from the command line.

[mose]

The expect solution with a generous sleep seems to make the trick. I'm going to close this issue :)