From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 132 invoked by alias); 25 Apr 2016 18:15:35 -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: 38341 Received: (qmail 18810 invoked from network); 25 Apr 2016 18:15:34 -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=-1.9 required=5.0 tests=BAYES_00,TVD_RCVD_IP autolearn=ham autolearn_force=no version=3.4.1 Date: Mon, 25 Apr 2016 11:14:06 -0700 (PDT) From: "Peter A. Castro" To: Bart Schaefer cc: Zsh hackers list Subject: Re: Possible ZSH bug with IO direction In-Reply-To: Message-ID: References: <571BBF3C.50402@matrix.ai> <160423151436.ZM6912@torch.brasslantern.com> <571CFD70.7090506@matrix.ai> <160424113558.ZM3564@torch.brasslantern.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Mon, 25 Apr 2016, Bart Schaefer wrote: > Date: Mon, 25 Apr 2016 10:47:49 -0700 > From: Bart Schaefer > To: Peter A. Castro > Cc: Zsh hackers list > Subject: Re: Possible ZSH bug with IO direction > > On Mon, Apr 25, 2016 at 10:31 AM, Peter A. Castro wrote: >> >> I believe the best solution is to teach Zsh code to handle CR+LF properly, > > Which means we're back to the "dozens of source modules" you mentioned. > There's no central place for this; because of vagaries of other I/O systems > (e.g. STREAMS modules), there's not even a consistent use of stdio vs. > low-level read/write (though at least they're usually not mixed on the same > descriptors). Yes...I had noticed that in my first few attempts at "fixing" the code. I quickly became overwhelmed at the scope of things. > I haven't looked closely at this (and have no idea whether it's possible with > the pre-main hook in place) but perhaps put the descriptors back into > binary mode somewhere in exec.c between whatever passes for zfork() > on cygwin and the actual execve() of any external process? We mostly > know when a zsh builtin vs. an external command is being run. I did consider this, but there's something about using the pre-main hooks that prevents resetting the attributes. I'll ask Corinna about it, but I suspect there isn't a way of doing it once the pre-main has been invoked. In anycase, this also leads to your next comment: > Either way the external commands are on their own -- the question is > whether they're better off getting binary when they expect text or the > other way around (as currently). That is its own can of worms. The later is what mostly-works for 95% of the use-cases. There is no good solution here, I'm afraid. So, to sum things up: pre-main hook is bad. CR+LF is evil. Teaching the code to grok CR+LF is hard. Users don't like change and expect things to "just work". Am I missing anything? :-/ -- --=> Peter A. Castro Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com "Cats are just autistic Dogs" -- Dr. Tony Attwood