From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) by sourceware.org (Postfix) with ESMTPS id 442F43858D1E for ; Mon, 30 Jan 2023 11:02:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 442F43858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rpatterson.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rpatterson.net Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-163ba2b7c38so2643002fac.4 for ; Mon, 30 Jan 2023 03:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rpatterson-net.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=bwuMmWcxyE7zU3lXl9tktuwa6Fw02ncWgyktgyi2xtk=; b=SLDm9/fhFdRfTXRTPUgjgw4jK/Y4No+Ppc74qL+y1EIlDq/diTZBS733Bf4u5VaFDj UfxO7MVrZyUAk20YGeJnDA2deihtRnJP1XswMV2StaKW2JPie/j0qnZJHt+n1S017UCp VcsUwlRcHZMOI6EawDfkRaphMrnuj0BxaxakhqApsK6fiRWalNgLYUlGXk451Qycf0fN XsYgapgtWv/wu4vEA/I4JDcO+7oC7yF3MEWE1EiOdTAe9rxe7kFguhrARJtSXupQoyAP 5vPu0hrkbZJYtnDpaafVec5mSkse8MWPBJ2kBVPWYtRQ50T7uv53Keocwg4vLYiVn+O3 XNmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bwuMmWcxyE7zU3lXl9tktuwa6Fw02ncWgyktgyi2xtk=; b=3poCGfhydP76Tjrhv97ZNZSWaSmE2PbxGDPjdZ6ODNr0Mw/gqtyOR7waJ9nVMZCOFX ywxOpgftNMPaH+JHIt9gu/TBiCvdxnvO6SsYSDf8RsiEeMFqk54e0jXfm9IH7KEvEE9e VDz5pXns7FuayuhibVVLQrtZ1i70z6YGk1xQzQRflmh4Jz0+I+ETdZuuZx2zgX3WDnXe SvzHKVjHt4LEK50dY58i2juxZt7/agfe7Rn3Lo8mkHmz+nYVIUtdeZgeEETsowHK5hAJ fkIzNEzDKUAqEz4t5Z2nUfZOMFzT7zJD9fuE7gpNKYxcJKas5zl5uxMETRCum3L9LqDA SlJg== X-Gm-Message-State: AO0yUKWbF7ONnS63h6G2auct1Wjo3spMzs8m/eiWdAezquXN98TpT1GV O+dpjIDpa4DrMZ0fMkjRwM0b6GUy8xMq8meVqapQgZTrPdoP5Civ X-Google-Smtp-Source: AK7set/CARs911ay5+WBdh7kiDDC9Q9s3pai46YO1nYzQfs/DOp456qATI1IAQWp511s7eZ5L95KDzmG0qyaqH8fTrU= X-Received: by 2002:a05:6871:b0d:b0:163:28ab:c4ca with SMTP id fq13-20020a0568710b0d00b0016328abc4camr1382706oab.195.1675076565175; Mon, 30 Jan 2023 03:02:45 -0800 (PST) MIME-Version: 1.0 References: <3bafc985-e382-5b31-bca5-3556ca6e4e40@Shaw.ca> In-Reply-To: From: Ross Patterson Date: Mon, 30 Jan 2023 03:02:34 -0800 Message-ID: Subject: Re: BUG: Log on Scheduled Task invisible/empty window blocks input To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,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 Sun, Jan 29, 2023 at 3:48 PM Brian Inglis 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