Launching files with commas or spaces in file path

[montanan]

I have a very simple test that I am trying to run in Windows 7

Code: Select all

Let>path=C:\test, inc\file.txt
executefile>%path%

I get an error every time. I have tried putting single quotes and double quotes at both ends of the "path" but I have not been able to get it to run.

Any workarounds others have come up with are appreciated!

-Richard
[/code]

[JRL]

After doing a little testing, it appears that ExecuteFile> is not behaving the same as other functions when it comes to a comma wrapped in a variable. The behavior I see is consistent with the ExecuteFile> function detecting the comma then terminating the first parameter at the comma and using everything after the comma as a second parameter. Other functions pass commas wrapped in variables on and do not treat them as parameter delimiters. For example if you remark out the ExecuteFile> and add a Writeln> the Writeln> function will work properly with the "path" variable.

WriteLn>%path%,wres,Text to be added

As a workaround you could use the RunProgram> function.

Code: Select all

Let>path=C:\test, inc\file.txt
//executefile>%path%
Run>notepad %path%

[montanan]

Thank you, JRL.

While it is certainly not convenient to determine the source application for each file type in order to run it, at least what you proposed will work.

I sure hope the the ExecuteFile command syntax can be changed so that it will work more seamlessly in these situations.

[Marcus Tettmar]

Do this:

Executefile>C:\test, inc\file.txt,

Or:

Let>path=C:\test, inc\file.txt
Executefile>%path%,

[JRL]

Thanks Marcus. That works.

So... in an attempt to understand: The trailing comma supersedes the comma embedded in the variable and negates the use of the post comma portion of the variable value being used as the "optional parameter" ?

[montanan]

Thank you, Marcus.

A big help!

Adding some very clear instructions to the Help file / Command instructions would also make this much more clear.

-Richard

[jpuziano]

Adding some very clear instructions to the Help file / Command instructions would also make this much more clear.

Yes perhaps it would.

What do you think Marcus? Is this an example of something that could/should be covered off with a narritive or example?

How do you decide whether to include something related to a command in the Help File or not?

[Marcus Tettmar]

I've already replied to an email from the OP saying that it will be sorted. It should work like all other functions. So was surprised to see the suggestion to change the help file given I'd already told the OP that we'd look at improving the command. Could change the help file, but I think would be best to fix to work as documented and as all other commands do.

[jpuziano]

I've already replied to an email from the OP saying that it will be sorted.

Ahh... sorry, I had no way of knowing that as your one post on this thread only offered workarounds.

It should work like all other functions.

Absolutely...

So was surprised to see the suggestion to change the help file given I'd already told the OP that we'd look at improving the command.

Maybe the OP thought it would take a long time to get the command improved? Maybe they forgot about (or didn't see) your email?

Could change the help file, but I think would be best to fix to work as documented and as all other commands do.

Again, absolutely agree. No need to document workarounds in the Help File when soon the command will be improved and the workarounds not needed... Carry on then and thanks for all you do.