On Sun, Jan 29, 2023 at 3:48 PM Brian Inglis <brian.ing...@shaw.ca> wrote: > > Best to hide that inside a script, rather than deal with mixing Windows and > shell quoting rules!
Tested and confirmed to be working with other scheduled tasks that exit. > Services drop privileges to $USER privileges unelevated. What I'm saying is that the requirement from my OP is that what is run has highest priveleges from *the windows side* regardless of what system/tool initially invokes it. > > Have you tested the first, most simple, test case from my OP? It's a > > very elemental test and reproduces the issue reliably for me so it > > would be interesting to hear what you (or anyone else) observes from > > that test case. > > It is unlikely it will be different: do they matter? >From my experience with software, troubleshooting and support, testing the simplest possible case is best practice to eliminate variables *and assumptions*. That's why my OP starts with such test cases. It's fine if you don't want to run that test otherwise be helpful, why don't we let others weigh in. Thanks anyways! > Most programs probably use regular startup code that opens the stdio handles, > whereas most shells support non-interactive operation that doesn't. I've also tested moving the commands being run into `*.cmd` and `*.ps1` scripts and running them that way, including various handling of stdio, all still reproduce the blocking window. > Doing anything with a console in Scheduled Tasks or any detached background > task > will pop up console windows, perhaps full screen and/or UAC modal if elevated > - > no surprise - don't do that if you don't want to see them! I don't understand how that's meant to be helpful. Did you read all the various cases I detailed? I cover cases that *do* open functional console windows and how that's not the issue I'm reporting. > Use run like XWin startxwin which does not display console windows: > > %CYGWIN_ROOT%\bin\run.exe --quote /usr/bin/bash -l -c "cd; exec > /usr/bin/startxwin" See the cases using `> run.exe` in my OP. Though I haven't tried adding `$ bash -c` as a layer. I'll try that out if I get more time to do more testing. Thanks for the specific helpful suggestion. > Services should be started by cygrunsrv elevated so they get the environment > they expect to run under. My OP covers why Windows services are not an option, again highest priveleges. > There are lots of unhelpful interactions between Cygwin and Windows > environments > and programs: you have to pick and choose one and do everything only with > those > programs in that environment. The twain can never (mostly) mix (without > effort). I concur, which is why I cover that running the commands that ultimately need to be need highest privileges from the Windows side and that Scheduled Tasks are the only way to do that. I wouldn't be messing with this if I could just do this all from inside Cygwin. > Your tests are play toys: what exactly are you actually trying to do? Not play toys, they are minimal test cases to reproduce an issue. In my experience in software, that's not only preferred but often surprisingly difficult to get from users reporting issues, so I guess we just don't see eye to eye. Thanks anyways! > and note that all stdio is redirected within the script > /var/log/...log > 2>&1, > < /dev/null if necessary, so that the Windows console is never involved. Thanks, that's a helpful specific suggestion I'll try when I next get time to do further testing. Thanks much for your help, lets let others weigh in and you can have your time back, Ross -- 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
