From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 1b706116 for ; Mon, 10 Feb 2020 23:03:02 +0000 (UTC) Received: (qmail 15991 invoked by alias); 10 Feb 2020 23:02:56 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45415 Received: (qmail 26354 invoked by uid 1010); 10 Feb 2020 23:02:56 -0000 X-Qmail-Scanner-Diagnostics: from mail-yw1-f47.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25718. spamassassin: 3.4.2. Clear:RC:0(209.85.161.47):SA:0(-1.9/5.0):. Processed in 2.813271 secs); 10 Feb 2020 23:02:56 -0000 X-Envelope-From: dana@dana.is X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.161.47 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L0/A3NmGATgfKTgr5o1bpo/Wn5uH3faiYl7gNUlDSzk=; b=awISspMcOhQh0NTa/0sOyYfFiVmYXrrvDStkOnkJ6vO/8eumJGVm1TkLieny4CIog1 ROxVzNclf8R5zif6MrsQ75+P//yWqEIZNT8XTQ9k/6320Zk5FQ1BkKzPQ+51DVQnkpp8 1wDZSmxUrF6J3Xb4mRJ6MAsWludTQMuKskWCAKWGVvGNygK2f6CSYkWLZwObXKJE7KJT iQmUEU758rWur11ebKqIPiQVBxF3vHSPGiecUsDiTOr7SRA2/OqBjtbH21gPaGw3UFdi N9P0ZGFNXmtKTG86T3kM46Thy3+FRlYjsXCI+Q3qN6K5sO9izDIQRYg1H4qUk4xFib50 XC4g== X-Gm-Message-State: APjAAAWhy9GCbH2pMkbQoE2P42H1mSUKqiEYDsY/xUvzx22/CrOZv3+w F6sIKvpLMQmIcA74gt1qexJ+5w== X-Google-Smtp-Source: APXvYqyTCSAcNtN7XmhixwIHECatHJSpSFVhRM1NLQxLeOO1WONclS2rsx6WGtYwKdOfJqYFRoQYFQ== X-Received: by 2002:a81:7c06:: with SMTP id x6mr3074801ywc.500.1581375739732; Mon, 10 Feb 2020 15:02:19 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: sudo autocompletion From: dana In-Reply-To: <327afa53-4d22-7cea-9f4f-3bf9bcf82607@gmail.com> Date: Mon, 10 Feb 2020 17:02:17 -0600 Cc: Daniel Shahaf , Zsh hackers list Content-Transfer-Encoding: quoted-printable Message-Id: References: <912d22db-8a8f-90f2-6738-f9f395994dcb@gmail.com> <1770be62-54d8-70a6-8b05-cfc98faa9b9f@gmail.com> <20200210030219.527a3ccf@tarpaulin.shahaf.local2> <327afa53-4d22-7cea-9f4f-3bf9bcf82607@gmail.com> To: Andrey Butirsky X-Mailer: Apple Mail (2.3445.104.11) On 10 Feb 2020, at 16:05, Andrey Butirsky wrote: > Didn't see all the file, but probably 'su' and variants need something = similar also? > One of the "solutions"...: > zstyle ":completion:*:$i:*" environ PATH=3D"$SUDO_PATH" FYI, _su doesn't currently support the environ style, so that isn't = actually doing anything for it. I don't think using environ is a good idea for us. It'd update PATH just = like command-path ultimately does, but it happens sooner, it exports the = change, and because it supports multiple var=3Dvalue pairs we'd have to do some = weird accounting to provide a default without ruining completion if someone = uses it to set HOME or whatever. I think you're right that we probably need to do something for su and = doas too, though. I very rarely use them so i'd have to double-check how they actually handle PATH On 10 Feb 2020, at 13:20, Daniel Shahaf wrote: > Might the user have set the command-path style in this context to > an empty value (zero strings, which would count as false)? ... > Could this style setting shadow a style the user had set explicitly? Yes and yes. The first is easily fixed, but the second is weird due to = how zstyle weights patterns. That's an issue with cache-policy as well On 10 Feb 2020, at 13:20, Daniel Shahaf wrote: > As an alternative, _sudo could set _comp_command_path=3D( $path > $path/%\/bin//sbin ) and then _command_names could use that value if > the style isn't set then. The parameter would be made local by > _main_complete. This is similar to how, say, $precommands is handled. That seems like it'd work. We could also give _command_names an option = to do it for us, similar to what we did recently with _normal. Both are API = changes, though, so we'd be stuck with it. Have to think about it dana