Windows/quotes/"start" (was Re: Having problem getting quotation marks with SYSTEM)

[Brian K. White]

On 11/15/2011 11:45 AM, Boaz Bezborodko wrote:
> Mirrotek International, LLC 90 Dayton Avenue Building 1-F Passaic, NJ
> 07055 Tel: 973-472-1400 x.112 Fax: 973-472-5170
> On 11/15/2011 11:41 AM, Kenneth Brody wrote:
>> On 11/15/2011 11:28 AM, Boaz Bezborodko wrote:
>> [...]
>>> When I try to open the pdf file with a Windows "Start [filename]" it
>>> doesn't
>>> work with a space and doesn't work with quotation marks.
>>
>> This is a "design flaw" (IMHO) in the "start" command.  If the first
>> parameter starts with a quote, then it is taken as the title to give
>> the window.  (There is no flag, such as "/title:", to specify this.
>> It's based purely on the existence of that quote.)
>>
>> Therefore, this doesn't work as one might expect:
>>
>>      start "c:\path\to\filename with spaces.ext"
>>
>> Rather than opening the specified file, you will get a new command
>> window, with the given string as the window title.
>>
>> I learned long ago to include a null quoted string:
>>
>>      start "" "c:\path\to\filename with spaces.ext"
>>
>>> I'm sure there a simple edit I can use to strip out spaces, but I
>>> just get
>>> my head around it right now.
>>>
>>> (I can get the edit syntax if I spend a bunch of time to grok it, but
>>> I then
>>> forget it until a few years later when I might need it again.)
>>
>
> OK, that solves one problem, but I'm still not getting the quotation
> marks when I execute
> SYSTEM "ECHO !PDF \"/f\\server\data\fpro\temp\ "{[filename]{"\">>
> "&[anotherfilename]
>
> An edit to strip out the spaces would also solve my problem.


1) Getting string handling routines to robustly handle spaces and quotes 
as they pass the string from handler to handler (processing to system to 
cmd.exe to echo to a file to whatever will read the file...) is always 
an exercise in trial & error, systematic not random! and almost always 
worth it. Simply do not expect the first thing you try to work, and do 
expect to add more layers of quoting or escaping until the final item 
looks like you want. Sometimes it helps to work backwards. If you can't 
visualize each holder of the string that needs to be addressed and how 
to do it, then instead try starting with a hand crafted end result and 
make sure that actually works. Make a file by hand that has !PDF "some 
file" in it and feed it to printwizard manually and verify that actually 
works, and figure out whatever it takes to make that work until it does. 
THEN try to make an echo command that produces the same end result 
string into a file. Work on that until that actually works. THEN try to 
make a filepro system command that produces that echo command.

2) For this particular task, why even use system echo to do that? Just 
use filepro's own file i/o commands to create the file and write 
whatever you want in there with no special problems about spaces or 
quotes. Or at least, there will only be one single layer of special 
handling and you will be more used to that and better able to see it. 
You'll know if you want a literal " in a file you can use \" or 
chr("34") etc.

s = "!PDF \"some other file\""
f = "some file"
h = open(f,"c0wt")
x = writeline(h,s)
x = close(h)

In the above command, you have to think like the computer, or rather, 
like each piece of software that will handle that string along the way.

Repeating myself a little to expand on 1) above.

Try to do a command manually at the cmd prompt and tweak that until it 
works. Your single backslash above, before the /f// escapes the quote so 
that filepro's system command doesn't "see" that quote, but the system 
command "eats" that backslash, because filepro knows you didn't really 
want a backslash in the string, you just put it there to tell filepro to 
ignore and special meanings of the next character.

So what does that result in? What is the final string that the system 
command will hand over to windows to execute? It will be an echo command 
with a quotes around part of the string, no backslashes. In a SANE OS, 
those quotes would be part of the echo command and merely contain the 
string to be echo'd and not be a literal part of the string itself that 
echo actually echos, but, I just tried at least on win7 cmd.exe, echo 
"hello there" >>file.txt results in "hello there" in the file, including 
quotes. It's an insane way to get there but it IS the end result you 
happen to want. So, you have some other problem:

* If the quotes are not in the output file, then you are not actually 
using the code shown above.

* If the quotes are in the file but printwizard isn't doing what you 
want, then perhaps you need something other than !PDF "file name" to 
make printwizard see "file name".

Have you tried manually constructing a file to figure out what it takes 
to make printwizard do what you want? What does that file look like? 
Only when we know what the end result needs to be for sure, can we say 
how to produce it.

-- 
bkw