The question is whether or not you can do:
"cmd.exe /C my.exe > \"$ENV{SystemRoot}\\TEMP\\My_Temp_File.txt\""
--Toby Ovod-Everett
-----Original Message-----
From: Mark Dootson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 3:58 PM
To: Mark Dootson
Cc: Ovod-Everett, Toby; [email protected]
Subject: Re: [wxperl-users] grr, vista issues
To reply to my own post :-)
"cmd.exe /C my.exe" would work fine, but you don't get the output of
my.exe, for the reasons Toby pointed out regarding ShellExecute.
Mark Dootson wrote:
> Ah, I missed the elevated permissions bit.
>
> If you had an executable, 'my.exe' with an application manifest marked
for elevated permissions, wouldn't a command line of
>
> "cmd.exe /C my.exe"
>
> get you an elevated permissions request?
>
>
> Mark
>
>
>
> Ovod-Everett, Toby wrote:
>> His problem (seen from earlier in the thread) is that anything that
>> starts the process via CreateProcess doesn't work properly with
elevated
>> permissions. He has to start the process via ShellExecute to get the
>> elevated permissions to work properly, but he still needs to capture
the
>> output. Thus my proposal to write a custom app using PerlApp that is
>> marked as requiring elevated permissions and is started via
ShellExecute
>> and that in turn starts the C installer app using CreateProcess (or
>> system() or open(), which both use CreateProcess), but hopefully the
C
>> installer app will thus inherit the elevated permissions attached to
the
>> small wrapper PerlApp. The wrapper PerlApp can grab the output and
use
>> a file, named pipes, TCP/IP connection on localhost, or whatever to
send
>> data back to the parent process (it can't use STDOUT since it was
>> started via ShellExecute).
>>
>> --Toby Ovod-Everett
>>
>>
>> -----Original Message-----
>> From: Mark Dootson [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, July 03, 2007 2:24 PM
>> To: [email protected]
>> Cc: Ovod-Everett, Toby; Ed W
>> Subject: Re: [wxperl-users] grr, vista issues
>>
>> If buffering isn't your issue, you could take a look at
>> Wx::Perl::ProcessStream on CPAN. It may do what you want.
>>
>> Regards
>>
>> Mark
>>
>> Ovod-Everett, Toby wrote:
>>> Totally missed this reply for some reason . ..
>>>
>>> -----Original Message-----
>>> From: Ed W [mailto:[EMAIL PROTECTED]
>>> Sent: Saturday, June 16, 2007 11:54 AM
>>> To: Ovod-Everett, Toby
>>> Cc: wxperl-users
>>> Subject: Re: [wxperl-users] grr, vista issues
>>>
>>>> No, I wrote the app, so I don't think it buffers its output (or if
it
>>>> does then it can be changed)
>>> If it's using STDIO, it buffers by default as soon as STDIO
discovers
>>> that the output device isn't a console but is a file or STDIN of
>> another
>>> program. Thus $| in Perl (which should be set to 1 for handles
where
>>> you want to ensure that they do not buffer). Thus the common idiom:
>>>
>>> select((select(MYHDL), $|=1)[0]);
>>>
>>>
>>>> I had considered running the program via shellexecute, spooling the
>>>> output to a file and reading in the file. Seemed quite ugly
>> though...
>>>> I hadn't really given it much more thought, but why would I need a
>>>> wrapper around the shellexecute? Does it turn out to be difficult
to
>>>> start that up with output redirected to a file?
>>> Capturing output is a weird business, having to do with all sorts of
>>> weird plumbing stuff in NT that I don't completely understand. I
>> don't
>>> think ShellExecute lets you specify STDIO handles - that's a
Microsoft
>>> decision. See
http://msdn2.microsoft.com/en-us/library/ms647732.aspx
>>> and http://msdn2.microsoft.com/en-us/library/ms682425.aspx and see
if
>>> you can find the equivalent of the STARTUPINFO structure (one of the
>>> options to CreateProcess) for ShellExecute - I don't see it. The
>>> STARTUPINFO structure includes hStdInput, hStdOutput, and hStdError,
>>> which is, I presume, how Perl goes about capturing output (by
creating
>> a
>>> handle and passing it in STARTUPINFO).
>>>
>>> Given all of that, I think you're going to have to use some program
to
>>> capture the output. Whether that program is $ENV{COMSPEC} using ">"
>> to
>>> redirect it to a file or whether it's a custom Perl program that
uses
>>> named pipes or something like that to communicate back to its
"host",
>> I
>>> think that's the route you're going to have to follow.
>>>
>>> --Toby Ovod-Everett
>>>
>>> -----Original Message-----
>>> From: Ed W [mailto:[EMAIL PROTECTED]
>>> Sent: Saturday, June 16, 2007 11:54 AM
>>> To: Ovod-Everett, Toby
>>> Cc: wxperl-users
>>> Subject: Re: [wxperl-users] grr, vista issues
>>>
>>> Hi
>>>
>>>> Does the "small C based installer app" use buffering on its pipes
or
>>>> not? If not, is there a way to write another small C (or
>>> PerlApp-based)
>>>> wrapper that is also marked as needing elevated permissions that
will
>>>> then start the installer app and redirect its output to a temp file
>>> that
>>>> can then be read by the Wx app?
>>>>
>>> No, I wrote the app, so I don't think it buffers its output (or if
it
>>> does then it can be changed)
>>>
>>> I had considered running the program via shellexecute, spooling the
>>> output to a file and reading in the file. Seemed quite ugly
though...
>>> I hadn't really given it much more thought, but why would I need a
>>> wrapper around the shellexecute? Does it turn out to be difficult
to
>>> start that up with output redirected to a file?
>>>
>>> Cheers
>>>
>>> Ed W
>>>
>>
>
>
