Re: [Monotone-devel] Question for Windows automate users

[Zbigniew Zagórski]

2009/2/22 Timothy Brownawell <address@hidden>:
> On Sun, 2009-02-15 at 10:27 -0800, Zack Weinberg wrote:
>> What's the intended effect of the make_io_binary() call in
>> automate::exec()?  It looks like we're setting stdin and stdout to
>> binary mode for any automate operation, but that doesn't seem right --
>> if you're just running one automate command inside a batch file or
>> something you'd want DOS line endings, wouldn't you?
>
> get_file / get_file_of and put_file need to be binary-safe, so they work
> with binary files. stdio needs to be binary-safe, so the byte counts
> don't get messed up.
>
> The others probably don't care, but making them not binary (1) would be
> inconsistent, and (2) would mean that they'd give slightly different
> output when run through stdio. Not sure how much these points actually
> matter, especially for the commands that generate lists (tags,
> ancestors, inventory) rather than dumping items (get_current_revision).

Agree in general. Summarizing:

1. Automate stdio must be always binary safe and consistent amongst platforms.

Imagine automate client working on windows reading from some ssh-ed
process on some unix (or vice versa). How one can know if that remote
one is unix/windows?

2. Standalone command execution:

For first-class data (revision text, cert value, file content, diff)
value it MUST be binary safe.

Invocation of:

   monotone au get_revision RID | sha1sum

must print RID regardless of platform and shell (that's also problem
with sha1sum tool which must read in binary mode but we have to make
monotone work as expected in this scenario).

Synthetic, query like data it can have native line-end so it can be
successfully parsed using platform shell utils (btw are there any
_other than unix-like_ shell text tools on any platform?). I think it
covers "any revision list", tags, keys, inventory, graph, options,
attibutes (really? **).

Packet IO is already line-ending agnostic and base64 meaning doesn't
change regardless of LE sequence. Native line-ending can be used.

> Perhaps default to binary for stdio and maybe get_file(_of)/put_file (or
> maybe not, since most files will probably be text files) and text for
> the others, with a --binary={yes|no} option to override this?

Not good idea IMHO. If there should be any option here it should be
monotone-wide and be something like --line-ending={native,CR,LF, CRLF}
(or unix,windows,mac). But that's pandora box we don't want open. It
was discussed several times without any reasonable result other than
it's a minefield.

**Hmmm.
Attribute value is part of revision text and i bet it can include
newline inside. So it's value should also be LE-consistent.

Regards,
ZZ