write eof without closing

Discussion in 'Python' started by cage, Aug 19, 2006.

  1. cage

    cage Guest

    hello

    can i write a eof to a file descriptor without closing it?
    like:
    fd.write(EOF)
    or something

    grts,
    ruben
     
    cage, Aug 19, 2006
    #1
    1. Advertisements

  2. What do you expect this to to? Writing a byte to the file and you don't
    know which value this byte has?

    Ciao,
    Marc 'BlackJack' Rintsch
     
    Marc 'BlackJack' Rintsch, Aug 19, 2006
    #2
    1. Advertisements

  3. No. Not on Windows, OS-X, or Unix. There is no such thing as
    "an eof".

    On CP/M Ctrl-Z is used as EOF for text files.
     
    Grant Edwards, Aug 19, 2006
    #3
  4. cage

    cage Guest

    Marc 'BlackJack' Rintsch schreef:
    ok let me explain this a bit more...
    I want to use a program that has a 'pipe' mode, in which you can use
    stdin to send commands to the program. I found out that, when in pipe
    mode and you are using the keyboard as input source you can do Ctrl-D to
    'signal' the program that you have finished typing your command. The
    program parses and then performs the command, and it doesn't quit. It
    quits after 'Quit\n' + Ctrl-D
    Now I want a python script to provide the input, how do i do that? I now
    use popen to be able to write to the program's stdin (p_stdin)
    I noticed that when i do a p_stdin.close() it acts as a 'ctrl-d' in that
    the program recognizes the signal to process the command, but then I
    cannot use p_stdin anymore to do p_stdin.write(...)

    grts,
    ruben
     
    cage, Aug 19, 2006
    #4
  5. cage

    Tim Chase Guest

    can i write a eof to a file descriptor without closing it?
    Common Dos/Window convention also uses ctrl+Z (0x1a) for EOF.

    c:\> copy con test.txt
    hello
    ^Z
    c:\>

    *nix usually uses ctrl+D (0x04) as an EOF signal...and OS-X being
    Unixish also uses the same.

    bash$ cat > test.txt
    hello
    ^D
    bash$

    Don't know about Macs earlier than OS-X.

    I don't know if there are problems (triggering an actual EOF and
    closing the file) writing either of these ascii characters in
    ascii/text mode (may vary between platforms?), but there are no
    problems writing either of these characters in binary mode.

    -tkc
     
    Tim Chase, Aug 19, 2006
    #5
  6. cage

    Lars Guest

    You might want to check the pty module in the Standard Library, and/or
    Pexpect (http://pexpect.sf.net/)
     
    Lars, Aug 19, 2006
    #6
  7. According to wikipedia (german version, but I bet you can get that info
    using the english one, too) C-d sends EOT - end of transmission. Which
    is ascii 0x04.

    So I suggest you try writing

    "\x04"

    to the pipe. Maybe that works.

    Diez
     
    Diez B. Roggisch, Aug 19, 2006
    #7
  8. cage

    cwarren89 Guest

    Writing the binary value for ^D into the stream will not do anything.
    That value signals the shell to close the stream, as such it only has
    significance when you're typing something into the shell.

    To the OP: writing an EOF to a stream without closing it makes no
    sense. EOF means just that--end of file. Once the program reaches an
    EOF, it can't read any more values from the stream, so keeping it open
    to write more stuff into it wouldn't even work.
     
    cwarren89, Aug 19, 2006
    #8
  9. cage

    cwarren89 Guest

    Actually, nevermind. It appears that receiving an EOF from a stream
    tells it when to stop 'reading', not necessarily that the stream is
    closed. What a weird behavior.
     
    cwarren89, Aug 19, 2006
    #9
  10. No but there is an EOF to the file anyway, even if it is open.

    I recall under MS-DOS, you could create a file of size N without writing to
    it (some INT21 or 9 ? call to modify the FAT) ... not really possible
    anymore.

    Philippe
     
    Philippe Martin, Aug 19, 2006
    #10
  11. have you tried *flushing* the output stream after each command?

    </F>
     
    Fredrik Lundh, Aug 20, 2006
    #11
  12. IIRC, ctrl-Z is not used _in_files_ to represent EOF. Only
    when text is being entered at the console.
    That's just the tty line-discipline layer of the tty driver.
    When it sees Ctrl-D as the first thing on a "line", it closes
    the file descriptor causing the client to see an EOF. That
    feature in the line-discipline layer can be disabled or
    configured to use any other character.

    I suspect what the OP really needs to do is write a newline and
    then flush the stream.
     
    Grant Edwards, Aug 21, 2006
    #12
  13. Easy to test, if you have Windows:
    'ba\n'

    As you see, in _text_ files on Windows a control-Z (char(26), AKA
    '\x1a') does indeed represent "end of file" -- a convention going back
    to CP/M (which lacked metadata to represent file length except in
    multiples of 256 characters, if I recall correctly) and is still
    followed by Windows (and by Python running on Windows).

    Nevertheless I doubt it would help the original poster -- I think, like
    /F and you, that a line-end and flush may be what he needs.


    Alex
     
    Alex Martelli, Aug 21, 2006
    #13
  14. your test doesn't match the OP's example, though, which used control-Z
    to signal end of file when reading from the console:
    hello
    ^Z
    1 file(s) copied.

    that control-Z works in the same way as control-D on Unix, and no EOF
    character is copied to the file:
    'hello\r\n'

    </F>
     
    Fredrik Lundh, Aug 21, 2006
    #14
  15. I might, but I won't admit it in public. :)
    That's correct.
    Very interesting. I thought that windows had abandoned that. I
    remember having problems under DOS/Windows caused by an old
    text editor that put a ctrl-Z at the end of the file --
    probably a result of the other programs reading the file in
    binary mode and seeing the ctrl-Z.
     
    Grant Edwards, Aug 21, 2006
    #15
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.