Command line arguments

[fj]

I need to get the command line typed to a console program. If the command was:

indigo <c:\wr52\in.txt

I would like to get back what was typed. I've tried the
Environment.CommandLine property and all I get back is the word indigo.

I need to know the details of the file redirection.

Is there anyway of getting the name of the file redirected to input?

 

[Tim Roberts]

I need to get the command line typed to a console program. If the command was:

indigo <c:\wr52\in.txt

I would like to get back what was typed. I've tried the
Environment.CommandLine property and all I get back is the word indigo.

I need to know the details of the file redirection.

Sorry. Those details are, so to speak, "none of your business".

Is there anyway of getting the name of the file redirected to input?

No. Those are not command-line arguments, and they are not the
responsibility of your program. They are merely directives to the shell --
cmd.exe in this case.

If you need to know the file name, then forget about using redirection and
change your interface to pass the file name as an argument:

indigo c:\wr52\in.txt

 

[Tim Jarvis]

I need to get the command line typed to a console program. If the
command was:

indigo <c:\wr52\in.txt

I would like to get back what was typed. I've tried the
Environment.CommandLine property and all I get back is the word
indigo.

I need to know the details of the file redirection.

Is there anyway of getting the name of the file redirected to input?

Raymond Chen just recently blogged about this, I think that he mentions
a couple of ways to do this, 1 unsupported mechanism and 1 WMI method.

http://blogs.msdn.com/oldnewthing/archive/2009/02/23/9440784.aspx

Regards Tim.

 

[Tim Roberts]

Now, all _that_ said, for the specific example given, the OP has a very
specific need: to "know the details of the file redirection". In other
words, while his question asks about a specific solution to a problem, he
probably doesn't actually care about the exact solution, but rather simply
that his problem is solved.

Since while the process is running, there is in fact a standard input
stream, and it does in fact _have_ to be connected to the file in
question, my guess is that there _is_ some way to map the stream back to
the file.
...
In other words: dig around to look for some kind of API that, given the
Stream instance that corresponds to the standard input (i.e.
Console.OpenStandardInput()), see if there's a way to map that back to the
underlying OS object, and from there to the actual file involved.

It turns out there are two ways to do this in unmanaged code, one
documented, one undocumented, neither of them easy.

You can take get the operating system HANDLE by doing
_get_osfhandle( fileno( stdin ) )

The documented method of converting that to a file name is to use
CreateFileMapping
MapViewOfFile
GetMappedFileName
(That returns a device-relative name, as in
\Device\HarddiskVolume2\tmp\x.cpp)
GetLogicalDeviceStrings
QueryDosDevice
(This lets you convery to C:\tmp\x.cpp)

There's actually a knowledge base article describing this.
http://msdn.microsoft.com/en-us/library/aa366789.aspx

The undocumented method is a lot shorter, using NtQueryInformationFile.

However, this is all the wrong solution. The right solution is to design
the interface to the program so that you PROVIDE it the information it
needs. Hence, don't use redirection if you need the input file name.