Problem with Environment.GetCommandLineArgs() ?

[Chad Z. Hower aka Kudzu]

Im using Environment.GetCommandLineArgs().

However some of the arguemtns passed in have spaces, so I enclosed them in
"".

For example:

"c:\temp\My area\"

The problem is when I access this as an element of the string array it
treating the last \" (And maybe others" as escape characters. So array
element [1] actually gets:

"c:\\temp\\My area\""

or

@"c:\temp\My area""

Am I just missing something obvious?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

[Tom Porterfield]

Chad Z. Hower aka Kudzu wrote:

Im using Environment.GetCommandLineArgs().

However some of the arguemtns passed in have spaces, so I enclosed
them in "".

For example:

"c:\temp\My area\"

The problem is when I access this as an element of the string array it
treating the last \" (And maybe others" as escape characters. So array
element [1] actually gets:

"c:\\temp\\My area\""

or

@"c:\temp\My area""

Am I just missing something obvious?

What's wrong with @"c:\temp\my area"? You use @-quoting when you don't want
escape sequences to be processed. That's what @-quoting is for and the
example you list is a textbook example of when to use it.
--
Tom Porterfield
MS-MVP MCE
http://support.telop.org

Please post all follow-ups to the newsgroup only.

[Chad Z. Hower aka Kudzu]

"Tom Porterfield" <tp******@mvps.org> wrote in
news:e#**************@TK2MSFTNGP12.phx.gbl:

What's wrong with @"c:\temp\my area"? You use @-quoting when you don't
want escape sequences to be processed. That's what @-quoting is for and
the example you list is a textbook example of when to use it.

So Im supposed to tell my users that because of a problem in C# that unlike
any other command line utilty they have to pass argumetns prefixed with a @?

So now we have type DOS comamnds like this:

copy @"c:\my area\*.*" @"d:\temp area\"

?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

[jerry]

This may be a problem with the Windows command line
interpreter, not .NET. The CLI sees a '\"' as a literal quote.
So you get a path with a quote char at the end instead of
a backslash.

The solution is to not end paths with a backslash
or to discard any quotes at the end of the path
with a String.TrimEnd.

Chad Z. Hower aka Kudzu wrote...

Im using Environment.GetCommandLineArgs().

However some of the arguemtns passed in have spaces, so I enclosed them in
"".

For example:

"c:\temp\My area\"

The problem is when I access this as an element of the string array it
treating the last \" (And maybe others" as escape characters. So array
element [1] actually gets:

"c:\\temp\\My area\""

or

@"c:\temp\My area""

Am I just missing something obvious?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

[jerry]

This may be a problem with the Windows command line
interpreter, not .NET. The CLI sees a '\"' as a literal quote.
So you get a path with a quote char at the end instead of
a backslash.

The solution is to not end paths with a backslash
or to discard any quotes at the end of the path
with a String.TrimEnd.

Chad Z. Hower aka Kudzu wrote...

Im using Environment.GetCommandLineArgs().

However some of the arguemtns passed in have spaces, so I enclosed them in
"".

For example:

"c:\temp\My area\"

The problem is when I access this as an element of the string array it
treating the last \" (And maybe others" as escape characters. So array
element [1] actually gets:

"c:\\temp\\My area\""

or

@"c:\temp\My area""

Am I just missing something obvious?


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

[Chad Z. Hower aka Kudzu]

jerry <je***@nospam.com> wrote in
news:MP************************@msnews.microsoft.c om:

The solution is to not end paths with a backslash
or to discard any quotes at the end of the path
with a String.TrimEnd.

This is not a solution at all. Am I supposed to tell users "Dont put a
trailing /, there is a bug in Windows".

And the bigger concern is, is it just doing this at the end, or is it
possibly escaping other characters internally too? This is a fairly big bug
that I've seen lots of confirmations from other users.

I would hope MS plans to fix this.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

[Chad Z. Hower aka Kudzu]

jerry <je***@nospam.com> wrote in
news:MP************************@msnews.microsoft.c om:

The solution is to not end paths with a backslash
or to discard any quotes at the end of the path
with a String.TrimEnd.

This is not a solution at all. Am I supposed to tell users "Dont put a
trailing /, there is a bug in Windows".

And the bigger concern is, is it just doing this at the end, or is it
possibly escaping other characters internally too? This is a fairly big bug
that I've seen lots of confirmations from other users.

I would hope MS plans to fix this.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

