External process fails with switch arguments

[Guest]

I am attempting to fetch data from an external process. It seems to work OK
with regular arguments, but not with switch arguments. Here is an example of
a failure:
===================================
ProcessStartInfo psi = new ProcessStartInfo("date","/t");
psi.UseShellExecute = false;
psi.RedirectStandardOutput = true;
psi.RedirectStandardError = true;
psi.CreateNoWindow = true;
process = new Process();
process.StartInfo = psi;
process.Start();
===================================

My Nunit test case returns this:
===================================
TestCase 'CleanCodeTest.IO.ExecProcessTest.TestOneSwitchArg'
failed: Expected string length 13 but was 27. Strings differ at index 0.
Expected: "Wed 6/20/2007"
But was: "*** date: invalid date `/t'"
===================================

The MSDN documentation for ProcessStartInfo.Arguments sheds no light on
this; it is extremely sparse, essentially providing just an example and no
descriptive text.

 

[Steven Cheng[MSFT]]

Hi Michael,

From your description, you're using the System.Diagnostics.Process class to
launch some external program, but got some error behavior, correct?

Based on the code snippet you provided, the external program you launch is
a "date" application and will take some commandline arguments. Would you
provide some further information on the date application's code logic or
what's the expected behavior if you launch it interactively (without using
Process class) in commandline or through shell?

Also, I'm wondering whether the "date" program is also developed by you or
your team and if you have source code or symbol to perform live debugging
against it. If so, that'll be quite helpful for us to do further problem
tracking.

Please feel free to let me know if there is anything I missed.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

Sometimes you think too hard

I am simply using the DOS "date /t" command here which should return a value
like that shown in my test case. And it seems pretty clear that the problem
is in the .Net interface, not the "date" program itself.

 

[Ben Voigt [C++ MVP]]

Sometimes you think too hard

I am simply using the DOS "date /t" command here which should return a
value
like that shown in my test case. And it seems pretty clear that the
problem
is in the .Net interface, not the "date" program itself.

And I already independently produced his expected output, and verified that
it is "date.exe" being run, not a cmd.exe builtin.

 

[Peter Duniho]

Sometimes you think too hard

I think you're being too hard on him. He's just looking at your question
at face value, assuming that everything you've done there is intentional..

I am simply using the DOS "date /t" command here which should return a
value
like that shown in my test case. And it seems pretty clear that the
problem
is in the .Net interface, not the "date" program itself.

Well, except for the fact that the "date" that takes "/t" as an argument
isn't an executable program you can start using the fileName parameter of
the ProcessStartInfo class. If you go to a command prompt in Windows and
type "date", you get the built-in "date" command by default, but you can't
use that "date" command as input to the creation of a process.

On my PC, I don't even have a "date" executable anywhere, and I can't
start a process using that as the fileName parameter. If you do have a
"date" executable that you are running (as it appears that you do), then
you need to determine the correct arguments to use to get the output you
desire. From your original post, it appears that "/t" is not the correct
argument (though it is with the built-in "date" command).

For what it's worth, if you use this to create your ProcessStartInfo, you
get what you're asking for:

