Shell command language bug? - (Moved)

[moosjuice]

For this experiment first we're going to make 2 folders in C:\ or whichever drive. New folder and Newfolder. In both were putting File.txt which can be blank.

Now we're going to make a quick script to open File in both folders. Let's look at the documentation. https://ss64.com/nt/start.html

Always include a TITLE this can be a simple string like "My Script" or just a pair of empty quotes ""

Alright we will leave the empty quotes. And it looks from this that the quotes are there to account for spaces.

Open a file with a particular program:
START "" "C:\Program Files\Microsoft Office\Winword.exe" "D:\Docs\demo.txt"

And we can disable the particular program part altogether.

Non-executable files can be invoked through their file association just by typing the name of the file as a command. (e.g. WORD.DOC would launch the application associated with the .DOC file extension).

So this should work.

Global Const $sFilePath = "C:\New folder\File.txt"

Run(@ComSpec & " /c start " & '"" "' & $sFilePath & '"', "", @SW_HIDE)

Perfect. All that's left is that the surrounding quotes are part of Microsoft's plan. So if we take off the surrounding quotes it won't work on the other folder, regardless of intuition that it doesn't need the quotes in that case. The "" is for the title being the same, leave nothing for your default program, but your default program won't know what to do without the surrounding quotes.

Global Const $sFilePath = "C:\Newfolder\File.txt"

Run(@ComSpec & " /c start " & '""' & $sFilePath, "", @SW_HIDE)

And it doesn't.

But surely, that means completely aping the code will not work

Global Const $sFilePath = "C:\Newfolder\File.txt"

Run(@ComSpec & " /c start " & $sFilePath, "", @SW_HIDE)

NOPE! WORKS. You can save your characters, have a working program and think absurdly that this will translate into directories with spaces. How naive the fool!

Global Const $sFilePath = "C:\New folder\File.txt"

Run(@ComSpec & " /c start " & '"' & $sFilePath & '"', "", @SW_HIDE)

 

Edited June 14, 2019 by moosjuice

[Jos]

Moved to the appropriate forum.

Moderation Team

[Jos]

1 hour ago, moosjuice said:

And it doesn't.

You are missing a space after ""

Run(@ComSpec & " /c start " & '"" ' & $sFilePath, "", @SW_HIDE)

... and why the extra concatenation (which I see a lot of people do)?  Isn't this easier?

Run(@ComSpec & ' /c start "" ' & $sFilePath, "", @SW_HIDE)

Jos

Edited June 14, 2019 by Jos

[moosjuice]

Alright, now that I reflect those quotes were misonstrued to what even I was talking about in the last sentence, at a glance the quotes for default title look like the quotes next to @SW_HIDE side of the expression look like it's adjacent when actually it has to do with Autoit (working directory), on top of it that it is genreally neat to have quotes up against the side of anything else. This is a rare case where I would actually want to not concatenate because even though it's a separate parameter, it looks like all the quotes everywhere. But while now it's not anymore the dramatic crescendo I wanted, I still think it's a bug to support spaceless and have something not be able to be intuitively changed.

[Jos]

@moosjuice, 

