Re: convert-ly from the commandline under windows corrupted?

[David Kastrup]

Eluze <address@hidden> writes:

> Phil Holmes-2 wrote
>> That's quite weird, since the > is a DOS redirection, so shouldn't affect 
>> the output of convert-ly.  What about trying python convert-ly.py instead?
>
> all the same
>
>
> dak wrote
>>> yes, with the option -e, and also dir > dir.txt
>> 
>> And without option -e (the output should then just be on-screen)?
>
> indeed, it is!

The > redirection is set up by the shell (or its Windows equivalent).
If convert-ly xxx.ly works fine with output to the screen, while
convert-ly xxx.ly > yyy.ly (where yyy.ly does not exist previously)
causes error messages from convert-ly, then the shell will leave the
file in a state where write calls from python don't succeed.

The corresponding passage in scripts/convert-ly.py reads

    if global_options.edit:
        try:
            os.remove (infile_name + '~')
        except:
            pass
        os.rename (infile_name, infile_name + '~')
        outfile = open (infile_name, 'w')
    else:
        outfile = sys.stdout

    outfile.write (result)
    
    sys.stderr.flush ()

    return errors

which is quite unspectacular.  So either there is still a permission
problem, or your version of Python and Windows just don't cooperate
sensibly on sys.stdout.

In the Python documentation, I read

    The standard streams are in text mode by default. To write or read
    binary data to these, use the underlying binary buffer. For example,
    to write bytes to stdout, use sys.stdout.buffer.write(b'abc'). Using
    io.TextIOBase.detach() streams can be made binary by default. This
    function sets stdin and stdout to binary:

    def make_streams_binary():
        sys.stdin = sys.stdin.detach()
        sys.stdout = sys.stdout.detach()

    Note that the streams can be replaced with objects (like
    io.StringIO) that do not support the buffer attribute or the
    detach() method and can raise AttributeError or
    io.UnsupportedOperation.

But the open calls (both for reading and writing files) don't open in
binary either.  So I can just assume that it is a permission problem
after all.  In UNIX, permissions are negotiated at the time of the
"open" system call.  If "open" succeeds, you can do everything that the
open system call asked for (unless you exceed the allotted quota or
physical space on the device).  I seem to remember that Windows is quite
more iffy about those kinds of thing.


-- 
David Kastrup