* preventing setup from forking
@ 2021-05-17 19:59 Jason Pyeron
2021-05-17 20:40 ` Jon Turney
0 siblings, 1 reply; 5+ messages in thread
From: Jason Pyeron @ 2021-05-17 19:59 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: preventing setup from forking
2021-05-17 19:59 preventing setup from forking Jason Pyeron
@ 2021-05-17 20:40 ` Jon Turney
2021-05-17 21:12 ` Jason Pyeron
0 siblings, 1 reply; 5+ messages in thread
From: Jon Turney @ 2021-05-17 20:40 UTC (permalink / raw)
To: Jason Pyeron, The Cygwin Mailing List
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: preventing setup from forking
2021-05-17 20:40 ` Jon Turney
@ 2021-05-17 21:12 ` Jason Pyeron
2021-05-18 9:13 ` Marco Atzeri
0 siblings, 1 reply; 5+ messages in thread
From: Jason Pyeron @ 2021-05-17 21:12 UTC (permalink / raw)
To: cygwin
> -----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!
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: preventing setup from forking
2021-05-17 21:12 ` Jason Pyeron
@ 2021-05-18 9:13 ` Marco Atzeri
2021-05-18 20:39 ` Adam Dinwoodie
0 siblings, 1 reply; 5+ messages in thread
From: Marco Atzeri @ 2021-05-18 9:13 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: preventing setup from forking
2021-05-18 9:13 ` Marco Atzeri
@ 2021-05-18 20:39 ` Adam Dinwoodie
0 siblings, 0 replies; 5+ messages in thread
From: Adam Dinwoodie @ 2021-05-18 20:39 UTC (permalink / raw)
To: Cygwin (cygwin@cygwin.com)
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-05-18 20:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-17 19:59 preventing setup from forking Jason Pyeron
2021-05-17 20:40 ` Jon Turney
2021-05-17 21:12 ` Jason Pyeron
2021-05-18 9:13 ` Marco Atzeri
2021-05-18 20:39 ` Adam Dinwoodie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).