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
next prev parent 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).