[m-users.] Capturing process output.

[Volker Wysk]

Am Samstag, dem 31.08.2024 um 20:15 +0200 schrieb Zoltan Somogyi:
> 
> 
> On Sat, 31 Aug 2024 18:38:18 +0200, Volker Wysk <post at volker-wysk.de>
> wrote:
> > For this to work, a predicate for attaching a stream to an existing file
> > descriptor would be needed. It doesn't look like this is provided by the
> > io/io.call_system libraries.
> 
> There is no such predicate in the Mercury standard library, because
> whenever possible, we want library predicates to be platform-agnostic,
> running on Windows as well as on Unix-like operating systems,
> but file descriptors are a Unix-specific concept. 

File descriptors are a POSIX concept, aren't they? I thought that Windows
was POSIX compliant... until I looked for this in the web. It isn't really.

> I guess we could add
> some abstraction of "an already opened file" that would be a file
> descriptor
> on Unix-like OSs and something else on Windows, but I don't know
> what that something else would be. (I know enough about Windows
> to know that I don't *want* to know more :-)

Hehe  :-)

> I view deciding on such an abstraction, both its meaning and its
> implementation,
> as a necessary first step in implementing the functionality you want,
> since it would represent one of its inputs.

You can write code in Mercury, that isn't platform-agnostic, because of the
foreign language interface. You can provide foreign code for just one
platform (such as C/Unix). That's fine.

Can't the wanted functionality be provided by a C language function, like
MR_GC_malloc, so it can be used in foreign C code? That would suffice.

> Note: the related operations are not in io.call_system.m, but in
> io.stream_ops.m. The C, C# and Java foreign_procs there invoke
> operations in their respective languages that combine opening a file
> with constructing the Mercury representation of a stream of top of
> the result of the file open (e.g. on top of a file descriptor on Unix-like
> OSs).
> The logical way to implement the functionality you describe would be
> to split each of those operations in two, since you want to use
> the second part on its own. So the code you want already (mostly) exists;
> it is just currently welded together with code you *don't* want.
>
> > I would be inclined to contribute this to the standard libraries, if
> > that is
> > welcome. I know that a high code quality would be required.
> 
> It would be welcome, but we would need not just a C implementation
> that works on Unix/MacOS/Windows (possibly with #ifdefs), but also
> C# and Java implementations.

I can't help with Windows, Java or C#. MacOS is a POSIX certified, Unix-
based system. If I write something like that run_program, it will be Unix
only (unless someone picks it up and ports it to Windows/Java/C#).


Cheers,
Volker