Win7Tester has beentry9ing to understand this as long as I can remember. It is a very tricky concept. How can a uote be a quote and be quoted and yst ve a function.

Chr(n) is a function. It returns a character by index. Tis """" Creates a string with a quote inside. "" inside a sring crates a quote. Functionally they are all identicl. All methods put the quote character INSIDE of the variable where as:

myvar = "some values"

This places what is inside of the quotes into the variable. These quotes are syntactic. All of the other examples are of programmatic use of the character.

Even many experienced programmers fail to get this. I have seen some make the same assumptions and mistakes for years. I think it has to do with brain wiring. Sometimes we have been able to feed the prog4rammers a special diet and get them to
have a revelation. They are changed forever whenever this happens;) ( the exact diet is a trade secret)

That's not it either. That outputs an empty string, followed by the array element, followed by another empty string.

To output the " character inside a VBScript string, you have to double it. If you want to output a single
" character as a string, you have to write """" -- that is, open quote, two consecutive
" characters (which VBScript will then interpret as single
"), then close quote.

set shell=CreateObject("WScript.Shell")shell.Run "notepad c:\documents and settings\jsmith\test.txt"

That does not want quotes. In many cases adding them will cause failure. The need for quotes has nothing to do with VBScript. It is only an issue with CMD.EXE. Once a newbie gets that (or is it now 'probie') then this gets straightened out.

Remember, in my ancient code, the path is a numerically keyed element in a dictionary, and so does not have quotes around it. If it were a dictionary elelment in the working example above you could replace "c:\program files (x86)\dnotepad.exe" with
objdictionaryA(IndexPtr).

Remember, in my ancient code, the path is a numerically keyed element in a dictionary, and so does not have quotes around it. If it were a dictionary elelment in the working example above you could replace "c:\program files (x86)\dnotepad.exe" with
objdictionaryA(IndexPtr).

DAS

Your completely missed the point I was making. Your example is not the same as what I was posting.

That is patently false, and you'd know that if you ran the two examples.

The first one failed because there is no system alias for Program Files (x86), and RUN needed to know there was spaces in the path.

The second one worked because I added the Chr(34)s to let Run know how best to find the target program.

I was really hoping you could admit your statement was wrong, but I see you want to keep playing semantics.

Truth is, time and time again you've berated people to learn how Windows works. I learned, and presented a clear example of what does not work, followed by an example of what does work, and I haven't changed a single thing since the start.

In VBScript, there is no difference whatsoever between Chr(34) and """", because both represent the same character.

Whether you need to quote a path for the Run method is a completely separate issue. Keep in mind that " characters are not part of a path. From the perspective of a command-line parser, " means 'all text between " characters is a single argument'
(unless, of course, the parsing rules for the specific executable state otherwise). In other words, the quotes are not part of the path and are only there to help the command-line parser.

That is patently false, and you'd know that if you ran the two examples.

The first one failed because there is no system alias for Program Files (x86), and RUN needed to know there was spaces in the path.

The second one worked because I added the Chr(34)s to let Run know how best to find the target program.

I was really hoping you could admit your statement was wrong, but I see you want to keep playing semantics.

Truth is, time and time again you've berated people to learn how Windows works. I learned, and presented a clear example of what does not work, followed by an example of what does work, and I haven't changed a single thing since the start.

But, it is what it is.

DAS

Nope - didn't patent anything. It is well documented in the Win32 API.

Win7Testr - don't get so irritated about it. Eventually you will see why the debate is going the wy it is. I know it is hard for non programmers to get what is happening.

Bill has made the point again. What is happening in a Run string has nothing to do with quoting. You failed to understand my example because you are determined to make you argument work. Yes - it is possible to turn the example on its head
to prove your point but it does not help you to understand what I was showing you.

This same issue is much easier to understand in 'C' like languages. The use of a real escape character may help. In VB languages quote escapes itself.

I hope you will also forgive me for "funning" around but this is a very amusing debate.

Remember, in my ancient code, the path is a numerically keyed element in a dictionary, and so does not have quotes around it. If it were a dictionary elelment in the working example above you could replace "c:\program files (x86)\dnotepad.exe" with
objdictionaryA(IndexPtr).

DAS

Just one more comment about what happens with Process.Create. When passed from Run the first string on the line is assumed to be the executable name. If this is not true then, as Bill has pointed out, the string can be quoted to help the conversion
to work as intended

THe point of my post was to show that the Run is not the issue when you oplace all or the arguments after the program name "notepad" because "notepad" does not care about argumetns. It assumes everything on the commandline is a file name.
When we use CMD.EXE this is not the case.

Quotes, again, in this case, have nothing to do with the original question.

There is NO difference between """" and Chr(34). It does notmatter what other arguments are made. They are functionally identical.

