# Interactive commands

**URL:** <https://forum.ansible.com/t/interactive-commands/16794>\
**Category:** Ansible Project\
**Created:** [November 14, 2014, 8:59pm UTC](https://forum.ansible.com/t/interactive-commands/16794 "2014-11-14T20:59:33Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Thomas\_Quinot](https://avatars.discourse-cdn.com/v4/letter/t/ecd19e/32.png) [@Thomas\_Quinot](https://forum.ansible.com/u/Thomas_Quinot)\
**Post date:** [November 14, 2014, 8:59pm UTC](https://forum.ansible.com/t/interactive-commands/16794/1 "2014-11-14T20:59:33Z")

</div>

Redirecting from -devel as advised...

> I am considering managing some network equipment (switches) with the  
> 'raw' module. This requires sending commands to the switch in an  
> interactive session (command streamed before receiving the switch's  
> prompt are ignored), performing successive 'wait for prompt/send  
> command' steps [over a 'raw' ssh session]. Is there any existing support  
> for such interactive processing (generalizing the circuitry providing  
> optional stdin data)? If not, would there be interest in it?

(I am willing to prototype this if that's of interest).

> I guess this could apply to the 'raw', but also possibly 'shell' and  
> 'command' modules.

Thomas.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\
**Post date:** [November 17, 2014, 8:29pm UTC](https://forum.ansible.com/t/interactive-commands/16794/2 "2014-11-17T20:29:37Z")

</div>

Basically this isn’t going to end well.

The ‘raw’ module is useful for sending to devices that look like Unix shells, but some things are too weird to work this way.

The right way to go with Cisco is going to be to get modules speaking to OnePK or NXOS APIs - similar to what has happened with Juniper or Arista. (things like Cumulus don’t need them, because it’s got a real SSH environment we can use like Linux).

In any case, I don’t want to go down the ‘parse CLI’ path for Cisco, and we’re in touch with Cisco about modules for Ansible – but it’s been slow going.

If this is something people would like to work on instead, I’d be quite interested.

They should strive for something close to what the Juniper and Arista modules can do, I’d think.

---

<div class="post-metadata">

**Author:** ![Thomas\_Quinot](https://avatars.discourse-cdn.com/v4/letter/t/ecd19e/32.png) [@Thomas\_Quinot](https://forum.ansible.com/u/Thomas_Quinot)\
**Post date:** [November 18, 2014, 10:02am UTC](https://forum.ansible.com/t/interactive-commands/16794/3 "2014-11-18T10:02:10Z")

</div>

\* Michael DeHaan, 2014-11-17 :

> Basically this isn't going to end well.

Can you elaborate?

> The 'raw' module is useful for sending to devices that look like Unix  
> shells, but some things are too weird to work this way.

Right, hence the proposal to extend it to offer a chat-script-style  
facility.

> The right way to go with Cisco is going to be to get modules speaking to  
> OnePK or NXOS APIs - similar to what has happened with Juniper or Arista.  
> (things like Cumulus don't need them, because it's got a real SSH  
> environment we can use like Linux).
> 
> In any case, I don't want to go down the 'parse CLI' path for Cisco, and  
> we're in touch with Cisco about modules for Ansible -- but it's been slow  
> going.

We're not talking Cisco hardware here but Brocade switches, and various  
other devices with limited interactive access over SSH. This is for very  
specialized cases, and I doubt it would be worthwhile to create a  
specific module for each such niche device.

Thomas.