zsh-workers
 help / color / mirror / code / Atom feed
From: Roger Qiu <roger.qiu@matrix.ai>
To: Bart Schaefer <schaefer@brasslantern.com>, zsh-workers@zsh.org
Subject: Re: Possible ZSH bug with IO direction
Date: Mon, 25 Apr 2016 03:08:00 +1000	[thread overview]
Message-ID: <571CFD70.7090506@matrix.ai> (raw)
In-Reply-To: <160423151436.ZM6912@torch.brasslantern.com>

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 <doctor@fruitbat.org>
>   *
>   * 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


  parent reply	other threads:[~2016-04-24 17:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-23 18:30 Roger Qiu
2016-04-23 22:14 ` Bart Schaefer
2016-04-24 12:17   ` Peter Stephenson
2016-04-24 18:36     ` Bart Schaefer
2016-04-24 19:01       ` Peter Stephenson
2016-04-24 21:23         ` m0viefreak
2016-04-25  9:12           ` Peter Stephenson
2016-04-25 17:25           ` Peter A. Castro
2016-04-24 21:53         ` Bart Schaefer
2016-04-25  8:46           ` Peter Stephenson
2016-04-25 21:12           ` Mikael Magnusson
2016-04-25 17:16         ` Peter A. Castro
2016-04-24 17:08   ` Roger Qiu [this message]
2016-04-24 18:35     ` Bart Schaefer
2016-04-25 17:31       ` Peter A. Castro
2016-04-25 17:47         ` Bart Schaefer
2016-04-25 18:14           ` Peter A. Castro
2016-04-26  9:16             ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=571CFD70.7090506@matrix.ai \
    --to=roger.qiu@matrix.ai \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).