Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

execute and run_command methods features #377

Open
YonatanNachum opened this issue Apr 1, 2023 · 0 comments
Open

execute and run_command methods features #377

YonatanNachum opened this issue Apr 1, 2023 · 0 comments

Comments

@YonatanNachum
Copy link

Hey all,
I can't understand why the design was to create the public "run_command" method in BaseSSHClient class and public "execute" command in the SSHClient class. This methods are very similar and the use of them is confusing. In addition each of them hold very good features that you can't use in the other one:

  1. run_command - sudo, user, read_timeout and HostOutput class as a return value.
  2. execute - let you use an existing channel without opening a new one each time.

I can't fully understand why "execute" isn't a "private" method in the sub-class while the user can only use run_command with additional feature of providing a channel to use.
This leads to the "wait_finished" method who is implemented in SSHClient sub-class which expects HostOutput as a parameter to work which means the intention is to use "run_command" method.

I think "run_command" method should be the main API for sending commands while each sub-class can implement the "execute" private method, and "wait_finished" method should be in the super class for better OO design.

Needless to say this is just my opinion and what I am saying is just a suggestion.

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant