Re: Interrupting globs (Re: Something rotten in tar completion)

[Ray Andrews <rayandrews@eastlink.ca>]

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.