2026/03/16

Monday, March 16, 2026 (#75)

Sunday Monday Tuesday posts: prev < this > next

References Ferreteria/v0.6/clade/IO/Aspect/Connx/run/Starter/Remote/SSH2/@fx/DoCommand ‎ (← links) Ferreteria/v0.6/clade/IO/Aspect/Connx/run/Starter/Local/@fx/DoCommand/@removed ‎ (← links) 2026/03/15 ‎ (← links) 2026/03/17 ‎ (← links)

• 10:10 I had a theory that maybe the stream was being broken by an error, and I needed to see what that was -- but so far I'm not finding anything in the ErrorBin. Either that subsystem isn't working right, or that's not the problem.
• 10:20 Adding a half-second delay to the buffer-send loop just means it fails sooner, in terms of bytes sent. This implies that something else is closing the pipe after some amount of time has passed.
• 11:56 By looking at the process status, I found what must be the problem: it's still prefixing with echo '' |. That seems like an empty-command-detection logic problem.
• 18:46 I think that did get fixed, but now we have a more crunchy problem: the final invocation of the core command (e.g. "mysql <credentials options>") still looks like a non-empty command, because it kinda is -- so I guess that's not going to work as a flag? I have to re-model this in my head...
  • Maybe we're back to having just a DoWait() flag? There are two places where we need to flag different behavior for the core command:
    • (1) in the Engine Server -- do we wrap the command with echo / [pipe] or not
    • (2) in the Runner -- do we wait for output, or exit right away
      • Maybe the caller should be handling the I/O wait-loop, instead of the Runner. Then we wouldn't have to signal this.
        • ...except the reason we do this, at least in Local\Proc, is because the Proc knows when it's done.
        • We could, however, have an object-function for this. ...if we don't already.
          • Yes, there sort of is one: IsRunning() is defined for Remote\SSH2 and Local\Proc's Status object, but it hasn't been part of the Runner API. The first test, then, will to see if it can be implemented across all the Runner classes currently in use.
          • Okay, that was pretty doable. Those two Runner classes are the only ones currently in use right now.
        • The next step is exposing the Canals object, which the Runner sets up inside DoCommand() before doing the I/O wait-loop.
          • It still makes sense for this setup to happen there, because different Runner classes have different ways of accessing their streams. (Hence the need for the well-known "Setup Ways and Streams Committee".)