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_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 3a90ac20 for ; Wed, 31 Jul 2019 13:17:29 +0000 (UTC) Received: (qmail 1843 invoked by alias); 31 Jul 2019 13:17:21 -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: 44623 Received: (qmail 1576 invoked by uid 1010); 31 Jul 2019 13:17:21 -0000 X-Qmail-Scanner-Diagnostics: from mail2.primenet.com.au by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.2/25524. spamassassin: 3.4.2. Clear:RC:1(203.24.36.6):. Processed in 0.052056 secs); 31 Jul 2019 13:17:21 -0000 Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.217.45; helo=mail-vs1-f45.google.com; envelope-from=sgniazdowski@gmail.com; receiver= 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 :cc:content-transfer-encoding; bh=tlwv1YaiTAPjWZMqOFUr1jzAMyydmGbWJrOVnafieos=; b=NOeJLePMxkAHoE6kpuRVvx2jCXWWLRTrykepTa4QeLM464/IJK+k84YJxB5KzdwdLM G+uuGa+GU4xcn8Q8PEzT8nxEqHf6IBX0mXZRb6ds+hXvlYASBF7PYLdIvKPk03RXGNHV Bb3swxXvu1gHPCsAmlVHwHgoGhlszK3HHUUBlAUvGfkU4lI9toQHdmmo+75e9Pplo8Vp SDGbNv92kSOAnV5ui0ZWPQBxz17HWadl7TjgrPi2XbJBIaLlw33uTaAeD99xEFe1j8fj tu+FLSrZN12uyBmb5G6JFaRCxNh96ilJLSSdbvTK5QAV6tC348s6EKvIwxXDQMrOvMqE Y4+g== 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:cc:content-transfer-encoding; bh=tlwv1YaiTAPjWZMqOFUr1jzAMyydmGbWJrOVnafieos=; b=aHgKvK3EAUMlaG7svkd2I9fKn7q1/RnEBlB7OKlaOcbNv+dkLkj3jLTmsIlN0QHWQi 9MyxMrWHw7yM9ZQHv+6tsOC+DaaDWhLApRhmqI1vkaEbiMXHKz792v7U6p5/yF3fZW8J 1EUK+lA+0F5B+i9sS2uNOWKA+nA50jeukUyesayXRHCNcNNmu9kes5xKW7BdQsGqJg8q HxAWxi2v4HbDbGWGnQAbFaXsYOSdCL5vSlIfPQkmQUzNhWWPt+5Gkg/a3biF++M+2ats f9wHnLZ80XDMYK+yV0gOJy8jI5FBK3jcChFkRdq8QqZs79sSe2AbMFGdWJSAKX1ejHwz wSfw== X-Gm-Message-State: APjAAAXt+ft8b7m+5uZ75sw7p0l/TI7gKouPI9bpqq9gCivNCg+4myIF 6xTuFdjOZhZU5ClRGrO68hszj/9tRXSegXfnnFB3p4IGPrM= X-Google-Smtp-Source: APXvYqyyI2eqXFlqa9N3lWm8vM13/LAeXHhbKSxKqsVq+qrfnQiDQi9IoyqBMo0bng7VtFwZZkRaekeqQ2yVmeeVSdk= X-Received: by 2002:a67:ead3:: with SMTP id s19mr59373174vso.147.1564578651825; Wed, 31 Jul 2019 06:10:51 -0700 (PDT) MIME-Version: 1.0 References: <49013421-774e-4389-a25d-680f1d97a8ef@www.fastmail.com> In-Reply-To: From: Sebastian Gniazdowski Date: Wed, 31 Jul 2019 15:10:39 +0200 Message-ID: Subject: =?UTF-8?Q?Re=3A_A_serious_bug_in_execution_=E2=80=93_where_to_debug=3F?= To: Roman Perepelitsa Cc: Daniel Shahaf , Zsh hackers list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 31 Jul 2019 at 14:40, Roman Perepelitsa wrote: > ... > How is this possible? > > foo.zsh: alias grep=3D'grep --color=3Dauto' > bar.zsh: function bar() { grep hello << baz.zsh alias grep=3D'grep --color=3Dauto' Thanks for bringing this up into the light. It's a good example of the problems with unloading. It also hints an extension to zplugin =E2=80=93 to test whether the alias' value is the one expected to be and hold the unsetting/restoration of the alias if it isn't. So, if baz would set alias grep=3D'grep -B1 --color=3Dauto', then things would work as expected. And that's how it is with the unloading =E2=80=93 it *often* work= s, sometimes doesn't. But still, it's an useful tool that can be often used. > You can get the same problems when reverting changes to any resource > with a shared name: aliases, traps, options, widgets. All code that > ran after the plugin you are attempting could've been affected by the > value you are reverting. Ok, but the unloading can still be useful. For example, besides the MYPROMPT=3D1..8 use case, I'm also using it often when developing a plugin, instead of the shell restart. It allows for a quick unfunction/redeclaration of autoload functions, for example. > Removing widgets is very likely to break your prompt due to the way > widgets are commonly hooked. When a decent plugin wants to hook a zle > widget, it will copy the previous widget and install its own. > ... > if *this* widget gets wrapped too, and you remove it, the chain of > hooks is broken. This particular case will be solved if the plugin will use add-zle-hook-widget instead of wrapping (support for this isn't yet in zplugin, but it'll be there soon). > > I think that it's actually possible to predict to a large extent by > > looking at the list of unload-actions. > > You can predict which aliases will be unset and which widgets removed > but you cannot predict how it will affect shell. Things can break a > little or a lot. Things may look OK but do damage behind the scenes. To sum up, your opinion is a mathematical-like proof that: * You cannot implement an unloading that just works as expected. While my opinion is a practical-view -like point that: * You can often get good results with unloading, just try & test it first with the plugin that you need to unload. --=20 Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org