2

I'm building a GUI for a CL program and I have the following question

Is it better to

  1. Have the GUI invoke the program behind the scenes using a shell with some options eg: If I were I were writing a git frontend, I would just have every button click correspond to a git foo bar command that runs in its own shell
  2. Or by-pass the program's CLI and plug in directly to the layer underneath

Caveat: I did not build the the app in question,but I do have access to the source. I'm asking if both are acceptable development patterns and what are some things I should be aware of when choosing either?

I understand that programming to the CLI provides a static non changing interface to which I can program to and the innards can change as long as the interface remains the same, but wouldn't hooking directly into the code below the CLI allow for greater scope of debugging and richer error messages?

|improve this question
  • 1
    can you clarify, has the program got a supported api to plug into, or are you suggesting hacking it? – Ewan Feb 26 '18 at 17:46
  • 1
    Honestly, it really depends on a number of factors, including whether or not you actually have a library to call for your command line tool. If not, just build the UI around calling the command line and parsing the response. – Berin Loritsch Feb 26 '18 at 17:48
  • @Ewan Not really, there is some semblance of an API layer under the CLI but I would have to re-write some portions of it to make it consistent. But I'm asking more in terms of industry practice. Is it normal to write an API layer for a GUI to plug into or do GUIs just invoke the CLI? – Srini Feb 26 '18 at 17:49
  • 1
    @SrinivasSuresh, I've seen both approaches in the wild. I know nothing of your tool, but there are pros and cons to a more integrated approach. One of the cons being the risk of breaking things to create an API where there was none to begin with. – Berin Loritsch Feb 26 '18 at 17:54
  • 1
    @SrinivasSuresh: if you want to be a really professional software developer, stop thinking in cargo-cult terms like "industry practices" or "best practices". There is nothing like "best practice", only confirmation to requirements. For example, this specific case: there are situations where solution 1 fits better to the give requirements, and there are situations where solution 2 fits better. None of them is "better in general". – Doc Brown Feb 26 '18 at 20:25
5

I've seen a program from a vendor shipped with two UIs, i.e. as a GUI and as a console program. They're implemented as two EXEs calling a common DLL.

And by using the DLL's API (ignoring both of the existing UIs/EXEs) I can include the program's functionality in my application.

what are some things I should be aware of when choosing either

The CLI might be better documented (and more stable, better supported) than the API exposed by the DLL (which may be known only to the vendor and which may change from version to version).

It may be worth noting, too, that driving an EXE's CLI means running it "out of process"; whereas using a DLL's API means using it "in-process". This may affect stability/reliability and performance.

|improve this answer
3

In my experience it is unusual, but not unheard of for a gui to invoke a cli. ie button presses on a graphical interface to launch a command line behind the scenes.

The main argument against it is that you have limited scope for dealing with errors and more errors that can occur. especially permission errors.

lets say my gui runs "format c:" when I click the "check for viruses" button. The os is clever enough to fire a popup saying "needs admin permissions" when the command runs, but how can my app pick up on that and automatically click yes?

Its not impossible, but its exactly the kind of thing the os its trying to stop you from doing.

Obviously thats an extreme example, but what if its just that the cli returns "overwrite file y/n" or "no permissions to c:" I have to parse the string and work out what's going on. Whereas an api would give me a nice exception

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.