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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,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 f08520a4 for ; Mon, 18 Mar 2019 21:22:28 +0000 (UTC) Received: (qmail 27716 invoked by alias); 18 Mar 2019 21:22:11 -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: 44143 Received: (qmail 21449 invoked by uid 1010); 18 Mar 2019 21:22:11 -0000 X-Qmail-Scanner-Diagnostics: from mail-yw1-f54.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.100.2/25391. spamassassin: 3.4.2. Clear:RC:0(209.85.161.54):SA:0(-2.0/5.0):. Processed in 2.545908 secs); 18 Mar 2019 21:22:11 -0000 X-Envelope-From: charlechaud@gmail.com 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.54 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Q9vCABblp/rWzdneP0z+kEQF7azxut7GPiupYqMTTxg=; b=HBSsC5J5CYOu98m4DgycO181ogXW2jOke4c58P7OqNVqjpCkpfJKIQgsSiIhLizX9P JSCY6GAseBTFZR3ZD9PAXC0to9858Q+/nvL+bJ/hiBk4+2WH9TTV8COa+njxkFHct6Al KeRlP799h87cqDJKsr7C3NwsXNZgC8rlDKAV/35kIna9ecCrA1YGNAsNOuBHOa8hN48e 19MzHXP1lxRwckkBzV/PCMty64uLzGnt6u0YRSx+aJW+msCkOOXYfUN8aNYCn2ru0/uy 4ZEm/LRo8p6kYVVRJKNmRM6QAhc5mQRd79vYA32txptfl808njL1p453HgF4s6ZS+Fgn yo6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Q9vCABblp/rWzdneP0z+kEQF7azxut7GPiupYqMTTxg=; b=nC+oD8QqNJXJCUMcEWNLtCxO3OaYY+I7LMpwIrieq0h7L380RsqwYfnWFcmHurorZ6 D4pSiqzWhMl9NoewkaYFVQcCCuKGibrPCLlyTc1UZKQ9mTSEAvNMQ4IVinVLQUGM8CrJ CAead444Ezmhuo4qjJy4GWogL4Ox6XR39zq2+njrdAd1RtbiNXx/LCZxrgKLVmRwPGUh MkS1ANXHB+X7SAF8XiuB5jPibgizUSZVAOITRpjIuRNyEW3F78hAWqulXVeGpW+ZoVaa p6FeXDWNAc29mwCdlIW51W3hoSaC3bbxbeRANqH51kmu/SHs0BO7TIAbh3soLigK+/on IDOg== X-Gm-Message-State: APjAAAVIFPvwmbXpn3VVtXrYzZUU6tyehu9O5xpdyGXzriZ75qGdKxnk vf/jXPwGL4vquE9GNkRISAqWCXorO6L/LhwlRgprreHY X-Google-Smtp-Source: APXvYqwSdO6+UcUtVlSNuWGnpGH5QoBAJx5pnXyEB6qp65sXoN2nmmXD6DBxIn+WJFGclZABMSS+AUhb8ExHVP1YdJY= X-Received: by 2002:a81:ac08:: with SMTP id k8mr15389498ywh.329.1552944094174; Mon, 18 Mar 2019 14:21:34 -0700 (PDT) MIME-Version: 1.0 References: <1552903309.5658.4.camel@samsung.com> In-Reply-To: <1552903309.5658.4.camel@samsung.com> From: Charles Blake Date: Mon, 18 Mar 2019 17:20:58 -0400 Message-ID: Subject: Re: Command hashing/autocd bug & possible fixes To: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="00000000000016eb5c058464f992" --00000000000016eb5c058464f992 Content-Type: text/plain; charset="UTF-8" >This certainly looks plausible. I can't offhand think of a reason why a >hashed command would begin with a "/"; it's just asking for trouble. Cool. I think stricter/cleaner cmdnamtab is safer long-term. Not sure any users will complain about 'hash' built-in no longer saving absolute keys which is a consequence of your preferred resolution, but that's only likely to be short-term, if it exists at all. You likely want to document that in the man page or at least release notes so that any 'hash' users aren't mystified. Also, you may want to double check other possible ways cmdnamtab can be poisoned. greping for addnode.cmdname, I think the only other spot is Modules/parameter.c but parameter names cannot have dots and slashes anyway. I haven't analyzed it -- the code is so twisty and FS state dependence as well as all the setopt stuff is a lot of cases -- but it's at least conceivable that user-inserted *relative* paths in cmdnamtab can break something (maybe a feature other than AUTOCD or some future feature). There may be no good reason to have explicitly relative paths starting with "./" or "../" in there either. You may also want to expand your preferred solution to cover those. PATH-relative entries can make sense. Eg., mh/inc for those old school enough to recall /usr/bin/mh installations. So, I'd stop short of a "block *any* '/' in cmdnamtab keys" rule. Testing just the start of the string is faster anyway. Presently, neither the explicitly relative (which don't make sense to cache) nor PATH-relative entries (which do make sense to cache) get in cmdnamtab automatically unless I'm missing something. They can be put manually via 'hash', though, and PATH-relative profitably so (a dubiously small profit, but still). If they do cause trouble it's "likely" users know they did it by hacking search with 'hash'..Probably very rare if it's even a problem at all. All famous last words, though. Some under- the-covers package might do it for them. Indeed, running whence on absolute paths has to be rare, too. I only noticed it recently using zsh-syntax-highlighting which broke AUTOCD on just a couple root dirents..mysteriously at first. I didn't realize it was z-sy-h for a while. Then it took a short while to isolate it to just entries in my $PATH. Then I just disabled z-sy-h for *just* long enough to forget why I disabled it. Re-trying z-sy-h a few days ago reminded me. I figured I should report this time since last time I forgot. Matthew Martin quickly reduced the misbehavior to whence with Daniel doing an easy subshell fix to avoid poisoning longer-term state. Curious just how long this bug lurked, I tested old versions of Zsh. I had to go all the way back to zsh2.1 from circa 1993 to find a version *without* this bug. zsh2.0 also worked. I think 2.0 may have been the first release with AUTOCD. At least zsh-1.0 didn't have it. So, well, it worked for a little while, anyway. ;-) --00000000000016eb5c058464f992--