I haven't reported the bug yet because I am still testing, and it's very closely related to another bug that I have already reported to GP Software. What I do know so far, is that while you are typing a command like this:
dopusrt /CMD Copy FILE="{file$}" CREATEFOLDER="{file$|noext}" HERE
Opus actually attempts to execute this:
dopusrt /CMD Copy "FILE={file$}" "CREATEFOLDER={file$|noext}" HERE
Which means that if your first file was named "File Name.ext", then Opus would look for a file named "FILE=File Name.ext" and try to copy it. And of course you do not have such a file, so you see an error.
I think the reason it doesn't work is that you're using " and '. You should only use " as I don't think ' works as a quote character in commands; either way you shouldn't use both at once.
Ah, it's not a bug, it's because the command is being parsed twice after it's generated: First by MS-DOS and then by Opus.
Try using two " instead of "' and '". If that doesn't work try using three, and so on. MS-DOS does strange things to quotes sometimes but it usually starts to work if you add enough of them (but not too many ). Usually you only need two.
Something like this should work, although I haven't tried it:
@nofilenamequoting
dopusrt /cmd CreateFolder NAME=""{destpath}{file$|noext}""
The doptest tool by Tanis is good here for checking the command that you're generating after it's been processed by MS-DOS.
[quote="kenalcock"]I haven't reported the bug yet because I am still testing, and it's very closely related to another bug that I have already reported to GP Software. What I do know so far, is that while you are typing a command like this:
dopusrt /CMD Copy FILE="{file$}" CREATEFOLDER="{file$|noext}" HERE
Opus actually attempts to execute this:
dopusrt /CMD Copy "FILE={file$}" "CREATEFOLDER={file$|noext}" HERE
Which means that if your first file was named "File Name.ext", then Opus would look for a file named "FILE=File Name.ext" and try to copy it. And of course you do not have such a file, so you see an error.[/quote]
Try leaving out the = signs - change to a space. Eg,
dopusrt /CMD Copy FILE {file$} CREATEFOLDER {file$|noext} HERE
Sorry I missed the late night discussion !
Nudel, do you ever sleep ?
@nudel and all
After using Doptest to debug, I find that this works.
@nofilenamequoting
dopusrt /cmd CreateFolder NAME=""{destpath}{file$|noext}"
Yes, that is two quotes after 'Name' and one quote at the end.
This must have been part of why I wrote a short command line program to do this.
@Ken
I also have considered using the Copy CreateFolder command.
It may be better in the end.
Nudel's Setclip program could be used.
However, it results in either:
a) another button to set the clipboard to the first file$|noext .
b) the use of @firstfileonly and then the use of allfile$ as my solution does.
This has the inherent flaw of being limited to the DOS command line character limit.
@Jon
Is it possible to cancel the @firstfileonly directive ?
I'm thinking something similar to this button that uses a fictional @allfiles directive:
[quote="porcupine"]@Jon
Is it possible to cancel the @firstfileonly directive ?
I'm thinking something similar to this button that uses a fictional @allfiles directive:
@Porc
I just submitted a feature request earlier today for a different external command code that would only process the first selected file or folder, which would enable you to accomplish what you are trying to do. It would also have other useful applications as well.
Yes, I hope something similar to that can be done !
I'll be backpacking North Manitou Island last week of September and part of the first week of October.
The last boat of the season leaves Oct 8 weather permitting.
[quote="nudel"]Ah, it's not a bug, it's because the command is being parsed twice after it's generated: First by MS-DOS and then by Opus.
Try using two " instead of "' and '". If that doesn't work try using three, and so on. MS-DOS does strange things to quotes sometimes but it usually starts to work if you add enough of them (but not too many ). Usually you only need two.
Something like this should work, although I haven't tried it:
@nofilenamequoting
dopusrt /cmd CreateFolder NAME=""{destpath}{file$|noext}""
The doptest tool by Tanis is good here for checking the command that you're generating after it's been processed by MS-DOS.[/quote]
Thanks for the pointer to doptest. It has allowed me to establish that this is a bug (IMO) but before I report it I thought it would be prudent to let the experts have a look. This works....
@nofilenamequoting
dopusrt /cmd CreateFolder NAME=""{destpath}{file$|noext}"
Note the mismatched number of opening (2) and closing (1) double quotes. If I add a second closing double quote, it fails.
Seems to work for me, although I'm running a version that's slightly different to the release version (but not very different in this regard as far as I know).
You can see exactly what's being generated by setting the type to MS-DOS, adding a Pause command to the end (so the temp file isn't deleted) and then going to %TEMP% and viewing the most recent dop*.bat file which will contain the command Opus generated.
It's worth remembering that MS-DOS may move quotes around when it parses things. Removing the = signs might solve the problem.
@aussieboykie
There is an issue. But, don't worry about reporting it. I've been typing issues up all day and this is one of my top three that I have been working on.
Instead, let's work together and focus on finding all the things that do not work that should work (that is, they are supported by documented conventions in the User Guide, the Help File, or in a FAQ here on the Centre). We should also try to find which methods do work for workaround purposes. (Jon already posted one to this thread, which Nudel and I also discussed offline earlier today.)
I've attached a toolbar with the following:[ol][li] Initialize Test Cases: Creates the test folder below and populates it with several test folders and files. Use the same button to re-initialize the folder between tests.
%SystemDrive%\Opus 8 Testing\KA00068 -- Quotes in Commands\Test Cases[/li]
[li] CreateFolder Menu - Contains 6 buttons, each with a different syntax variation of this command.[/li]
[li] Copy CREATEFOLDER Menu - Contains 6 buttons, each with a different syntax variation of this command.[/li]
[li] Add Selected to Favorites Menu - Contains 6 buttons, each with a different syntax variation of this command.[/li][/ol]Each button menu contains 6 buttons each with a different syntax variation of the command the menu is named after. The first three buttons are labeled as issues, since that syntax produces errors for at least one of the three different commands. The last three buttons are labeled as workarounds, since these syntaxes seem to work for all three commands.
These are the 6 different syntaxes used:[ol][li] dopusrt /CMD Command ARGUMENT={code value containing spaces}[/li]
[li] dopusrt /CMD Command ARGUMENT="{code value containing spaces}"[/li]
[li] @nofilenamequoting
dopusrt /CMD Command ARGUMENT="{code value containing spaces}"[/li]
[li] @nofilenamequoting
dopusrt /CMD Command ARGUMENT=""{code value containing spaces}""[/li]
[li] dopusrt /CMD Command ARGUMENT "{code value containing spaces}"[/li]
[li] dopusrt /CMD Command ARGUMENT {code value containing spaces}[/li][/ol]In my tests:[ul][li] Syntaxes 1 and 2 error for the first two commands, but not the third command.[/li]
[li] Syntax 3 errors for all three commands.[/li]
[li] Syntaxes 4, 5, and 6 work for all three commands.[/li][/ul]NOTE: Some errors generate error messages, some erroneous results (or no results).
I have Opus v8.2.2.4 U installed. I would like others who have been participating in this thread to download the toolbar and test each of the 18 commands and let me know if your results vary from mine.
Issue: KA#00068 - Commands: Opus incorrectly repositions quotations around external command codes Status: Analysis Date: KA00068--Quotes In Commands.dop (21.8 KB)
@nofilenamequoting
dopusrt /cmd CreateFolder Name ""{destpath}{file$|noext}""
@Ken,
I've downloaded your toolbar.
I'm working on it.
I can't run your Initialize Test Cases as I'm not on WinXP.
However, it's not much of a problem.
I understand your DOS well enough to proceed.
I use 4NT secondary to the DOpus batch file mode.
I use MS DOS in DOpus, but can easily Call or Execute a 4NT *.btm batch file from DOpus.
I have this line in my autoexec.bat:
set comspec=C:\4PROMPT\4NT\4NT.exe
Easy to turn on or off in MSconfig.
I'll just rewrite it to 4NT.
I'm not certain why you need the ping sleep commands.
4NT can easily do that kind of thing, but why bother?
Your batch file should execute just fine in 4NT without that.
In any case, I already see your point with this first toolbar.
I'll get a little more organized and report back.
I already know what the outcome will be though.
[quote="porcupine"]
I've downloaded your toolbar.
I'm working on it.
I can't run your Initialize Test Cases as I'm not on WinXP.
However, it's not much of a problem.
I understand your DOS well enough to proceed.[/quote]
You could also just manually make some test files in any old folder, just make sure you have 6 files and 6 folders for each Command. Just make sure they all have spaces in their names.
I use the :Sleep function (which uses the Ping command) to slow down the script a little, without actually stopping it for the following:[ol][li] So the user (usually me) can read some of the messages that otherwise zip by too quickly.
[/li]
[li] In some my other Opus toolbars still under testing, I use thousands of test cases (you have seen some of my test cases and used some yourself in other threads). During Test Case Re-Initialization, the whole test case folder gets deleted. It can take quite some time for Windows to get the word that the folder is successfully deleted. (The same timing issue that plagues us in a multi-step RegExp rename also plagues this command script). Thus I need the script to keep checking until the folder is actually removed, before continuing to recreate it and repopulate it with untouched test case files and folders. I use :Sleep to force the script to wait a consistent number of seconds between delete attempts and verification checks. After a certain number of unsuccessful verification checks, the script will inevitably prompt the user to take action.[/li][/ol]
Thanks !
I'll be looking into that with my rewrite.
Again thanks for the lucid explanation.
I'll let you know what I find in the short term,
and assuming I don't get marooned on North Manitou Island for the winter, long term.
@nofilenamequoting
dopusrt /cmd CreateFolder Name ""{destpath}{file$|noext}""
[/quote]
Yes. Playing around with Ken's testbed alerted me to the fact that the use of "=" after NAME affects the outcome. The documentation for CreateFolder refers to NAME, not NAME=, and the double quoting thing is normal enough DOS command resolution behaviour, so I'm OK that this is not really a bug. However, the documentation would benefit from being a bit more specific. For example, it states that "The NAME parameter can also be used to specify multiple folders to create simultaneously." but does not say how. I did some tests..
[code]@nofilenamequoting
dopusrt /cmd CreateFolder Name a,s,d,f creates a single folder called a,s,d,f
@nofilenamequoting
dopusrt /cmd CreateFolder Name a s d f creates four folders[/code]
If you use the CreateFolder dialog, then whatever you type in the box is taken to be a folder name - e.g. a s d f is one folder and a,s,d,f is also one folder, unless of course you tick the "Create multiple foders (comma separated)" box in which case it treats a,s,d,f as a request to create four folders and a s,d f as a request to create two folders, all of which is consistent.
[quote]@nofilenamequoting
dopusrt /cmd CreateFolder Name a,s,d,f creates a single folder called a,s,d,f
@nofilenamequoting
dopusrt /cmd CreateFolder Name a s d f creates four folders[/quote]
Thankyou Aussieboykie.
I wasn't aware of that, but it does make some sense.
In the CreateFolder Dialog one does not need quotes for filenames that include space characters.
[quote="porcupine"]
In the CreateFolder Dialog one does not need quotes for filenames that include space characters.[/quote]
In fact the dialog is clever enough to refuse to accept " or indeed any other character that is not valid in a file name, such as : or | or ....
). Usually you only need two.