Well I see this is coming a bit late, but hopefully it can help you or someone else having a similar problem.
Since you are running a Windows shortcut, instead of using the syntax for cygwin/*nix environment variable expansion (
$VAR_NAME) you probably just need to use the syntax for Windows/CMD.exe expansion (
%VAR_NAME%). Also, I am linking two Wikibooks below that should cover pretty much anything you ever need to do with batch files for future reference.
That said, I would have expected your syntax also to work, and I do imagine there is some way to have expansions happen on the "other side", so-to-speak. If I can find a way as I work on my terminal launch script I will update this answer.
- Programming CMD has most of the basic syntax and essential commands
- Windows Batch Scripting a fairly comprehensive reference for everything
cmd shell scripting leaves a lot to be desired, and I think you can easily google for something that gives you a run down on all the details. I just wanted to mention it, and mention that there is nothing stopping you from using something like 'MinGW-x64' (I recommend researching the difference between 'MinGW-x64' and the original if you are in doubt; they are maintained by separate entities), or something like Cygwin, which you clearly already have some experience with, either of which will allow you to do
MinGW-x64 is simplified and has an incomplete POSIX implementation due to some concepts that are incompatible with the Windows Subsystem without some additional support (well, the Microsoft VC runtime, I guess; and I think there are circumstances where you need to at least with MinGW if not MinGW-x64) but I mention it first, since it is a 'native' (i.e. 'fast') solution.
Cygwin provides its 'compatibility layer'
.dll that provides a fairly complete POSIX environment, at the cost of (a) some fairly siginificant overhead (at least in some cases) and (b) having a fairly complex extra
.dll that has to be provided with any software you make with it, and at the cost/benefit (depending on your perspective) of being fairly well locked into the GPL if you use it for your project and link to the compatibility layer.
However, as an alternative, this answer mentions Red Hat's Cygwin license offer for non-GPL license terms on Cygwin, if you so desire. (And, of course assuming that it's cost-effective for you and your project.) However, for personal or in-house shell scripting (i.e., not 'distributed', an, so, not covered by the GPL) it might very well be a good choice, and would almost certainly be better than futzing around with the idiosyncrasies of a DOS-era product still stuck supporting poor decisions made well over 30 years ago.