From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3492 invoked by alias); 24 Dec 2015 00:47:45 -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: 37429 Received: (qmail 18851 invoked from network); 24 Dec 2015 00:47:43 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Date: Wed, 23 Dec 2015 16:47:39 -0800 From: frederik@ofb.net To: Bart Schaefer Cc: zsh-workers@zsh.org Subject: Re: question about saving history and error reporting Message-ID: <20151224004739.GA21636@ofb.net> Reply-To: frederik@ofb.net References: <1450718785.14170.ezmlm@zsh.org> <20151221203800.GB23389@ofb.net> <151221125450.ZM21081@torch.brasslantern.com> <20151222181420.GA21368@ofb.net> <151222165433.ZM28846@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <151222165433.ZM28846@torch.brasslantern.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: Thanks for the perspective. On Tue, Dec 22, 2015 at 04:54:33PM -0800, Bart Schaefer wrote: > On Dec 22, 10:14am, frederik@ofb.net wrote: > } > } For me, if the history can't be written, it would be convenient to > } know about the errors that are being generated immediately, so that I > } can fix the problem. Are there many situations where the history can't > } be written due to a problem which is transient? > > The most common reason in the case of inc_append_history could be that > multiple shells are updating the file at the same time. There are also > things like home directories on remote filesystems that are temporarily > unreachable. > > Really it's not the responsibility of the shell history mechanism to > alert you about system-wide failure conditions like a full disk, and > I wouldn't want to encourage anyone to rely on it for that. > > } Are there other cases where Zsh hides errors that occur during its > } operation? > > That's a rather wide-open question. The (programmed in shell code) > completion system deliberately suppresses all sorts of errors that > might occur during generating the possible matching words, because > they're irrelevant to updating the command line and displaying them > would mess up screen for ZLE. Within the C code, I would not be > surprised if there are other implicit actions for which displaying > an error state is considered unnecessarily verbose, but I can't tell > you of any offhand. >