Notepad is a notable (no pun intended) exception to the "quote your filename and path on the command line " rule. Its command-line parser is clever enough to simply read the command-line string and use that as the name of the file you intend to open (no
quotes required). The quotes don't break it either, though.

Not all programs are that clever and simply use the C runtime library command-line parser. In general, this means that you should quote strings that contain spaces when passing to a program's command line so the command-line parser understands your intentions.

Notepad is a notable (no pun intended) exception to the "quote your filename and path on the command line " rule. Its command-line parser is clever enough to simply read the command-line string and use that as the name of the file you intend to open (no
quotes required). The quotes don't break it either, though.

Not all programs are that clever and simply use the C runtime library command-line parser. In general, this means that you should quote strings that contain spaces when passing to a program's command line so the command-line parser understands your intentions.

Bill

No matter how you parse it this still has absolutely nothing to do with VBScript quotes and Chr(34).

We all know why it isn't, but that's besides the point, it absolutely is not equivalent; Always. It doesn't matter that the Testit(1) line is syntactically incorrect, it matters that """ does NOT get you what Chr(34) does in every case, and when
people make statements like that, those asking for advice are more than willing to treat it as gospel, coming back to find out why it doesn't work every time as they were told.

That and of course Run absolutely requires a complete path, without the Chr(34) pair, it bombs on the first space. Thats how it works.

I think you misread what we have been saying. You wrote """ --- three consecutive " characters is an incomplete string in VBScript.

"""" is a complete string in VBScript: It is a string containing one " character. (You need four " characters in a row, not three.) When VBScript sees two "" inside a string, it interprets it as one ".

And Bill, again, I couldn't care less if the line is incorrect, """ is not equivalent.

It's funny to see testosterone at work. Two grown men showing concrete examples where their insistance falts flat.

JRV even used this english "is not true then, as Bill has pointed out, the string can be quoted to help the conversion to work as intended". Help? Absolutely required, run my dnotepad example in it's entirety.

Instead, he could have said "I was wrong, but allow me to explain" or "I was wrong", but of course testosterone is pretty impressive stuff.

Of course then he had to throw in the "I know its hard for non-programmers" old standby. Then to escape as best you can, both of you refere to the original question as if it is some sacroscint example that negates discussion of where absolute statements
can come under fire.

You guys are a hoot. Office scripting? Check with office groups (who use VBA and know little to no VBS). Tables? Check with the office product groups for the app you are using to create tables. Home projects?
This is a systems administration scripting forum. Nevermind Ed Wilson went into Office, Media player, and all manner of windows scripting, even hinting end users could use scripting to automate their Windows systems if they paid attention.
But suddenly this is a sysadmin forum. Did Ed sign off on the change?

And Bill, again, I couldn't care less if the line is incorrect, """ is not equivalent.

Of course it isn't. Nobody said it was. What we're saying is that the complete string """" (four consecutive " characters) equates to a string, in VBScript, containing a single " character. Not three " characters. Four. For some reason, we seem not to have
been successful in communicating this fact.

But suddenly this is a sysadmin forum. Did Ed sign off on the change?

This forum has always had a system administration focus, as long as I've been a moderator (and even longer, as I recall). What we don't want is for the forum to get littered with unanswerable drive-by questions.

I don't know what the gripe has to do with this specific question, though, and we seem to have gotten off-topic. So unless you have another question, we need to leave this question and move on.

Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.