JT.exe and escaping " marks

[Igor Solodovnikov]

Does anyone know how to escape double quotes (") for setting
parameters using the jt.exe command? E.g. If I want to pass quotes
into the /sj Parameters="" command, or if I want to set a password
with a double quote and a space.

E.g.

/sc TaskUser "pass wo"rd"

I've tried doubling them up "pass wo""rd" preceeding with a \
"pass wo\"rd" and preceding with a ^ "pass wo^"rd" but nothing seems to
work.


Thanks

 

[Bill Stewart]

Does anyone know how to escape double quotes (") for setting
parameters using the jt.exe command? E.g. If I want to pass quotes
into the /sj Parameters="" command, or if I want to set a password
with a double quote and a space.

E.g.

/sc TaskUser "pass wo"rd"

I've tried doubling them up "pass wo""rd" preceeding with a \
"pass wo\"rd" and preceding with a ^ "pass wo^"rd" but nothing seems to
work.

AFAIK, this is not possible. It's a command-line parsing limitation of
jt.exe.

 

[dennis]

Hi,

Just in case you haven't seen it before, some programs accept:

'pass wo"rd'

I also thought you couldn't do it on JT.EXE which is why I general
start batch files.
I've got the funny feeling I'd got it to work recently, perhaps on some
of its subparameters though (I thought I'd used \")

Bye,
Dennis Bareis

 

[Bill Stewart]

Just in case you haven't seen it before, some programs accept:

'pass wo"rd'

I also thought you couldn't do it on JT.EXE which is why I general
start batch files.

A program's ability (or lack thereof) to parse a command line is usually
dependent on the compiler's RTL (runtime library) functions. If the RTL
implements some sort of quoting mechanism, then all's well. Another
option for authors is to use the GetCommandLine API and parse the string
themselves. This is a nuisance, of course, which is why most folks rely
on their compiler's RTL functions (e.g., the argc and argv arrays) to do
the parsing for them.

When I messed with jt.exe in the past, I thought I was not able to get
it to accept embedded quotes, but of course I could be wrong...