Exec Sh Feature

[fr05t1k]

Demo:
https://youtu.be/6YJuKxVKi2s

Fixes #56

[bcicen]

This PR only works if the user has Docker on their local machine + the target container contains bash.

A much more acceptable approach would be implementing an arbitrary container exec feature in the connectors subpackage using the go-dockerclient library.

[fr05t1k]

@bcicen ok, I'll try a bit later. Anyway it works for my case :)

[pjvds]

executing the default shell is already a great step forward! 👍

[fr05t1k]

@bcicen I used API for executing but left sh command. I can add a check for global env variable and local env variable for overriding default shell. Like in Kitematic:
https://github.com/docker/kitematic/blob/master/src/components/ContainerDetailsSubheader.react.js#L100

[bcicen]

StopLoop() and Loop() are already handled when a menu is selected from Display(), so not necessary here

[bcicen]

Looking much better!

Rather than forcing a default shell globally for all containers, it might make more sense to make this a generic exec menu option/method, with a second input menu presented, pre-filled with the default shell, but allowing the user to modify/input a custom command as well.

[fr05t1k]

Looking much better!

Rather than forcing a default shell globally for all containers, it might make more sense to make this a generic exec menu option/method, with a second input menu presented, pre-filled with the default shell, but allowing the user to modify/input a custom command as well.

Good idea. I'll do it.

BTW there are still some artifacts with terminal rendering through direct stdout. I'm trying to solve it.

[bcicen]

FYI, after making some updates to handle potentially empty frames when first attached, I've merged your branch here. Thanks again!

[fr05t1k]

It still has artifacts. I don't think that this feature is ready for production.

Artifacts which I found:

• terminal cursor is not blinking
• screen size isn't correct
• some events propagate to ctop itself

[bcicen]

screen resizing might be difficult without stopping termui entirely -- if possible, it might be ideal to close and reopen std{out,in} descriptors when entering and leaving each exec session, re-initializing termui entirely

[bcicen]

in addition to artifacts, most combination key presses are being filtered from the stdin stream as well. The above mentioned solution of handing full stream control over to the exec thread is likely the only option that will handle all the edge cases that come with subprocess shell usage.