On Thu, Aug 27, 2020 at 11:44 AM Michael Wild wrote: > > On Thu, Aug 27, 2020 at 11:02 AM Corinna Vinschen wrote: > >> On Aug 27 07:48, Michael Wild via Cygwin wrote: >> > On Wed, Aug 26, 2020 at 10:57 PM Jon Turney wrote: >> > >> > > >> > > It turns out to be the case that setup doesn't propagate the CYGWIN >> > > environment variable into the environment for scripts it runs, so >> > > setting that isn't going to make any difference. That should probably >> > > be considered a bug. >> > > >> > > However, even if that's fixed, there's no value for winsymlinks in >> > > CYGWIN env var to specify the behaviour of Cygwin 3.1.4 and previous >> > > (i.e. always create traditional symlinks, don't use WSL symlink >> reparse >> > > points) >> > > >> > >> > Thanks Jon for the elaboration. Isn't winsymlinks=lnk supposed to do >> this >> > per the documentation? Could Corinna be convinced to include an option >> > where this can be done? To be honest, my hopes are greater to get this >> > worked-around in a useful timeframe from the Cygwin side than getting >> the >> > proper fix into Docker. >> >> Isn't it sufficient to fix setup so you can create lnk-style symlinks in >> your scenario? The CYGWIN env variable and the number of options is >> such a mess. >> >> >> Corinna >> > > I am right now modifying setup to not sanitize CYGWIN away when invoking > the post-install scripts and then will report back. > > Michael >
Hmm, OK, changing script.cc to not strip out CYGWIN is trivial. But the harder part is that main.cc uses ShellExecuteEx() with SHELLEXECUTEINFO.verb set to "runas" in order to re-run setup elevated. This resets all environment variables back to default. In my instance I can circumvent this by passing --no-admin and running from an elevated shell where CYGWIN is set already. And indeed, this works and resolves my Docker problem. I attached this fix as a patch. But on the other hand, I find this behavior to be a bit confusing. However, I don't see an easy way of resolving the "runas" issue, because it is by design. An option would be that the calling process passes the CYGWIN variable as a command line argument to the elevated process. But that is also ugly. What do you guys think? Michael -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
