Re: BUG: Log on Scheduled Task invisible/empty window blocks input

[Ross Patterson <me@rpatterson.net>]

On Sun, Jan 29, 2023 at 3:48 PM Brian Inglis <Brian.Inglis@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