Robustly running external processes is a tricky and subtle business.

Having laboured for years at the C level on cross-platform Unix/Windows code -- while lovingly studying the collected works of Mark Russinovich, Jeffrey Richter and the legendary W Richard Stevens (who tragically died way too young at 48) -- I am painfully aware of how differently Windows and Unix deal with processes under the covers. For example, Unix uses signals for IPC while Windows does not and command line parsing is completely different. Worse, I have no clue about (and no interest in) the subtleties of running external processes on Dec VMS, Classic Mac OS, and other obscure OSes that Perl supports.

Accordingly, to keep my code simpler and easier to test and troubleshoot (while being correct for each OS), I usually prefer to use separate code paths for Windows and Unix code that runs external commands (a crude example of this approach can be found in Timing and timing out Unix commands and Re: Timing Windows commands). I also worry about the correctness of a cross-platform abstraction and especially the difficulty of troubleshooting bugs. I might add that I've always applauded Perl for allowing me to easily write Unix-specific code and Windows-specific code when I want to.

So, given your reply here, my advice is to write your Perl code that runs external processes to work on Unix only, test it on Unix only, and clearly document that assumption. I don't think you need worry about differences between different Unix flavours (e.g. Linux vs AIX), at least I'm not aware of any gotchas in this area.

Update: BTW, this reply (in a long debate on the history of Windows NT vs Unix) mentions the real reason why Windows does not have Unix-like signals, and further notes the vast gulf between Windows CreateProcess and Unix fork/exec.

References Added Later

These two are excellent:

• Calling External Commands More Safely by haukex (2017)
• The problem of "the" default shell by afoken (2017)

Other references:

• Re^3: Perl Rename by afoken (2010: argument passing to shells on different OSes)
• Re^2: Having to manually escape quote character in args to "system"? by salva (2017: compares how Windows and Unix parse the command line)

• (Windows) verbatim command line arguments inside Perl script by LanX (2021: discusses Windows command line parsing and quoting)
• Re: More Effecient Method Chaining by me (2021: discusses running external commands safely, robustly, portably, efficiently on multiple platforms)
• Raku: How do I generate a handle for HKEY_LOCAL_MACHINE? by nysus (2022: Raku version of CPAN File::Which requested)
• Re: null output on program by haukex (2022: Security issues running external commands)
• Re^2: Who still uses the camel book? by starX (2023: APUE gets a special mention in this node on classic programming books)

• Unix shell versus Perl
• Re^2: Unix shell versus Perl (some shell script security issues to be aware of)
• Any reason to use the Paws module over aws cli commands in perl script?
• sed/awk/grep to Perl

• Re: Reading output of external program without Shell
• Re: capture child process STDOUT/STDERR on Win32
• Re: capturing command output

• Re^3: [OT] 'perl' is not the 'perl' reported by 'which perl' (which vs type References) (I was ordered by our Unix guru at work to never use the C shell and to always use the type command, never the which command)

See also:

• Re: Threads or no Threads (Threading, Forking, Signals, Event Loop and Concurrency References)