public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@Shaw.ca>
To: cygwin@cygwin.com
Cc: Ross Patterson <me@rpatterson.net>
Subject: Re: BUG: Log on Scheduled Task invisible/empty window blocks input
Date: Sun, 29 Jan 2023 16:48:44 -0700	[thread overview]
Message-ID: <ad5f00c1-2924-b4dd-4f6d-259f40c911e9@Shaw.ca> (raw)
In-Reply-To: <CAGJ7yHDge+-xe-zTjcCXmRNus8qFOo6m0smbHs8Z=ZHPwcdwEg@mail.gmail.com>

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

  reply	other threads:[~2023-01-29 23:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-27  2:43 Ross Patterson
2023-01-27 19:39 ` Brian Inglis
2023-01-29 22:55   ` Ross Patterson
2023-01-29 23:48     ` Brian Inglis [this message]
2023-01-30 11:02       ` Ross Patterson
2023-11-25 15:16 Jason Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ad5f00c1-2924-b4dd-4f6d-259f40c911e9@Shaw.ca \
    --to=brian.inglis@shaw.ca \
    --cc=cygwin@cygwin.com \
    --cc=me@rpatterson.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).