From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) by sourceware.org (Postfix) with ESMTPS id 59D483858D32 for ; Sun, 29 Jan 2023 23:48:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 59D483858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=Shaw.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=shaw.ca Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTP id M82qpfRYEl2xSMHPhp3zo0; Sun, 29 Jan 2023 23:48:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shaw.ca; s=s20180605; t=1675036125; bh=b5rMp5j4DGC8et8hOHhSaBovWZOJzd5wR4f64remblY=; h=Date:Reply-To:Subject:To:References:Cc:From:In-Reply-To; b=ppgT2cK8QzQGnZPhLFIYUjLSjGJhF7m+2XGBp2LhWo/vimN6pwl/q+tNkOgdc1bT6 t0AfMj+Lec+CTeHDKS+lg65G1BzqxRloGQtrWSC8LVDUD11wbzlhERoyxgf5s6cqtK SERc6rUzXo8mW/xCt0DUV5Ic7SWWUHOY7Cz1UNIt31b5ADj9QYfciAXwRA5CWgluMc 9jy3l9SOq477snFW2OvwjieAGXwZDkIeeqjQSwMB06lN7xVGuQlksYT8OaPOVpf0CS uB9pMTE2QM/QKZ2rtBOD8s5RPrKiV4yCG8k9m5b/e/r+GiAuIREbnDHNi5kLynOoky mPwFENL5bIJaw== Received: from [10.0.0.5] ([184.64.124.72]) by cmsmtp with ESMTP id MHPhpIqiacyvuMHPhpOrda; Sun, 29 Jan 2023 23:48:45 +0000 X-Authority-Analysis: v=2.4 cv=VbHkgXl9 c=1 sm=1 tr=0 ts=63d705dd a=oHm12aVswOWz6TMtn9zYKg==:117 a=oHm12aVswOWz6TMtn9zYKg==:17 a=IkcTkHD0fZMA:10 a=xEtqiN7rneSloUyuQzcA:9 a=QEXdDO2ut3YA:10 Message-ID: Date: Sun, 29 Jan 2023 16:48:44 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Reply-To: cygwin@cygwin.com Subject: Re: BUG: Log on Scheduled Task invisible/empty window blocks input Content-Language: en-CA To: cygwin@cygwin.com References: <3bafc985-e382-5b31-bca5-3556ca6e4e40@Shaw.ca> Cc: Ross Patterson From: Brian Inglis Organization: Inglis In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfHNWeAr15+q7VeFBv2aGe9NVcNqpkCaiDLEKnoBDzxeLvPBMp+pwNWqIVmxvNLb4Wy++CQaKrTYGIa0BSg6CKSviCKi2kyrlL4r3+HvBzo4WXHbujc9X f26GIDwG2ykbN9zujE5jKdOvRrYyzwee+BiLSeCL4OqglMCErKM2deZJPzSRmCK7wBxI+cFABZh26v7HCsFzigZnYsldJBwJsog= X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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