Re^3: Restarting a Perl script on Windows 10
by stevieb (Canon) on Sep 20, 2019 at 23:11 UTC
|
"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.
| [reply] [d/l] [select] |
|
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.
| [reply] |
Re^3: Restarting a Perl script on Windows 10
by petro4213 (Acolyte) on Sep 23, 2019 at 08:58 UTC
|
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? | [reply] |
|
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.
| [reply] |
|
More argument from ignorance. Why even bother?
| [reply] |
|
|
Re^3: Restarting a Perl script on Windows 10
by petro4213 (Acolyte) on Sep 25, 2019 at 07:43 UTC
|
I initially missed the option with the command line using wperl. This works well, because it hides the new command window. | [reply] |
|
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.
| [reply] [d/l] |
Re^3: Restarting a Perl script on Windows 10
by Anonymous Monk on Sep 21, 2019 at 01:15 UTC
|
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! | [reply] |
|
| [reply] |
Re^3: Restarting a Perl script on Windows 10
by petro4213 (Acolyte) on May 07, 2020 at 08:31 UTC
|
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...
| [reply] [d/l] [select] |
|
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. | [reply] [d/l] [select] |
Re^3: Restarting a Perl script on Windows 10
by Anonymous Monk on Sep 21, 2019 at 11:07 UTC
|
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.
| [reply] |
|
| [reply] [d/l] |
|
Loading fuel or battery is some intricate mess?
| [reply] |
|