write eof without closing


C

cage

hello

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

grts,
ruben
 
Ad

Advertisements

M

Marc 'BlackJack' Rintsch

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

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
 
G

Grant Edwards

can i write a eof to a file descriptor without closing it?

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.
 
C

cage

Marc 'BlackJack' Rintsch schreef:
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

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
 
T

Tim Chase

can i write a eof to a file descriptor without closing it?
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.

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
 
L

Lars

cage said:
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(...)

You might want to check the pty module in the Standard Library, and/or
Pexpect (http://pexpect.sf.net/)
 
Ad

Advertisements

D

Diez B. Roggisch

cage said:
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(...)

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
 
C

cwarren89

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.
 
C

cwarren89

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.
 
P

Philippe Martin

cage said:
hello

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

grts,
ruben

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
 
F

Fredrik Lundh

cage said:
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

have you tried *flushing* the output stream after each command?

</F>
 
Ad

Advertisements

G

Grant Edwards

Common Dos/Window convention also uses ctrl+Z (0x1a) for EOF.

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

IIRC, ctrl-Z is not used _in_files_ to represent EOF. Only
when text is being entered at the console.
*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$

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.
 
A

Alex Martelli

Grant Edwards said:
IIRC, ctrl-Z is not used _in_files_ to represent EOF. Only
when text is being entered at the console.

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
 
F

Fredrik Lundh

Alex said:
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"

your test doesn't match the OP's example, though, which used control-Z
to signal end of file when reading from the console:
>copy con test.txt
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:
>python -c "print repr(open('test.txt', 'rb').read())"
'hello\r\n'

</F>
 
Ad

Advertisements

G

Grant Edwards

Easy to test, if you have Windows:

I might, but I won't admit it in public. :)
'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)

That's correct.
and is still followed by Windows (and by Python running on
Windows).

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.
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Top