For BCDEdit I need the driveletter without backslash, because it requires "[C:]..." as drive-syntax.
With "set driveletter=%path:~0,2%" (= only take first 2 chars) it will work via commandline, but when getting the path from DO using "@set path = "{filepath$}" it doesn't.
Alternatively I could use "{sourcepath$|}" (which will result in "C:"), but I don't know how to remove the "".
Can't you combine a @set and another msdos set to get rid of the slash?
Tried a lot, but I'm no good coder.
Using "~0,2%" with "@set" results in removing first 2 chars (while in Dos it shows the first 2 chars). And using Dos' "set driveletter={sourcepath$}:~0,2" also doesn't work.
Tried a lot, but I'm no good coder.
Using "~0,2%" with "@set" results in removing first 2 chars (while in Dos it shows the first 2 chars 
). And using Dos' "set driveletter={sourcepath$}:~0,2" also doesn't work.
The script runs fine in commandline, but I want to to use it within DO.
Doubling the % characters may work. (Same as you'd need to in a .bat file vs the command prompt. stackoverflow.com/questions/1450 ... a-cmd-file )
Failing that, scripting. DOS-Batch is the devil. 
I'll try... no, scripting is the devil ... for me
DOS Batch is full of arcane issues. Scripting is not perfect either but is much more straighforward, once you take an afternoon to learn it. Highly recommended.
It seems any batch code stops processing if there is a regular msdos "set" command used in a DO button.
Prefixing the "set" command with a dummy "echo" gets you around this (here at least) and then this seems to work:
[code]@nofilenamequoting
@leavedoswindowopen
echo off& set letter={sourcepath$}
echo off& set letter=%letter:~0,2%
echo Letter: "%letter%"
pause
[/code]
You need @externalonly if you want to use the DOS Set command instead of the Opus one.
Thank you both! The @externalonly did the trick!
@externalonly vs. button type "MSDOS Batch".. I think I don't get it! o)
I did not think of the internal "Set" command when doing a batch type button, maybe this is something that can be enhanced?
A notification would also work I guess or some kind of warning in a status-bar or something in the button editor. Something that reminds you:
You used "Set", make sure to use @externalonly if you intend to set env-variables.
Maybe rename "Set" to "SetDO" in v12?
These simple things should not require any support, if experienced users struggle with this, there might be something wrong with it.
AFAIK the DO "@set"-command requires an "@". I ran into problems, because I combined DO-vars with MS-DOS-vars, but after using "@externalonly" and removed all "@", which I used for filepath etc., it worked (don't ask me for details, it works ).
@Leo: "...once you take an afternoon to learn it.". That was good !
The @Set modifier is different to the Set command, which is different to the DOS Set command. You've probably used the Opus Set command a hundred times, so many that it's blended in to the furniture. I find the same thing.
Same problem if you want to run a DOS or external command called "Copy" or "Help". Nothing is specific to Set here. If you wanted the DOS Copy command instead of the Opus one, you'd have to use @externalonly there as well, to tell Opus that's what you want.
We are not renaming the Set command and breaking absolutely everything people have in their existing configurations. That would be really silly. 
We'd also have to rename Copy and others.
A better warning/notification would be not to try using env-vars and DOS Batch at all, these days (unless you just want to run a tool that outputs to a command prompt). This is what scripting is for.
I'm not sure string manipulations using arcane MS-DOS incantations and environment variables in an environment that inherently has to allow mixing of internal and external commands (which also means potentially split batch files in half and losing any env-vars) counts as a "simple thing".
Can you explain in short why this mixed-mode exists? What needs to be done in a button that mixes DO commands and batch code?
I'm not a pro-button code writer, just curious, as I currently can't think of something that would require this. I also hardly remember any button making use of that.
Maybe we could ditch that for v12? o) Loosing some weight and gaining more profile in the automation part wouldn't be the worst thing. o)
If you want a pure DOS batch file just make a .bat file.
It's not about running external files. It just might be a bit unclear what needs to be done to run pure batch code straight from a button.
I would have expected it to work right away, if I set the button type to MSDOS Batch. For the mixed mode, there still is the "Opus or external" button type I guess?
I'm still interested in what can be done by mixing batch and DO commands and why DO inherently has to allow that, please let me know if you can remember.
This is feedback after all, not nitpicking. Two experienced DO users getting confused when trying to run batch code from DO is feedback as well (indirect).
Suggesting to use scripting and leaving behind arcane MS-DOS stuff is questionable advice fmpov, as DO supports that for a decade and still does. If you don't like/remember the aspects behind that anymore or don't want to give support, maybe remove it from DO or render it officially unsupported to make this clear to everyone.
Let me add, msdos batches and people using them are going to stay for quite a while, activex scripting is not well spread and does not replace batches and not even powershell does. This is my impression from what happens out there on customers and hobbyists side at least, regardless of how many powershell trainings and websites pop up about it.
Again, just feedback, no offense.
Well, I'n not experienced in scripting, but maybe that's the reaon why it confuses a bit more.
For me it's hard to understand which DO-commands can be used within a MS-DOS-Batch. The reason why I used "@set" in the batch was, that I didn't know that a DO-variable is also available when using "set" only (e.g. filepath etc.). On the other side when executing easy commands with variables I always use "@set".
Few days ago I already had a working "standalone"-batch of my script and later solved it by just calling the external cmd followed by {filepath$}! Then Leo postet the "@externalonly"-hint and I tried again and was able to include the cmd into DO. Of course the better solution. Thanks again.
The original idea of DOS batch mode was to be able to run command line third-party programs from Opus buttons. For example, you might want to use imagemagick to do an image conversion and then use the Opus copy command to archive it. Or whatever.
Just because a usage isn't immediately obvious to you doesn't render the function completely useless and needing to be immediately removed.
Yes correct, your example cleared that. What you describe makes total sense and isn't even a weird usecase or something, thanks.
Maybe we can find the root of the irritation, I think it basically is just missing information - the documentation says:
Standard Function:
This is used for most commands, and is the option you will most often select.
Both internal Opus functions and the launching of regular external Windows programs work in this mode.
MS-DOS Batch Function:
This is used to run MS-DOS type programs (including .bat scripts).
It's intended for programs that don't open a window of their own, but instead are designed to print text to a DOS prompt.
From recent experience, the msdos batch function also runs internal DO commands by default, which is mentioned only for the standard function and was unexpected for me. So now I wonder, what is the exact difference between the two? Must be something with how DO prepares the call to whatever is in the button. To also provide help instead of just questions, I did a table. I think it gives a hint on how complex this actually is. Let's validate it and inject it into the docs? o)
DO-ButtonTypes_vs_Commands.zip (2.36 KB)
