From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2954 invoked by alias); 24 Apr 2016 17:07:39 -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: 38326 Received: (qmail 27514 invoked from network); 24 Apr 2016 17:07:36 -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,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polycademy-com.20150623.gappssmtp.com; s=20150623; h=sender:reply-to:subject:references:to:from:organization:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=zlugh7E6U9mbqlYUbrXEtKOvjpXg83O2DJL1yinxByg=; b=jMtP0uqJHU/v/ZQhbs0sPTM4R67LA6UUtUOOvYlKYim3I3xTz/REr1crc5DdE+5b7l ZsNswN82ZyjYHnhgv1hji/RHj5WooArRiDsDpEdaDAWAMUUxuH+RnPJbsBcqauEHpnst NoH7indjyagry1ZlOFiK6GyngEUFGQMYpK9taouwK6QZNh0qyKE9BnXcTYmWt9qZMPo8 6KuNvNHijeOSufsN4uAU5vv9+E9EetOuhrlm9hXjhk6EYe8x8rwwNBuwfbwsdRnGf7OD Dw4cbVstQH8uyMlxmAkAjZXvCAK0gZiIJbO1/XhDb0TVunJcsw9YxwA7bkzJXlgJ6XtM jPNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:reply-to:subject:references:to:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=zlugh7E6U9mbqlYUbrXEtKOvjpXg83O2DJL1yinxByg=; b=VJX7MTMkctSpc4p5j1KkzKoPNy38IdQEiZMEoBmaxxwETOrfmKGlz/9LhyhdvT1pv8 TnKy2qC+EgLPHSXn2rQh8skDk9C3BLV9q2AoEE85YlMOvfXfC89PNjkqmz/92rgoQ4sa T91LHVxTKKN6nT7YERQ8HfiaECX88OTyZHoBPyTUPnL85IFn8KSX6suidEVSVjH4kXHn 4z8gQhQ4bdY7G8evBPWA+PDZJdYjwHllslw/SNqtarwNziLDKkVpFU2wV0bcLJONiMn1 on4nn+GQEVswL3QP0K9NrFWTGhhm3I+5WlZ6izHKZhR/lOLWXYij05IZGsVzq5NL5QnZ VNxg== X-Gm-Message-State: AOPr4FVTv4/yqCM+7aBGW8IM2dGDrJbx5WMtwSQfs0doYRAAfBZdlHn1wQh9OzVocmbUJw== X-Received: by 10.98.64.4 with SMTP id n4mr42693300pfa.58.1461517652501; Sun, 24 Apr 2016 10:07:32 -0700 (PDT) Sender: Roger Qiu Reply-To: roger.qiu@matrix.ai Subject: Re: Possible ZSH bug with IO direction References: <571BBF3C.50402@matrix.ai> <160423151436.ZM6912@torch.brasslantern.com> To: Bart Schaefer , zsh-workers@zsh.org From: Roger Qiu Organization: Matrix AI Message-ID: <571CFD70.7090506@matrix.ai> Date: Mon, 25 Apr 2016 03:08:00 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <160423151436.ZM6912@torch.brasslantern.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Thanks, the workaround did work. But I've never seen read & write redirection at the interactive prompt. Does that make the STDIN for the program I'm running readable and writable? How does that work? Can the program then rewind that descriptor, and write to `input.jpg`? Also since Bash doesn't suffer from this problem, will this be fixed eventually? On 24/04/2016 8:14 AM, Bart Schaefer wrote: > On Apr 24, 4:30am, Roger Qiu wrote: > } > } > gm convert -compress JPEG - - < input.jpg > output.jpg > } gm convert: Corrupt JPEG data: 873 extraneous bytes before marker 0xd9 > } (/tmp/gmo1fx92). > > I suspect you are encountering the issue that "gm" wants input.jpg in > binary mode, but zsh's input redirection operator has forced it to text > mode. A lengthy comment in Src/main.c (copypasted below) explains this. > > There's [intended to be] an easy workaround, which is to open the file > for both read and write even though you're only going to read it: > > gm convert -compress JPEG - - <> input.jpg > output.jpg > > However, it's been years since I had a Cygwin system or the time/patience > to care to set one up, so I haven't tested the workaround. > > Aside: The zsh/system module "sysopen" doesn't recognize O_BINARY or > O_TEXT modes; that should probably be corrected if someone can compile > on a system that has them, but of course the comment below indicates > that O_BINARY would be overridden anyway. > > > * Peter A. Castro > * > * Cygwin supports the notion of binary or text mode access to files > * based on the mount attributes of the filesystem. If a file is on > * a binary mounted filesystem, you get exactly what's in the file, CRLF's > * and all. If it's on a text mounted filesystem, Cygwin will strip out > * the CRs. This presents a problem because zsh code doesn't allow for > * CRLF's as line terminators. So, we must force all open files to be > * in text mode reguardless of the underlying filesystem attributes. > * However, we only want to do this for reading, not writing as we still > * want to write files in the mode of the filesystem. To do this, > * we have two options: augment all {f}open() calls to have O_TEXT added to > * the list of file mode options, or have the Cygwin runtime do it for us. > * I choose the latter. :) > * > * Cygwin's runtime provides pre-execution hooks which allow you to set > * various attributes for the process which effect how the process functions. > * One of these attributes controls how files are opened. I've set > * it up so that all files opened RDONLY will have the O_TEXT option set, > * thus forcing line termination manipulation. This seems to solve the > * problem (at least the Test suite runs clean :). > * > * Note: this may not work in later implementations. This will override > * all mode options passed into open(). Cygwin (really Windows) doesn't > * support all that much in options, so for now this is OK, but later on > * it may not, in which case O_TEXT will have to be added to all opens calls > * appropriately. > -- Founder of Matrix AI https://matrix.ai/ +61420925975