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

Brian Inglis Brian.Inglis@Shaw.ca
Sun Jan 29 23:48:44 GMT 2023


On 2023-01-29 15:55, Ross Patterson wrote:
>> dash (or bash if required) native path with WD /var/log/ native path e.g.
>> %CYGWIN_ROOT%\bin\dash /usr/local/bin/....sh WD %CYGWIN_ROOT%\var\log

> I'm not understanding the use of `WD` here, can you clarify/elaborate?

Working Directory entry

> At any rate, I forgot to mention that I also tried adding output
> redirection to the end of the action's ""Add arguments (optional)" and
> did so in various combination with the other variants described in my
> OP:
>      ... >> C:\...\log\....log 2>&1
> And I observed the same or similar mix of different blocking window types.

Best to hide that inside a script, rather than deal with mixing Windows and 
shell quoting rules!

>> For normal scripts and schedules, I use cron job commands or scripts which log
>> everything under /var/log/.
> 
> In that case, I'd still need `# crond` to run with highest privileges
> as those are the privileges I ultimately need what it would run to
> have.  But maybe I'll try that if I get time to do more testing.

Services drop privileges to $USER privileges unelevated.

> 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?

Most programs probably use regular startup code that opens the stdio handles, 
whereas most shells support non-interactive operation that doesn't.

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!

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"

Services should be started by cygrunsrv elevated so they get the environment 
they expect to run under.

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).

Your tests are play toys: what exactly are you actually trying to do?

How to successfully run Cygwin scheduled tasks without seeing windows:

>> I use scheduled tasks with actions running scripts from /usr/local/bin/ under
>> dash (or bash if required) native path with WD /var/log/ native path e.g.
>>
>> %CYGWIN_ROOT%\bin\dash /usr/local/bin/....sh WD %CYGWIN_ROOT%\var\log
>>
>> with various options (mainly user SYSTEM, logged in or not, highest privileges),
>> and triggers.
>>
>> I never see any windows appearing as the scripts log everything under /var/log/.
>>
>> The scripts run as tasks start and stop Cygwin services, init and run smart
>> reporting, clean up cron job remnants before smart reporting, terminate all
>> processes before running setup.

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.

Have you tried running a non-interactive script from a non-interactive shell as 
suggested?

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry


More information about the Cygwin mailing list