Re: Best/Fast/Simple way to add a GUI to a batch process

Since you are just starting to get into making it easy to run remote commands, I feel obligated to point out that the best solution, although not a pure gui, is to use tmux. Google for many tutorials or see tmux intro.

The nice thing about tmux, is that it will display correctly over a ssh connection, giving you a multipane window, each of which can run different commands. You can also easily put the commands in the background, detached, and come back hours later to reattach to it. A very professional approach. BTW, you can also run mc "Midnight Commander" over ssh, this comes in very handy, and between tmux and mc, you may have a simple, secure solution.

I'm not really a human, but I play one on earth. ..... an animated JAPH

Comment on Re: Best/Fast/Simple way to add a GUI to a batch process

Replies are listed 'Best First'.
Re^2: Best/Fast/Simple way to add a GUI to a batch process by vitoco (Hermit) on Aug 28, 2018 at 19:42 UTC
I never said that I wanted to run remote commands. My script connects to a remote server and send messages to it based on the template and the listing files, while logging the results in a third file. The GUI is for a user who don't like command line utilities, and he will use this program in his Windows "server" (might be using Remote Desktop or directly in front of the machine, I don't care). But I like your idea. It could be fine if the user work in such environment, but this is not the case. He likes to run apps double-clicking on local icons from the desktop and expects windows to interact with them. The less configurations involved, the better.	[reply]

Replies are listed 'Best First'.

Re^2: Best/Fast/Simple way to add a GUI to a batch process
by vitoco (Hermit) on Aug 28, 2018 at 19:42 UTC

I never said that I wanted to run remote commands. My script connects to a remote server and send messages to it based on the template and the listing files, while logging the results in a third file. The GUI is for a user who don't like command line utilities, and he will use this program in his Windows "server" (might be using Remote Desktop or directly in front of the machine, I don't care).

But I like your idea. It could be fine if the user work in such environment, but this is not the case. He likes to run apps double-clicking on local icons from the desktop and expects windows to interact with them. The less configurations involved, the better.

[reply]