[erlang-questions] Issues with stdin on ports

[Robert Raschke]

Hi Anthony,

could Py-interface http://www.lysator.liu.se/~tab/erlang/py_interface/ help
with that?

Note, I've not used it, so don't know much at all beyond reading that page.
It would probably mean using the Pygments library, rather than going via
the command line pygmentize. You can probably take the pygmentize source
and replace the command line handling with setting up a Python Node.

Alternatively, and not necessarily very nice, instead of streaming to
pygmentize, write to a file and invoke on that. You wouldn't even need a
port then, you could get away with os:cmd/1 (if you aren't interested in
return codes). But you already know this, I think.

Robby

PS Something like expect for Erlang ports would be pretty cool, though. Not
that I'm not volunteering ;-)



On Mon, Jul 29, 2013 at 10:19 AM, Anthony Grimes <i@REDACTED> wrote:

> Hey Robert.
>
> I don't think C nodes help in this case, and they don't solve the general
> problem. One of my use cases is talking to pygmentize, which is a Python
> program. If I want to do that, I have to write a middleman program that
> does the actual communication with this program and talks to my Erlang
> program over a socket, or via ports if I make the middleman program look
> for some specific sequence of bytes to treat as EOF since I can't send
> actual EOF.
>
>
> On Mon, Jul 29, 2013 at 2:12 AM, Robert Raschke <rtrlists@REDACTED>wrote:
>
>> Hi Anthony,
>>
>> In the past, I've tended to use the port mechanism to simply kick off a C
>> node, which then allows you to have full control over whatever
>> communications needs you have.
>>
>> This obviously only works if you are interfacing with a technology that
>> will allow you to create C node and use the EI libs in some way. Not sure
>> if that is the case from what you wrote.
>>
>> Regards,
>> Robby
>> On Jul 29, 2013 8:04 AM, "Anthony Grimes" <i@REDACTED> wrote:
>>
>>>  Howdy folks.
>>>
>>> I unfortunately have not been able to use Erlang for most of what I've
>>> been doing lately because of a long standing issue with Erlang ports
>>> that I'd like to start a discussion about here.
>>>
>>> As far as I am aware, ports are generally the only option for creating
>>> and communicating with external processes in Erlang. They seem to have
>>> at least one particular fatal flaw which prevents them from being very
>>> useful to me, and that is that there is no way to close stdin (and send
>>> EOF) and then also read from the process's stdout. For example, I cannot
>>> use a port to start the 'cat' program which listens on stdin for data
>>> and waits for EOF and then echos that data back to you. I can do the
>>> first part, which is send it data on stdin, but the only way for me to
>>> close it is to call port_close and close the entire process.
>>>
>>> This issue prevents Erlang users from doing any even slightly more than
>>> trivial communication with external processes without having some kind
>>> of middleman program that handles the creation of the actual process you
>>> need to talk to and looks for a specific byte sequence to indicate 'EOF'.
>>>
>>> I could totally be wrong, but it seems like we need something other than
>>> just port_close. Something like
>>> http://www.erlang.org/doc/man/**gen_tcp.html#shutdown-2<http://www.erlang.org/doc/man/gen_tcp.html#shutdown-2>
>>>  which lets you say
>>> "Hey, I want to close the stdin of this process but still read from its
>>> stdout." or something similar. I could be totally off track on what a
>>> good solution would be.
>>>
>>> So I'm wondering if people are aware of this problem, and I'd like to
>>> make sure that people think it is an actual problem that should be
>>> fixed. I'm also curious what people think a good solution to the problem
>>> would be. I'm not sure I have the time/particular skill set to fix it
>>> given that the port code is some pretty obscure (to me) C code, but
>>> starting conversation seems like a good way to begin.
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130729/4e25958b/attachment.htm>