From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26072 invoked by alias); 6 Dec 2014 22:57:19 -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: 33893 Received: (qmail 2279 invoked from network); 6 Dec 2014 22:57:17 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Authority-Analysis: v=2.1 cv=AduIQRnG c=1 sm=1 tr=0 a=+SwvCgffRUjIJVDq/BIVHQ==:117 a=+SwvCgffRUjIJVDq/BIVHQ==:17 a=G8GL833Es-AA:10 a=N659UExz7-8A:10 a=UrzGkYy1A2i-Wr6lB8AA:9 a=pILNOxqGKmIA:10 Message-id: <548389C9.8030505@eastlink.ca> Date: Sat, 06 Dec 2014 14:57:13 -0800 From: Ray Andrews User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-version: 1.0 To: zsh-workers@zsh.org Subject: Re: Interrupting globs (Re: Something rotten in tar completion) References: <20141202155452.647182b4@pwslap01u.europe.root.pri> <141202084858.ZM31517@torch.brasslantern.com> <20141202172654.30e7d380@pwslap01u.europe.root.pri> <141204085606.ZM9146@torch.brasslantern.com> <20141204171226.301e9d2c@pwslap01u.europe.root.pri> <141205002023.ZM19736@torch.brasslantern.com> <20141205145054.655a2f70@pwslap01u.europe.root.pri> <141205100632.ZM508@torch.brasslantern.com> <20141205181330.2b458b46@pwslap01u.europe.root.pri> <20141205203417.2bc66b7b@pws-pc.ntlworld.com> <20141205220717.2f86bdd2@pws-pc.ntlworld.com> <54824EB5.3080001@eastlink.ca> <141206142744.ZM2362@torch.brasslantern.com> In-reply-to: <141206142744.ZM2362@torch.brasslantern.com> Content-type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: 7bit On 12/06/2014 02:27 PM, Bart Schaefer wrote: > On Dec 5, 4:32pm, Ray Andrews wrote: > } Subject: Re: Interrupting globs (Re: Something rotten in tar completion) > } > } On 12/05/2014 02:07 PM, Peter Stephenson wrote: > } > > } >> continue to do its job of acting as a sandbox but without screwing up > } > } What is a sandbox? > > A place where you can safely play without breaking anything important, > and where most of the mess is safely contained. > > In this context, that means a way to execute a command that may fail in > an unexpected or at least unpredictable way, without having that failure > change the rest of the shell state. An excellent metaphor then. Sounds like a very good thing to have. > > } So there was no distinction between an internal error and a user break? > } I thought the philosophy was to go overboard making very fine > } distinctions between various breaks, and that would seem to be > } the very first one to make. > > Problem here is that there really is no such thing as a "user break." > > There is the arrival of a signal from the operating system; some of the > time you can assume that certain signals must have been triggered by > something a user did, but the OS doesn't distinguish the source of the > signal, only the type of signal. The INTterrupt signal is *usually* > generated from the user's keyboard input, but doesn't have to be. > Sheesh. In DOS ^C is always a hardware interrupt, plain and simple. It's read at the BIOS level. So we can't/don't just check the kb buffer? It seems strange that the OS has no special flag for a keyboard generated interupt.