Stdout and Shell commands

[Dar Scott]

On Dec 4, 2006, at 5:24 AM, Mark Smith wrote:

> There are some shell commands (openssl sha1, for example) that take  
> their arguments from stdin or a file, but not the command line.  
> While it's easy to write data to a file and pass the filepath to  
> the shell, it's not very efficient if you want to do it many times  
> in succession.

What you want is process i/o.  See 'open process' etc.

There are some problems.  You have to do a half-close.  That is, you  
need to close the pipe to the tool without closing the pipe from the  
tool.

Revolution tries to do a half-close with a a control character (04,  
EOT, Control-D), but that doesn't work well.

On OS X you cannot do a half-close with binary.  This was done to fix  
a concern (bz 1770).

On OS X this does do a half-close with text mode, but there seems to  
be something fishy with the line ends in text mode.  Anybody know  
what is wrong with the line ends in this case?  This needs a bz but  
I'm not sure what is up.  I've tried this with sort and things don't  
get sorted.

On XP it gets a little mixed up with ^X or ^Z, I forgot which.  That  
is, Rev thinks it closed the pipe for ^D, but the application thinks  
it is still open.  Maybe you can send ^X^Z^D and something will  
happen.  I have some notes someplace but I don't think they were  
enough to bugzilla.

As you can see, I'm not clear on this.  We do need a half close  
command for open process and open socket.

If the tool reads a fixed number of lines or characters, you might be  
OK.  You don't have to do the half close.

I do have some other bugs reported on process I/O and some bugs that  
are not ready for bz on process I/O.


I'd go with the file for the input with shell() for now.  If the  
output is binary, then you should use a file for output, too, on  
Windows.  I have not had a problem with binary output on OS X.

Note that passwords are often not input with stdin even though they  
look like it.

Dar