Clearly I am missing something… and it's probably trivial so I'm prepared to embarrass myself with this question, but here goes: I would like to have a button running a small MS-DOS batch script, but my button does nothing right now, so I'm doing something wrong.
Here is my script:
set var=%CD%
sett var=%var:\=\\%
echo %var% > var.txt
This script works fine if I run it from a command prompt. There's more going to be added in later, but for now I was just trying to use this to test if the basic ideas would work. If they did, I should see a "var.txt" file in my source folder, but I don't (I also searched through essentially all plausible locations, and there's no "var.txt" file anywhere), so it looks like nothing is happening.
Additional sleuthing reveals that if I have just a one-line script saying something like
echo "Test" > var.txt
then I will indeed get a "var.txt" file in my source folder. If add just one line to set the variable, like so:
set var="Test"
echo "Test" > var.txt
Then nothing happens and the script doesn't seem to run at all, so I must be missing something really basic.
Hmm, now there seems to be a somewhat more arcane problem: I have the variable "var" defined as a User Environment Variable as part of my general DOS/Windows environment. Now it looks like, despite the script seemingly going through, somehow %var% does not get set, and remains at its pre-defined value as shown by the content of var.txt. Any idea why that might be?
P.S.: I know I can solve my issues simply by writing an external .bat script and running that from DOpus, but having the script defined inside DOpus should work, I think, and helps with portability…
One more piece of information: If I set the value of some arbitrary variable (say, %xyz%) the value gets set properly, but it seems I cannot overwrite the value of the existing variable. Strange.
For clarity, I have something like
set var=%CD%
set xyz=%CD%
echo %var% > var0.txt
echo %xyz% > var1.txt
After running this the file var0.txt contains the pre-defined (unchanged) value of %var%, the file var1.txt contains the correct source path.
DOS Batch is usually the absolute worst choice to write anything in, as it's very arcane. You can probably do it a lot more easily in something else. Let us know what you're aiming to do and we can suggest how to do it.
This question is really an extension of what I had been asking for earlier, regarding a button for running WSL in ConEmu. With the somewhat convoluted way ConEmu starts its associated shells, the best path to achieve what I wanted seems to be to define an environment variable that holds the directory I want the bash shell to start in. This is defined system-wide as "~" (my home folder under WSL) so that everything works as before when I simply start ConEmu from its regular shortcut. In order to launch the shell in a specific source folder, all I then need to do is redefine this environment variable to point to the WSL version of the source path.
Like I said, I do have a DOS batch script that does exactly that and works fine. Thus I can just define a button for DOpus which starts that script and I'm set.
So this question really seeks to eliminate the need for a separate .bat file, by inserting the entire code in that script into the definition of a DOpus button.
Unfortunately, running DOS commands within DOpus' environment seems to somehow work differently, and I narrowed the issue down to the fact that it seems we cannot change environment variables from within DOpus. This is somewhat strange, and I don't really understand the reason why this would be, but here we are…
Nevertheless, I would still be interested in any more elegant solutions for what I am doing.
P.S.: Oh, and I do agree that DOS scripts typically represent a somewhat ugly solution.
Ok I've confirmed this and it's a bug (or side effect anyway). Opus is expanding the environment variables itself when building the batch script to run, but it doesn't know about changes made by the set command. So it sees the original value of %var% and expands that even though in reality it's changed. Because %xyx% wasn't set when the script was built, Opus ignored it and passed that through unchanged - meaning it gets correctly expanded by the script.
Ahh, that's comforting to know, in a way. Well, I'm sure you'll fix that at some point. It's not terribly urgent for my situation since I do have a working alternative, but it might prevent others from tearing their hair out…
You can use the @noexpandenv modifier to prevent expansion of env vars. Currently we're looking at whether this should be the default behaviour for batch scripts.
