UNIX for Dummies Questions & Answers

Experience level : New to programming in Linux. Forgive my noobiness in this context with regards to programming, language or grammar.

Some Background info : I have seen a lot of programs which I use (Modo and Maya especially) which can use a command line to run the different parts of the program. So to make a new standard primitive I can run a command like (fictitious command) "create polycube 5" and create a polygonal cube of 5 units size. When using Maya the first time, such commands are overwhelming but the power lies in combining these commands so that any and all GUI interface activities can be scripted by copying and pasting commands echoed in the script manager window. Anything that is done on the GUI will have a corresponding command reflected in the script manager window.

I wished :All programs in my computer had functionality like this so I could have 'stringed' together my browser, mail program, download manager, and contacts manager and so on seamlessly the way I wanted them to work.

My question : is when creating a GUI program say for example a calculator, wouldn't it be better (especially if one is planning to add workflow automation features to the final application,) to create multiple console programs where each program is used for a certain functionality in the calculator ( say for example volume Conversions use a console program "vConvert", area conversions uses another called aConvert, and so forth so when the final application is put together, besides using the GUI to run the application, a power user can string commands in a script manager like in the above applications to create a custom workflow script/shortcut/button. or run individual converters separately from the CLI.

Is there a disadvantage (performance issues or security issues) in the final application if it is created this way?

What you're forgetting is that these applications weren't meant to cooperate. Maybe SeaMonkey from Mozilla is what you're searching for. Apart from that, you're right: GUIs that display the corresponding commands for the command line are grand.

If you're launching several subprograms, each of which contribute only a small part to the whole job, you incur a certain overhead for the process creations and the IPC (communication between the programs).
A more viable alternative would be to make a clear separation between the functionality layer and the user interface. The more loosely these two are connected, the easier it becomes to exchange a GUI for a CLI.

Thanks for the reply. Much appreciate it.

Wished Linux programmers considered something like this to echo all GUI interactions as commands.

We would have had a better solution for automation in Linux than inventing newbie friendly equivalents for "Applescript" or "Automator" like on Macs.