The batch script run by itself from the cmd line works fine and sets the environment variables as expected. Even from within the Perl script - the set statements in the batch script output the said environment variables. The issue is not with the batch script. I am wondering why the last two print statements in the Perl script give me the error they do - or how do I make the environment variables stay put in the cmd window ? It seems that once the batch script is run (from within the perl script) - it wipes out the environment variables that are set and are not even recognized from within the same perl script...if that is the case how can I use those environment variables in the perl script ?
If you start a script, it gets the environment at the time. If that script fiddles with an environment variable, that is only a temporary setting for the duration that that script is running.
If you set an environment variable before a script is started, then the script inherits that value when it runs. Back up another level, when Windows boots, certain values are set in the environment and all processes inherit those values.
In almost all cases, forward slash, '/' works like '\'.
That's pushing it. It's true in Perl (since the Windows API accepts "/"), but not so much in the shell (because "/" is the command line option starter, and it doesn't need to be preceded by whitespace). For example, dir /users won't work.
That said, if you place the path in quotes, "/" is much more likely to get accepted. For example, dir "/users" does work.
This is only relevant if $pathSeparator is used to build shell commands, which is possible. It's hard to tell, since $pathSeparator isn't actually used in the posted snippet.
Yes, there are issues with \ vs / in Windows. I think that there are things like '\' is needed on a path to an .exe.
In Perl code, using "/" in a Perl function almost always or at least I don't know of a case where it does not. But YES, there are cases where Windows itself is pretty finicky about this. Yes, I would quote a path, like "/file", because there are even more lexical pitfalls like "divided" by file!
Without spending hours thinking about it, I cannot cover every single case. My method is simplistic, I write something that "feels right" and if it is wrong, I try again and then verify that the new formulation is "right". It just seems like when I think I've learned everything about it, I get bit with a new wrinkle when dealing with this \ and / Windows command line stuff! I think that is just the nature of the beast.