2026/02/25

From Woozle Writes Code
Jump to navigation Jump to search
Wednesday, February 25, 2026 (#56)
Tuesday Wednesday Thursday posts:prev <this> next

I'm now struggling with how to implement the distinction between {execute a single command, and the process ends when the command is done} vs. {execute a single command which waits for more input, so I can send it gigabytes of stuff and then close the process when that is done}...

I have part of an idea, and I hope I'm not scrambling things again by implementing it.

I think I see the underlying reason of how this problem came to be: ssh2_* functions let you open a connection without a command, but proc_open() needs to run something. (Documentation: For now, see PHP/resource -- but there should eventually be PHP/resource/process and PHP/resource/ssh2.)

Later I

I've added a flag to the CmdLine clade. The trick now is how to access the I/O streams -- which Proc exposes, but SSH2 does not (they're not required by Runner).

...and I'm wondering if maybe CmdLine, or a podling thereof, should be where those are stashed... or is the more-obvious idea of requiring them in Runner preferable?

Later II

Aha! The reason why putting the streams in CmdLine is a good idea is that this gives the end-client code direct access to them, instead of having to fish down the connection-chain for the end-server process.

So that's what I'll do.

...and oh, wait, they're already there: QOLecturer() and QOListener(). So... what was I already using those for? (I think it was just a couple of days ago that I set this up...):

  • QOLecturer() - not used yet
  • QOListener() - SSH2 looks for the desired output stream here
    • Exporter also defines this as a last-mile bridge between whatever invokes Exporter and the CmdLine object (which Exporter creates)

I also defined QOAudience() and QOLecturer() in Runner:

  • QOAudience() - Proc looks for the desired output stream here, but nothing sets it and nothing else uses it
  • QOLecturer() - never used

In Proc::DoCommand() there's a note: «2026-02-22 Maybe if !$doOBuff, we should QOAudience()->SetIt(...something...)» -- which makes me think that there was always a need to properly define all this stuff, and maybe now I'm seeing enough of the picture to actually do that.

The Plan

Here's what I think I will do:

1. [DONE] In Exporter: remove QOListener(), and replace it with QOCommand.
  • That way if the caller needs to be able to send or receive stuff via the Command object, they can set it beforehand or retrieve it afterwards as appropriate.
  • This required creating QCmdLine (if I wanted to keep with my current convention, anyway).
1a. [DONE] Update Schema\MyMar (currently the only user of Export) to create its own CmdLine and pack its desired Listener Stream in there instead of passing it to Exporter.
2. Remove QOAudience() and QOLecturer() from Runner... after making sure I understand their role there vs. their role in CmdLine, anyway.
2a. ...and update any other code which was using them.
3. Re-examine the 2026-02-22 suggestion, and resolve it one way or another.