Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: Restarting a Perl script on Windows 10

by NetWallah (Canon)
on Sep 20, 2019 at 17:48 UTC ( [id://11106450]=note: print w/replies, xml ) Need Help??


in reply to Restarting a Perl script on Windows 10

I was able to get this to start without <enter>:
exec("wmic","process","call","create", "CommandLine='cmd /k $pathToMys +elf'" );
But it keeps an annoying empty cmd window hanging around.

                "From there to here, from here to there, funny things are everywhere." -- Dr. Seuss

Replies are listed 'Best First'.
Re^2: Restarting a Perl script on Windows 10
by jcb (Parson) on Sep 20, 2019 at 22:53 UTC

    I am happy to say that I currently avoid Windows, but your code gives me an idea or three:

    exec(qw/wmic process call create/ => "CommandLine='$pathToMyself'" ); +# if Perl scripts are associated to perl exec(qw/wmic process call create/ => "CommandLine='perl $pathToMyself' +" ); # if perl.exe is in %PATH% exec(qw/wmic process call create/ => "CommandLine='wperl $pathToMyself +'" ); # if wperl.exe is in %PATH%

    These of course are completely non-portable in typical Microsoft style, so if you want your script to be generally usable, try adding this before one of the above:

    unless ($^O eq 'MSWin32') { exec( $pathToMyself ) }

    Really the best answer is probably to get a better operating system...

      "Really the best answer is probably to get a better operating system..."

      As nice as that sounds, there are all number of reasons why this may not be desirable, feasible, or even possible for some people.

      Personally, the only time I use Windows is when I'm developing berrybrew. I've got a few VMs configured for that. So realistically, I only use Windows to develop software that I don't even use :)

      ...that's not entirely accurate. I use my Test::BrewBuild CI automation against Perl instances running under berrybrew on a Windows system that all it does is listen for incoming test run requests. I have a VM set up with Perlbrew as well for the exact same purpose. All of my distributions (the cross-platform ones) are automatically tested against both Windows and Unix over the network, across at least 10 versions of Perl before I do a CPAN release.

        I understand some people may be stuck with Windows for whatever reason (and I have used it at $WORK because that is what someone else decided $WORK would use) but the issue at hand is breakage after an OS update for which workarounds may be possible but are definitely non-portable. Perhaps the Perl 5 porters could include something functionally similar to one of my suggestions in the implementation of exec on Windows Perl for Windows 10? But Windows no longer really has versions anymore, only "Windows 10 rolling release with mandatory automatic updates" so how to determine when to use the workaround and when to use the traditional code that worked before?

        Working around Windows' brokenness is still working around Windows' brokenness, which you cannot fix because you are not Microsoft, so the best solution is to move to a non-broken operating system, or at least to a system you can fix. I suggest GNU; avoiding these kinds of problems was a significant motivation for the GNU project, as I understand it.

      Thanks! This works fine.! :-)

      The only ugly thing is, that it not only restarts my program, but it also creates a new command window. Any idea on how to get rid of this or at least get it minimized?

        If all three of those also produce persistent extra command windows... the only idea I have at this point is "get a better operating system" ... or maybe run your program on a better operating system (on another computer, possibly a VM) and an X server on Windows for display? It has been some years; the last time I did that I was using a MinGW (I think?) X11 build on Windows XP.

      I initially missed the option with the command line using wperl. This works well, because it hides the new command window.
        This works well, because it hides the new command window.

        Yep. wperl.exe's raison d'ętre is to run GUI-based scripts in Windows without a command-line window. As I linked in another post (but should have quoted, too), the perlwin32#Miscellaneous Things docs say,

        If you want to start a copy of perl without opening a command-line window, use the wperl executable built during the installation process. Usage is exactly the same as normal perl on Windows, except that options like -h don't work (since they need a command-line window to print to).

        The new file extension with its own association that I also mentioned in that other post could help you make GUI-based scripts automatically run with wperl, if you so desired.

      Really the best answer is probably to get a better operating system...

      Windows 10 seems like spyware posing as an operating system. macOS has the same smell but they disguise it as cloud services (lol). I had to implement 2 firewalls to extinguish the constant creepshow of unintended and unknown outbound network connections sending god knows what, encrypted, to the criminal minds at Apple, Inc. Thank Linus for Linux!

        Please share your solutions.


        The way forward always starts with a minimal test.

      The solution

      exec(qw/wmic process call create/ => "CommandLine='wperl $pathToMyself'");

      works fine, as long as the script to call (pointed to by $pathToMyself) doesn't require additional command line parameters.

      I know, that this is not a Perl issue, but would you have a solution on how to add command line parameters to this call? I must admit that I don't understand the wmic docs...

        WinDOS uses the DOS model and does not pass arguments to invoked processes, only a "command tail" string that all Windows C runtime libraries parse into argc and argv using some rules or other.

        Using wperl as in your example means that $pathToMyself is already being passed as the "command tail" to wperl. Try:

        my $argtail = join ' ', @args; exec(qw/wmic process call create/ => "CommandLine='wperl $pathToMyself + $argtail'");

        If you are wondering, yes, this does mean that arguments containing whitespace are a problem. Quoting is handled by C runtime library startup code and that can vary from program to program because there is no standard system C runtime library on Windows.

      Really the best answer is probably to get a better operating system...

      oh noes my fork is not a knife. My car won't start. Better get a new one. Probably. New bathwater; New baby. No logic by job.

        "My car won't start. Better get a new one."

        From an economic perspective this is/may be often the better solution. Instead of some intricate mess about.

        «The Crux of the Biscuit is the Apostrophe»

        perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

Re^2: Restarting a Perl script on Windows 10
by Anonymous Monk on Sep 21, 2019 at 10:44 UTC
    Duh cmd /k /K Run Command and then return to the CMD prompt. This is useful for testing, to examine variables

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11106450]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (5)
As of 2024-03-29 07:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found