Sign in to follow this  
Followers 0
KJohn

Windows 7: Run paths requiring manual addition of quotes

10 posts in this topic

#1 ·  Posted (edited)

I recently installed Windows 7 Professional RTM which I got from MSDN AA. There is this problem that I'm facing and I'm unable to figure out what exactly I need to fix:

Take this path: C:\Users\Koshy John\example.exe

Let's suppose the file exists:

- FileExists("C:\Users\Koshy John\example.exe") returns 1

- Run("C:\Users\Koshy John\example.exe") fails. But Run('"C:\Users\Koshy John\example.exe"') will succeed - note the quotes and the space in the path.

The only thing I can think of that could cause this behavior is turning off 8.3 filenames (I think they are disabled by default on each drive separately, I just changed that to a global behaviour. I turned it on again but with no avail.)

Do you remember any other setting within Windows that could cause this sort of behaviour? Or is it something wrong with AutoIt on Windows 7?

I don't mind "fixing" my code to take care of this problem but what sort of behaviour would extra quotes have on older operating systems?

UPDATE:

It is a file system problem. I rebooted into vista to check and only paths with spaces on my D: (where Windows 7 is installed) require me to enter quotes. It is not an AutoIt problem but if you know of a solution, let me know. I do wonder though: how can autoit play safe if such a situation arose randomly on one of the many machines it encountered?

UPDATE2:

After enabling 8dot3 on D:, I created a folder with a space in it and tried running an executable stored within it (without quotes), and it worked! But none of the older paths created when 8dot3 was disabled work without quotes (and that means just about everything else because Windows 7 turns off 8dot3 filename creation by default). I thought 8dot3 was for legacy applications and not for fundamental things like the Windows Run dialog (both Vista and 7)!

Now you must be wondering why I am not required to enter quotes on C: even though 8dot3 has been disabled, that is because it is enabled by default on Vista and most of the folders already had alternative 8dot3 names stored in the file system by the time I disabled it. But on the other hand, Windows 7 (and Windows 2008) starts off it's installation with 8dot3 disabled by default leading to none of the folders created before re-enabling 8dot3 having alternative shortnames at all!

I hope I have brought more clarity to the situation...

Update3:

ShellExecute works perfectly without quotes, just like fileexists. While Run continues to fail without quotes. I now think this must be taken to the AutoIt developers - would moving this topic to developer chat help?

Edited by Koshy John

Share this post


Link to post
Share on other sites



#2 ·  Posted (edited)

The Run command seem the have different effect on Windows 7.

But it's 100% alright.

See this >> Run("C:\Path\e r.exe param1 param2") what is the different?

Run('"C:\Path\e r.exe" param1 param2')

So Run("C:\Users\Koshy John\example.exe")

equals to running C:\Users\Koshy with param John\example.exe which will fail >_< for the reason.

I notice this also from the begining of Beta but never thing it would be a bug or anything.

Edited by athiwatc

Share this post


Link to post
Share on other sites

But this is breaking my applications that used to run perfect in Vista! It is ridiculous to sit and code around this - I can do it but what kind of a solution is that for something so fundamental!

Share this post


Link to post
Share on other sites

But this is breaking my applications that used to run perfect in Vista! It is ridiculous to sit and code around this - I can do it but what kind of a solution is that for something so fundamental!

Is the same thing happening if you code directly against the windows api (CreateProcessW)?


Broken link? PM me and I'll send you the file!

Share this post


Link to post
Share on other sites

But this is breaking my applications that used to run perfect in Vista! It is ridiculous to sit and code around this - I can do it but what kind of a solution is that for something so fundamental!

For Autoit Dev, You should add a File.Exist Check on the string. If the file does exist, add the " if not then don't.

For Koshy John, try ShellExcute it should not be that must slower.

Share this post


Link to post
Share on other sites

Using run with spaces in a file name will assume anything after the space is a command line entry.

FileGetShortName() should solve the issue if you have an issue escaping with extra quotes.


Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites

Using run with spaces in a file name will assume anything after the space is a command line entry.

FileGetShortName() should solve the issue if you have an issue escaping with extra quotes.

This is not the problem, it's the problem with Windows 7 and Vista have different result and this is kinda bad.

Share this post


Link to post
Share on other sites

It depends on the user name most likely. One appears to have a space.

Share this post


Link to post
Share on other sites

#10 ·  Posted (edited)

I have updated the first post with important information, please read that first.

Is the same thing happening if you code directly against the windows api (CreateProcessW)?

I am not sure how to do that but I know this is a file system problem that Windows itself is unable to work around. And consequently AutoIt.

Most notably, any string with a space in an autorun field or even the run dialog box pointing to the partition where paths with spaces in them were created while 8dot3 was disabled fails.

For Autoit Dev, You should add a File.Exist Check on the string. If the file does exist, add the " if not then don't.

For Koshy John, try ShellExcute it should not be that must slower.

This is one possible solution. ShellExecute works perfectly without the extra quotes.

Using run with spaces in a file name will assume anything after the space is a command line entry.

FileGetShortName() should solve the issue if you have an issue escaping with extra quotes.

I understand the parameter thing but from what I've understood so far, I think FileGetShortName will fail because there are no alternative shortnames stored in the file system if 8dot3 was set to disabled when the relevant path was created.

This is not the problem, it's the problem with Windows 7 and Vista have different result and this is kinda bad.

And exactly why this is happening is detailed in the first post. Edited by Koshy John

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0