Ever considered writing books? (referring to your elaborate writing style, which isn't easy for none english natives like me)  
The easiest way of checking is to simply write the total result with a consolewrite() to be able to check whether it is properly formed.

EDIT:

4 minutes ago, moosjuice said:

I still think it's a bug to support spaceless and have something not be able to be intuitively changed.

No idea what that means so please so a simple example of what in your mind is wrong and how it should be.

Jos

Edited June 14, 2019 by Jos

[BrewManNH]

Talk to Microsoft, it's their issue, they're the ones that require quotes around file paths/names with spaces in them.

The best way to check if your quotes are in the right places is to use ConsoleWrite on the command line for Run before using it in Run. ConsoleWrite will show you exactly how it will look to ComSpec when you Run it.

Second hint, NEVER EVER use /c or @SW_HIDE until your command runs successfully, only use those in production code or you're never going to see where you screwed up.

Edited June 14, 2019 by BrewManNH

[moosjuice]

@Jos

Thanks. I've always been the wordsmith, it helps to keep notes as you hear expressions. Still no one believes it's a bug, or absurd that it doesn't translate from spaceless to spaces. To put it another way as a programming language you can't have arbitrary rules because they are superfluous. Users expect the language to be compact, when there is a precedent set because of that assumption they will try to use the rest of the program as though that's the only way it will be recognized.

@BrewManNH

That's good advice. I've been starting to use ConsoleWrite but for GUIs it can also be satisfying to use the message boxes. I've been lucky that all I've done is low level file operations while being blind and just AB testing but to be safe hobbyists should check out https://ss64.com/nt/cmd.html and take advantage of the full parameters you can set to CMD as you safely view it.

[Jos]

1 minute ago, moosjuice said:

Still no one believes it's a bug, or absurd that it doesn't translate from spaceless to spaces.

I don't know yet as I haven't seen any example that clearly (for me) proves your point and isn't covered by a word-wall. 
So do me a simple favor and show a basic runnable example that in your mind should work and doesn't.  

Jos

[moosjuice]

4 hours ago, moosjuice said:

that means completely aping the code will not work

Global Const $sFilePath = "C:\Newfolder\File.txt"

Run(@ComSpec & " /c start " & $sFilePath, "", @SW_HIDE)

NOPE! WORKS. You can save your characters, have a working program and think absurdly that this will translate into directories with spaces. How naive the fool!

Global Const $sFilePath = "C:\New folder\File.txt"

Run(@ComSpec & " /c start " & '"' & $sFilePath & '"', "", @SW_HIDE)

^Doesn't work

 

[BrewManNH]

5 minutes ago, moosjuice said:

^Doesn't work

This is what I get with that exact code above, except I used a consoleWrite, like I told you to do, instead.

Global Const $sFilePath = "C:\New folder\File.txt"
;~ Run(@ComSpec & " /c start " & '"' & $sFilePath & '"', "", @SW_HIDE)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : @ComSpec & " /c start " & ''"'' & $sFilePath & ''"'' = ' & @ComSpec & " /c start " & '"' & $sFilePath & '"' & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

This is the output from that.

Quote

C:\WINDOWS\system32\cmd.exe /c start "C:\New folder\File.txt"

Properly formatted, and with quotes in the right place, so I don't see why it won't work.

 

Instead of crying bug, try using some error checking before.

[Nine]

It is not a bug of the autoit run function.  I would call it a feature of the start command.  You can go directly into a cmd.exe console and execute the same commands you were testing and it will react exactly in the same manner.  

[Jos]

As already mentioned by the 2 previous posts:

You are shelling this command: 

C:\WINDOWS\system32\cmd.exe /c start "C:\New folder\File.txt"

Which indeed fails from the CMD.exe prompt.
... but why not simply use ShellExecute() as that is made for this?:

ShellExecute($sFilePath)

Jos

[moosjuice]

16 minutes ago, BrewManNH said:

This is what I get with that exact code above, except I used a consoleWrite, like I told you to do, instead.

Global Const $sFilePath = "C:\New folder\File.txt"
;~ Run(@ComSpec & " /c start " & '"' & $sFilePath & '"', "", @SW_HIDE)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : @ComSpec & " /c start " & ''"'' & $sFilePath & ''"'' = ' & @ComSpec & " /c start " & '"' & $sFilePath & '"' & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

This is the output from that.

Properly formatted, and with quotes in the right place, so I don't see why it won't work.

 

Instead of crying bug, try using some error checking before.

You are totally ahead of your skiis. Try reading my post before claiming to know what is the proper format of the Start function.. and then run it yourself from the Run prompt.

13 minutes ago, Jos said:

 

Which indeed fails from the CMD.exe prompt.

We have confirmation. Thanks for the function but my work here is done.

[BrewManNH]

38 minutes ago, moosjuice said:

Try reading my post before claiming to know what is the proper format of the Start function

Try using error checking before thinking you know more than others do. I was only looking at the format of the quotes and the string, I couldn't care less what the format of the Start command is, it's immaterial. I assumed that you were smart enough to have figured out how to properly format the command line for what you wanted it to do. I don't play in the command console much these days unless absolutely necessary.

[Jos]

Mmm ... Guess I've seen enough here as there are too many words countering words and not enough substance.

Enjoy.

Jos

[moosjuice]

@Jos

You are not innocent in all this. You moved my thread from the PowerShell to Autoit, leading @BrewManNH to think I was complaining about autoit. I was going to complain about it earlier but that was on the assumption that @BrewManNH was only talking about the piece of code that I corrected and not the very basic, easy to interpret what was going to the command prompt pieces of code at the bottom, but it escalated a bit quickly. I also slightly disagree that even if it was in Autoit, or if there was a debug tool for CommandLine, I would consider everytime someone had to use that for something as basic as what's on the bottom (because 2 syntaxes exist to do the same thing), that it is a damage control mechanic for a bug.

[Jos]

wtf is wrong with you? 
You posted an AutoIt3 script question in the wrong forum so it got moved....  deal with it and stop the arguing for a change.

Jos

[JLogan3o13]

As has been seen many times, and I am willing to bet experienced many times yourself throughout your life - admit it to anyone else or not - even if your post had merit, the message was lost amid your unfounded arrogance (as it was pointed out you were simply doing things incorrectly) and your caustic demeanor toward others.

We are all for folks wanting to add to and improve the language but the comments made to others who have proven experience with the language and belittling their responses are not going to win you any friends here.

Edited June 14, 2019 by JLogan3o13