2026/04/05

Sunday, April 5, 2026 (#95)

Saturday Sunday Monday posts: prev < this > next

References Ferreteria/v0.6/clade/Sys/Data/Engine/endpt/Client/MyMar/@fx/NewSchemaList/@versions ‎ (← links) 2026/04/04 ‎ (← links) 2026/04/06 ‎ (← links)

• 09:45 We have once again achieved "successfully sending command to DB engine and not getting anything back" status.🎉
• 10:10 The fix turned out to be shockingly simple: a newline needed to be sent after the SQL command.
  • This must have been included earlier but somehow got removed in all the kerfuffle.
  • Now to test it over SSH...
• 14:52 The problem now is just how to make the SSH2 implement the model correctly whilst, under the hood, the actual operations work rather differently.
  • Every time I start to type out what I think I need to do, I realize it's wrong...
• 16:34 Some pencil-sketches have happened, via which I have sorted out a few things:
  • proc_open() is more analogous to ssh2_exec() than it is to ssh2_connect().
    • For modeling purposes, therefore, it might be best to think of it as "proc_exec()".
    • This is despite the fact that proc_open() and ssh2_connect() do have in common the fact that they both open a closeable session on which additional operations can be done (unlike ssh2_exec() which just returns a stream).
      • Reading the docs for ssh2_exec() again, I'm suddenly wondering if the stream is writable or not. It may be that I need to be running ssh2_shell() instead -- because {the only example I can find of sending data to the remote process} uses that, and not ssh_exec().
    • The only discrepancies between the two, as I understand it, have to do with having more control over a proc session than over an ssh2 session, because of the former being local and the other one being at the other end of a thirty-nine-and-a-half-foot pole.
  • Furthermore, just to complete the analogy, one could imagine a fictional proc_connect() which would do exactly nothing.

17:16 more model reworking

Model A what proc ssh2 open starter no op ssh2_connect() create session (w/ start-command) proc_open() ssh2_exec()

Model B what proc ssh2 open starter no op no op create session (w/ start-command) proc_open() ssh2_connect() ssh2_exec()

...so I think this means that Model A, which is more aesthetically appealing, is also a better fit for what's actually happening under the hood. I think.

In any case, I'm going to do whatever code-reworking is now necessary in order to apply that model -- because right now, the ssh2 version is running the start-command as a regular executable, rather than keeping it open.

...which makes me realize: oh, I'm not modelling the question of "keep executable open or close it"... Here we go again?

21:53 ssh2 quirks

After extensive dialogue with Copilot, I worked out that the trick to actually getting a response after sending a command to an open executable is twofold:

(1) do not set the stream to blocking mode

(2) wait for a response

• A 1-second delay worked reasonably well for this application, but it's probably better to loop and wait until a non-empty string is received.

Now I just need to integrate all that back into the framework...