[C# Learner]

jerry <je***@nospam.com> wrote:

This may be a problem with the Windows command line
interpreter, not .NET. The CLI sees a '\"' as a literal quote.
So you get a path with a quote char at the end instead of
a backslash.

The solution is to not end paths with a backslash
or to discard any quotes at the end of the path
with a String.TrimEnd.

Hmm... I see this problem with a .NET app that takes parameters, but
not with the following Delphi equivalent:

program Project1;

{$APPTYPE CONSOLE}

uses
SysUtils;

var
I: Integer;
begin
for I := 1 to ParamCount do
WriteLn(ParamStr(I));
ReadLn;
end.

Unless the ParamStr() is working around this...

[C# Learner]

jerry <je***@nospam.com> wrote:

This may be a problem with the Windows command line
interpreter, not .NET. The CLI sees a '\"' as a literal quote.
So you get a path with a quote char at the end instead of
a backslash.

The solution is to not end paths with a backslash
or to discard any quotes at the end of the path
with a String.TrimEnd.

Hmm... I see this problem with a .NET app that takes parameters, but
not with the following Delphi equivalent:

program Project1;

{$APPTYPE CONSOLE}

uses
SysUtils;

var
I: Integer;
begin
for I := 1 to ParamCount do
WriteLn(ParamStr(I));
ReadLn;
end.

Unless the ParamStr() is working around this...

[Chad Z. Hower aka Kudzu]

C# Learner <cs****@learner.here> wrote in
news:vh********************************@4ax.com:

Unless the ParamStr() is working around this...

Not that I know of. I've looked at the source before for this and didnt see
any work arounds unless a new one was added for Delphi 8.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

[Chad Z. Hower aka Kudzu]

C# Learner <cs****@learner.here> wrote in
news:vh********************************@4ax.com:

Unless the ParamStr() is working around this...

Not that I know of. I've looked at the source before for this and didnt see
any work arounds unless a new one was added for Delphi 8.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

[jerry]

When calling a Windows API such as FindFirstFile from Delphi,
I had to be careful about trailing backslashes in directory
names. But this may very well be a problem with .NET.

I certainly appreciate that someone posted this problem.
I now know I will have to put in some command-line
argument checks that weren't there before.

C# Learner wrote...

jerry <je***@nospam.com> wrote:

This may be a problem with the Windows command line
interpreter, not .NET. The CLI sees a '\"' as a literal quote.
So you get a path with a quote char at the end instead of
a backslash.

The solution is to not end paths with a backslash
or to discard any quotes at the end of the path
with a String.TrimEnd.

Hmm... I see this problem with a .NET app that takes parameters, but
not with the following Delphi equivalent:

program Project1;

{$APPTYPE CONSOLE}

uses
SysUtils;

var
I: Integer;
begin
for I := 1 to ParamCount do
WriteLn(ParamStr(I));
ReadLn;
end.

Unless the ParamStr() is working around this...

[jerry]

When calling a Windows API such as FindFirstFile from Delphi,
I had to be careful about trailing backslashes in directory
names. But this may very well be a problem with .NET.

I certainly appreciate that someone posted this problem.
I now know I will have to put in some command-line
argument checks that weren't there before.

C# Learner wrote...

jerry <je***@nospam.com> wrote:

This may be a problem with the Windows command line
interpreter, not .NET. The CLI sees a '\"' as a literal quote.
So you get a path with a quote char at the end instead of
a backslash.

The solution is to not end paths with a backslash
or to discard any quotes at the end of the path
with a String.TrimEnd.

Hmm... I see this problem with a .NET app that takes parameters, but
not with the following Delphi equivalent:

program Project1;

{$APPTYPE CONSOLE}

uses
SysUtils;

var
I: Integer;
begin
for I := 1 to ParamCount do
WriteLn(ParamStr(I));
ReadLn;
end.

Unless the ParamStr() is working around this...

[jerry]

Yes, you are right. I did some tests using batch files which had no
problem with text which contained a trailing backslash-quote sequence.
Microsoft fell on its face with this one. The only other suggestion I can
offer is to parse Environment.CommandLine instead of using incorrectly
pre-parsed args. But I'm sure you already tried that.

I'm using VS2002. I can only hope it is fixed in later versions.

Chad Z. Hower aka Kudzu wrote...

jerry <je***@nospam.com> wrote in
news:MP************************@msnews.microsoft.c om:

The solution is to not end paths with a backslash
or to discard any quotes at the end of the path
with a String.TrimEnd.

This is not a solution at all. Am I supposed to tell users "Dont put a
trailing /, there is a bug in Windows".

And the bigger concern is, is it just doing this at the end, or is it
possibly escaping other characters internally too? This is a fairly big bug
that I've seen lots of confirmations from other users.

I would hope MS plans to fix this.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

[jerry]

Yes, you are right. I did some tests using batch files which had no
problem with text which contained a trailing backslash-quote sequence.
Microsoft fell on its face with this one. The only other suggestion I can
offer is to parse Environment.CommandLine instead of using incorrectly
pre-parsed args. But I'm sure you already tried that.

I'm using VS2002. I can only hope it is fixed in later versions.

Chad Z. Hower aka Kudzu wrote...

jerry <je***@nospam.com> wrote in
news:MP************************@msnews.microsoft.c om:

The solution is to not end paths with a backslash
or to discard any quotes at the end of the path
with a String.TrimEnd.

This is not a solution at all. Am I supposed to tell users "Dont put a
trailing /, there is a bug in Windows".

And the bigger concern is, is it just doing this at the end, or is it
possibly escaping other characters internally too? This is a fairly big bug
that I've seen lots of confirmations from other users.

I would hope MS plans to fix this.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

[Chad Z. Hower aka Kudzu]

jerry <je***@nospam.com> wrote in
news:MP************************@msnews.microsoft.c om:

Yes, you are right. I did some tests using batch files which had no
problem with text which contained a trailing backslash-quote sequence.
Microsoft fell on its face with this one. The only other suggestion I
Yep. :)

Would be nice to get someone from MS to acknowledge if they know of this or
not...
I'm using VS2002. I can only hope it is fixed in later versions.

Im using 2003. :)

Are you using .net 1.1. or 1.0?
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

[Chad Z. Hower aka Kudzu]

jerry <je***@nospam.com> wrote in
news:MP************************@msnews.microsoft.c om:

Yes, you are right. I did some tests using batch files which had no
problem with text which contained a trailing backslash-quote sequence.
Microsoft fell on its face with this one. The only other suggestion I
Yep. :)

Would be nice to get someone from MS to acknowledge if they know of this or
not...
I'm using VS2002. I can only hope it is fixed in later versions.

Im using 2003. :)

Are you using .net 1.1. or 1.0?
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"