I don't see why you want to invoke a shell in a way that was meant to interact with humans. You can pass an arbitary string to any shell script you want to invoke, just like you would do for any other program: using the multi-argument form of exec, system, or open.

If the shell script is executable (chmod +x script.sh), there is really no difference to invoking a compiled program (except for the O/S kernel passing the script name to its interpreter binary as argument, but that's completely transparent). You use the shell script like any other program, i.e. exec('/path/to/script.sh',$any,$args,$you,$like).

If the shell script is not executable (chmod -x script.sh), you pass the script name as first argument to a shell, and the remaining arguments after that. I.e. exec('/some/shell','/path/to/script.sh',$any,$args,$you,$like).

In both cases, the shell script will see four parameters: The contents of $any as first parameter, the contents of $args as second parameter, the contents of $you as third parameter, and the contents of $like as fourth parameter.

The only remaining problem are NUL bytes ("\x00") in the parameter values. They terminate the argument even if perl originally passed a much longer string, simply because the underlying API uses C strings that end at NUL bytes.

Regarding the state of String::ShellQuote: Feel free to contact and support the author and improve the module.

I don't see any use for that module on Unix-like systems, but with support for command.com and cmd.exe, it could be useful on Win32. Unfortunately, you can not be sure about proper quoting on Windows, as each INVOKED application is free to implement different quoting rules. See also the second half of Re^3: why IPC::Open3 can't execute MS-DOS "dir" command?.

Alexander