ProcessStartInfo psi = new ProcessStartInfo("cmd", "/c date
/t");

Though, it doesn't use your installed "date.exe" program, so if that was
intentional, you'll have to figure out what arguments to pass to your
installed "date.exe" program (as I suggest above).

Pete

 

[Guest]

Looks like false assumptions got in the way on both sides of the aisle here.
Once I became clued in from Peter's post, I saw why. To me, when I specified
"date" I expected to execute "date", just as if I typed it on the command
line. I did not imagine there were two different types of date, one builtin
and one standalone. Now all the prior discussion makes sense, and I see why
"cmd /c date /t" will, in fact, do what I expect.

Much obliged to all.

 

[Ben Voigt [C++ MVP]]

Interestingly, for me "date.exe /t" gives the expected output. Is that
still running a cmd.exe builtin? If so, I'd classify that as a bug.

(Tries with cygwin)
$ date.exe /t
date: invalid date `/t'
$ which date.exe
/usr/bin/date.exe

Seems like you might be running the cygwin (gnu-utils) version of date by
mistake. Check your path.

(Uses filemon to see what date.exe cmd calls)
No hits....

(Uses taskmgr to see what date.exe cmd calls)
None.

Looks like not only is "date" a cmd.exe builtin, so is "date.exe"??? Looks
like a bug...

Sometimes you think too hard

I think you're being too hard on him. He's just looking at your question
at face value, assuming that everything you've done there is intentional.

I am simply using the DOS "date /t" command here which should return a
value
like that shown in my test case. And it seems pretty clear that the
problem
is in the .Net interface, not the "date" program itself.

Well, except for the fact that the "date" that takes "/t" as an argument
isn't an executable program you can start using the fileName parameter of
the ProcessStartInfo class. If you go to a command prompt in Windows and
type "date", you get the built-in "date" command by default, but you can't
use that "date" command as input to the creation of a process.

On my PC, I don't even have a "date" executable anywhere, and I can't
start a process using that as the fileName parameter. If you do have a
"date" executable that you are running (as it appears that you do), then
you need to determine the correct arguments to use to get the output you
desire. From your original post, it appears that "/t" is not the correct
argument (though it is with the built-in "date" command).

For what it's worth, if you use this to create your ProcessStartInfo, you
get what you're asking for:

ProcessStartInfo psi = new ProcessStartInfo("cmd", "/c date
/t");

Though, it doesn't use your installed "date.exe" program, so if that was
intentional, you'll have to figure out what arguments to pass to your
installed "date.exe" program (as I suggest above).

Pete

 

[Peter Duniho]

Interestingly, for me "date.exe /t" gives the expected output. Is that
still running a cmd.exe builtin? If so, I'd classify that as a bug.

Well, then it's a bug that's been in the command line interpreter for
ages. My recollection is that the DOS CLI has always treated any name
followed by .exe or .com as the built-in command if no matching program is
found. Maybe I'm wrong and this was new to DOS 2.0 (which introduced a
lot of new features, relatively speaking). Hard to remember for sure,
going that far back.

But that shouldn't imply that a different mechanism that doesn't go
through the CLI should produce the same behavior. There's a big
difference between using an interactive interpreter and simply telling the
operating system to start a process. Any process must have some
executable from which the process is started. The only reason that the
CLI can map what looks like an executable file to a built-in command is
that the CLI is already running and can intercept that. But when starting
the process in the first place, there's no CLI running to do the mapping.
So an actual executable is required.

By explicitly specifying that the CLI is run ("cmd.exe"), then a command
can be passed to that CLI, and it's parsed just as it would have been had
the user typed it at the command prompt. Of course, replacing "date" with
"date.exe" in that case would result in the original behavior, assuming an
alternative "date.exe" was still installed, and if not would produce the
built-in "date" command.

[...]
Looks like not only is "date" a cmd.exe builtin, so is "date.exe"???
Looks
like a bug...

See above. The only reason that "date.exe" is a "built-in" is that it
matches in name with an existing built-in, and this is either by design,
or a very ancient, unnoticed, unresolved bug. If an actual date.exe had
been found in the path, that would be run instead.

Seems like reasonable behavior for the DOS CLI to me. But if you feel
it's a bug, I think you ought to report it to Microsoft.

Pete

 

[Ben Voigt [C++ MVP]]

Interestingly, for me "date.exe /t" gives the expected output. Is that
still running a cmd.exe builtin? If so, I'd classify that as a bug.

Well, then it's a bug that's been in the command line interpreter for
ages. My recollection is that the DOS CLI has always treated any name
followed by .exe or .com as the built-in command if no matching program is
found. Maybe I'm wrong and this was new to DOS 2.0 (which introduced a
lot of new features, relatively speaking). Hard to remember for sure,
going that far back.

But that shouldn't imply that a different mechanism that doesn't go
through the CLI should produce the same behavior. There's a big
difference between using an interactive interpreter and simply telling the
operating system to start a process. Any process must have some
executable from which the process is started. The only reason that the
CLI can map what looks like an executable file to a built-in command is
that the CLI is already running and can intercept that. But when starting
the process in the first place, there's no CLI running to do the mapping.
So an actual executable is required.

By explicitly specifying that the CLI is run ("cmd.exe"), then a command
can be passed to that CLI, and it's parsed just as it would have been had
the user typed it at the command prompt. Of course, replacing "date" with
"date.exe" in that case would result in the original behavior, assuming an
alternative "date.exe" was still installed, and if not would produce the
built-in "date" command.

[...]
Looks like not only is "date" a cmd.exe builtin, so is "date.exe"???
Looks
like a bug...

See above. The only reason that "date.exe" is a "built-in" is that it
matches in name with an existing built-in, and this is either by design,
or a very ancient, unnoticed, unresolved bug. If an actual date.exe had
been found in the path, that would be run instead.

Seems like reasonable behavior for the DOS CLI to me. But if you feel
it's a bug, I think you ought to report it to Microsoft.

Well, on every other shell I've ever used, if there is an alias for "date"
and I type "date.sh" or "date.pl" or whatever, it doesn't match the alias.

If the "help" command (or is it help.exe?) listed the builting commands with
the ".exe" extension then I would agree with the behavior. "date" alone
would search for "date.com" and "date.exe" and find the builtin. And
"date.exe" would match the builtin. But here I specified "date.exe" and the
builtin is named "date" and I can't see that being a match.

Is this behavior for built-ins documented somewhere?

 

[Peter Duniho]

Well, on every other shell I've ever used, if there is an alias for
"date" and I type "date.sh" or "date.pl" or whatever, it doesn't match
the alias.

For better or worse, you aren't using "every other shell". Every shell
has its own idiosyncrasies, and when one uses a particular shell, one
needs to be familiar with those idiosyncrasies. This particular shell is
deeply entrenched in the world of Windows, and I believe you are likely
stuck with its behavior, whether you like it or not.

[...]
Is this behavior for built-ins documented somewhere?

Probably, inasmuch as the NT/DOS command prompt behavior is documented at
all. It's not like a Unix shell that comes with a complete man document
describing every detail of its behavior. In large part, the behavior of
the command prompt UI is "documented" by the current behavior. Whatever
it does, that's what it's supposed to do.

But sure, it's entirely possible there's a document somewhere that
describes this as the intended behavior of the NT/DOS command prompt
interpreter.

Pete