 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / June 2007External process fails with switch arguments
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. 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. 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. > Sometimes you think too hard :-) > [quoted text clipped - 3 lines] > 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. > 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 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. 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... On Thu, 21 Jun 2007 09:56:01 -0700, michael sorens <m_j_sorens@newsgroup.nospam> wrote: > 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 > 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 >> 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. [quoted text clipped - 35 lines] > 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? > Pete > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.