preventing setup from forking

preventing setup from forking

[Jason Pyeron]

When I run

 

c:\inst\setup-x86_64.exe -q -f -R c:\cygwin64 -l c:\inst -P libgcrypt-devel,asciidoc,cygport,gcc-g++,libpoppler-cpp-devel,libpcre-devel,dejagnu,texlive-collection-latex

 

or

 

c:\inst\setup-x86_64.exe -qvW -f -R c:\cygwin64 -l c:\inst -P libgcrypt-devel,asciidoc,cygport,gcc-g++,libpoppler-cpp-devel,libpcre-devel,dejagnu,texlive-collection-latex

 

the prompt returns immediately. This is causing problems when it is run from a (windows) ssh session.

 

e.g. ssh oss-cygwin-server-2019-node -l 'jenkins$' -t 'c:\inst\setup-x86_64.exe -q -f -R c:\cygwin64 -l c:\inst -P libgcrypt-devel,asciidoc,cygport,gcc-g++,libpoppler-cpp-devel,libpcre-devel,dejagnu,texlive-collection-latex'

 

Any thoughts? 

 

This is forcing me to run it interactively, as there is something that is causing it to hang, with no output.

 

-Jason

Re: preventing setup from forking

[Jon Turney]

On 17/05/2021 20:59, Jason Pyeron wrote:
> When I run
> 
> c:\inst\setup-x86_64.exe -q -f -R c:\cygwin64 -l c:\inst -P libgcrypt-devel,asciidoc,cygport,gcc-g++,libpoppler-cpp-devel,libpcre-devel,dejagnu,texlive-collection-latex
> 
> or
> 
> c:\inst\setup-x86_64.exe -qvW -f -R c:\cygwin64 -l c:\inst -P libgcrypt-devel,asciidoc,cygport,gcc-g++,libpoppler-cpp-devel,libpcre-devel,dejagnu,texlive-collection-latex
> 
> the prompt returns immediately. This is causing problems when it is run from a (windows) ssh session.

--wait should be doing what you want.

I recently discovered that if the invoking shell is PowerShell, then 
because setup is a GUI application, PowerShell doesn't wait, so maybe 
that's what's happening here...

> Any thoughts?

RE: preventing setup from forking

[Jason Pyeron]

> -----Original Message-----
> From: Jon Turney 
> Sent: Monday, May 17, 2021 4:41 PM
> 
> On 17/05/2021 20:59, Jason Pyeron wrote:
> > When I run
> >
> > c:\inst\setup-x86_64.exe -q -f -R c:\cygwin64 -l c:\inst -P libgcrypt-
> devel,asciidoc,cygport,gcc-g++,libpoppler-cpp-devel,libpcre-devel,dejagnu,texlive-
> collection-latex
> >
> > or
> >
> > c:\inst\setup-x86_64.exe -qvW -f -R c:\cygwin64 -l c:\inst -P libgcrypt-
> devel,asciidoc,cygport,gcc-g++,libpoppler-cpp-devel,libpcre-devel,dejagnu,texlive-
> collection-latex
> >
> > the prompt returns immediately. This is causing problems when it is run from a (windows)
> ssh session.
> 
> --wait should be doing what you want.

-W is the same, no impact.

> 
> I recently discovered that if the invoking shell is PowerShell, then
> because setup is a GUI application, PowerShell doesn't wait, so maybe
> that's what's happening here...
> 

Fits my observations. https://superuser.com/questions/908664/have-the-command-prompt-launch-an-application-like-notepad-and-block-until-it-is helps.

start /b /wait c:\inst\setup-x86_64.exe -q -f -R c:\cygwin64 -l c:\inst -P libgcrypt-devel,asciidoc,cygport,gcc-g++,libpoppler-cpp-devel,libpcre-devel,dejagnu,texlive-collection-latex

from cmd.exe use start /b /wait

/B Start application without creating a new window. The application has ^C handling ignored. Unless the application enables ^C processing, ^Break is the only way to interrupt the application.

/WAIT Start application and wait for it to terminate.

My real issue was the user was not an admin - doh!

Re: preventing setup from forking

[Marco Atzeri]

On 17.05.2021 23:12, Jason Pyeron wrote:
>> -----Original Message-----
>> From: Jon Turney
>> Sent: Monday, May 17, 2021 4:41 PM
>>

> 
> My real issue was the user was not an admin - doh!

that could be due to "setup" in the program name.

It is one of the "security" ideas of MS

Regards
Marco

Re: preventing setup from forking

[Adam Dinwoodie]

On Tue, 18 May 2021 at 10:13, Marco Atzeri via Cygwin wrote:
>
> On 17.05.2021 23:12, Jason Pyeron wrote:
> >> -----Original Message-----
> >> From: Jon Turney
> >> Sent: Monday, May 17, 2021 4:41 PM
> >>
>
> >
> > My real issue was the user was not an admin - doh!
>
> that could be due to "setup" in the program name.
>
> It is one of the "security" ideas of MS

I believe it's nothing to do with the program name, and everything to
do with how the UAC permissions work: if you run the setup program
with the -B argument so it won't check it's running with Administrator
permissions, or run it from a parent process that already has
Administrator permissions, you'll get the behaviour you might expect.
If you run it without -B and from an unelevated context, then the
installer will elevate to Administrator before it does anything else,
and that means the calling context -- cmd or anything else -- won't
get any feedback from the installer, so it returns straight away.