Problem with Environment.GetCommandLineArgs() ?

  • Thread starter Thread starter Chad Z. Hower aka Kudzu
  • Start date Start date
C

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 said:
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?
Click to expand...

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.
 
Tom Porterfield said:
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.
Click to expand...

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\"

?
 
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...
 
jerry said:
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.
Click to expand...

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.
 
jerry said:
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.
Click to expand...

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 said:
Unless the ParamStr() is working around this...
Click to expand...

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.
 
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...
 
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 said:
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
Click to expand...

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.
Click to expand...

Im using 2003. :)

Are you using .net 1.1. or 1.0?
 
Back
Top