in reply to Best/Fast/Simple way to add a GUI to a batch process

Thanks for the ideas. I'll take a look and try them.

But I intenionally omited a bit of info: I cannot install perl in the destination server, so I'll use PAR to make an executable for the user. I think this would limit the options, or not?

For instance, I made a fresh Strawberry x64 install in my notebook and then added WxPerl using cpan, which took me more than an hour to complete the makefile. Then I added PAR::Packer and it added Tk as a dependency!!! Why? And it also took almost another hour to complete!!!

Finally, I tried to include Padre in my installation to see what can it do, but cpan couldn't finish the installation (I guess it is something related to x64 and DBM on Strawberry installs).

Thank you again...

  • 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 zentara (Cardinal) on Aug 27, 2018 at 21:06 UTC
    Hi, if I were in your shoes, this would be my approach. If you can, run your app thru ssh. If your server has an X server, you can even run X apps thru ssh and it will be displayed on your local display. The problem most run into, is that most servers don't allow an X server to be run, because of system bloat and insecurities. This normally means that you will have to run your programs remotely as commandline via ssh. There are numerous examples on google. What you can then do, is use the Tk::ExecuteCommand example I showed on your local machine, but with ssh remote commands instead of local commands. I hope that makes sense. For example, see Net::SSH2::Channel Net::SSH2 Interactive command example and A little demo for Net::SSH2.

    Remember, unless your server has an X server running, which it probably dosn't, you won't be able to run any gui program. If you don't want to use Net::SSH2, you can always run (individual ssh with options) from a local Tk-ExecuteCommand gui. That way, you have your gui on your local machine, but run non-gui commands on the server you connect to.

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

      The OP described it as a Windows server so I assumed an RDP session is being used. Even if you aren't allowed to install things you can put a portable Perl folder such as from Strawberry Perl onto the server. This is the situation I work in with servers that are behind a firewall that doesn't allow web access. Most servers have an older version of ActiveState Perl that is required by a software application. I have a portable Perl folder that I have installed authentication email modules to on my personal workstation using CPAN. I can then deploy this folder to the servers so I can send authenticated emails. In the good old days I created install scripts to install modules on the ActiveState Perl in a particular order according to dependancies and hoped I didn't mess something up. It took me hours to deploy to multiple servers. Now I just give teammates a document describing how to copy the portable Perl folder and use portableshell.bat.

[reply]

      Actually, the server doesn't need to have an X server. Properly configured, an application running on a server can use an X server running on a desktop (or laptop) PC. (Has been many years since I last did this, but as best I can determine, it it still possible.)

[reply]
        Hi, thanks for that info/correction. I'm not sure if I believe it though. The last time I tried it, the server needed an X server in order to do X forwarding. Can any more knowledgable monk clarify whether a server needs X running in order to forward X thru ssh? Seaching the docs on Google dosn't reveal that detail. From what I can gather, you need to have the xauth program running on the server, but if that requires a full X install, I'm not sure. Server GUI

        Update: After some thought, it dawned on me that you probably need the X server installed on the server, but not neccessarily running. Why? Because when you try to execute the remote X program, it must find the various X libraries it needs, otherwise it will complain and fail. Your remote client can't provide the needed libraries, they must be on the server. So it seems RonW you are right, the X server does not need to be running, but the libraries must be installed. So .... X installed, but not neccessarily running, would be required.

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

In Section Seekers of Perl Wisdom