From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24006 invoked by alias); 15 Sep 2016 11:17:40 -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: X-Seq: 39344 Received: (qmail 14666 invoked from network); 15 Sep 2016 11:17:39 -0000 X-Qmail-Scanner-Diagnostics: from mail-qt0-f180.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.216.180):SA:0(0.0/5.0):. Processed in 1.383749 secs); 15 Sep 2016 11:17:39 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,SPF_PASS, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: sgniazdowski@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.216.180 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ojhPjJR+ECsvEiB7lMqnnshl4vBcRKrEw059bvhPz5o=; b=TrzYgZOcPLDz3QuIVmYGAWedRDf2l8bplM7oZsiDy4xaUVX3yQPRqKB2OcWYjpv40w yPLfSMZ80SvLD2202b4ylpEjEwy4jvskjZ05UeWqryaz03ytKwnbrqXBJMacNYl7ZMwa oPaljQd3TDjvN6DfnM0bi3Dp0W4afGJGo7MEgxkQ1IC4cvKY1IwfV5gI+vDrcC/mhpET rXe+JWTWRG+0vcfT17CanaAbOXnmW9CaP1LRwrpFzDQ351n560xg+cN6C1h8IPnswYdS eX9KhZ1fxgV6yWyFvZDPVJdWpuT5rdRvCwhUan/AssN/FiAAQJgDtjMvv8sgG7Dweew5 1Axw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ojhPjJR+ECsvEiB7lMqnnshl4vBcRKrEw059bvhPz5o=; b=egVSqU++WPxtsr6OBZl/egtCLRU1UHDdtGwkhItgzvnuN+/QUSH3m35REiijyC9aQw 4P+9MlPqx/RTSqzguFJ6HhWOXQ8odrhNrqdEN9ks1QZw4NIsH6SykJotiklkozvjR/qA IV2d+edPv7i4S9RkNf9w6qYhYRdwb3U+XsJY5gCq3xsXb2C/HX84ez1M1LvMs74ueZX0 MM+f7PKUmtJtXMo9ny3GfR6N6Xr3Qxr/WeB7LYTA/4wT9UG2PfxJVywGEBSEaYoGqINo NNhidEqYSs3uBaHKxfafxIOEoYl4Y9oOFJURsh887xvv3kn/S+ekN56kVeMvo4nAqKg/ rO1w== X-Gm-Message-State: AE9vXwPGawTDCQRcHQN10GvveJATbylHpPvCKGfBtVgfYtnC0LL8Hlx8+yIFmAxFQwSTQGoKhTTA6dKtQ1ceOg== X-Received: by 10.200.40.36 with SMTP id 33mr8419089qtq.53.1473934722701; Thu, 15 Sep 2016 03:18:42 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <160914215152.ZM519@torch.brasslantern.com> References: <20160913142003.480cfd9c@pwslap01u.europe.root.pri> <160913091822.ZM29020@torch.brasslantern.com> <20160914200421.021c559e@ntlworld.com> <160914215152.ZM519@torch.brasslantern.com> From: Sebastian Gniazdowski Date: Thu, 15 Sep 2016 12:18:22 +0200 Message-ID: Subject: Re: Can periodic hook stop rescheduling? To: Bart Schaefer Cc: Zsh hackers list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 September 2016 at 06:51, Bart Schaefer wr= ote: > On Sep 14, 8:04pm, Peter Stephenson wrote: > } Subject: Re: Can periodic hook stop rescheduling? > } > } On Tue, 13 Sep 2016 09:18:22 -0700 > } Bart Schaefer wrote: > } > The other (not mutually exclusive) option would be to make recurring > } > schedules part of the "sched" builtin itself > } > } I was thinking of that and sounds like a useful feature anyway. > > Yes, the danger is in scheduling something harmful and for a short > interval and then not being able to turn it off. This might be a general topic of descheduling, its not-full convenience. It is done via: sched -item (number of item on sched's list as man page says). Apparently one has to fork, parse `sched` output, establish item nr and invoke sched -item. Race condition isn't possible because when being in function, then not being at idle prompt, so sched won't be invoked and no deschedule will occur. However these steps are not very convenient. Forgetting for a moment about implementation effort, what would be the best is IMO a builtin schedid that would put an ID (new kind, not the "item") of last scheduled item into REPLY. No fork, no moving parts (i.e. no change of entries' positions in the time ordered schedule list), a hash-table-key-like ID, that a bigger script would be able to save for use after say 2 hours when user would e.g. "unload plugin" (whatever this means currently). As for the mistake schedule with short interval, then maybe =E2=80=93 that's not that best for me as schedid =E2= =80=93 new builtin ksched, i.e. kill-sched, to deschedule all entries. I've seen sched's code and it's really basic what's really cool, except maybe for the around-precmd code when it get's run, I didn't see that. But a new builtin is rather a unpleasant thing, one has to fill some registration tables probably? What are chances for schedid, ksched, automatic rescheduling? Maybe I could implement them when given green light, however I first need to finish one plugin. PS. Maybe instead of ksched =E2=80=93 schedpop. Removes top entry from the list. In case of problems with short interval and problematic scheduled code, one would have to manage to enter schedpop few times, in many cases single time. PS2. About my question on periodic hook, is it immune to Ctrl-C? Best regards, Sebastian Gniazdowski