Control stript which is runing in background.

[2QdxY4RzWzUUiLuE at potatochowder.com]

On 2021-01-01 at 11:11:47 +0100,
jak <nospam at please.ty> wrote:

> Il 01/01/2021 04:14, 2QdxY4RzWzUUiLuE at potatochowder.com ha scritto:
> > On 2021-01-01 at 03:43:43 +0100,
> > jak <nospam at please.ty> wrote:
> > 
> > I think you were clear enough before, but you may not have
> > considered things the OP did not specify.  One of the hardest parts
> > of software development is understanding and specifying the actual
> > problem to be solved.  I've never done that in a second language
> > (I'm nowhere near fluent in anything other than English); I can only
> > imagine the extra layers of complexity.
> 
> This is the OP's initial request:
> 
> > Hi. I would like to make something like this:
> > A python script would run headlessly in the background.
> > I would like to control the script from the command line using other python scripts or from the python shell.
> > From time to time I would ask the main script to create a popup window with an image or a plot.
> > What would be the proper way to approach it. How to make communication between two scripts?
> > Thank you.
> > Petro.
> 
> I have suggested an alternative way for his necessity.
> It will be up to him to decide which one he should adopt. That way he
> has a choice, at least.
> I don't know where you work. I know, however, that in these zones, if
> you do more than necessary wasting their time, they will kick you away.

So what is necessary?  Does "control the script" include reporting
success or failure of a request?  The OP also said "communication
between two scripts," which to me means two way traffic.  Only the OP
knows for sure, and at least one of us might get it wrong if we don't
ask, or at least acknowledge that we don't know.

If I start with a named pipe because it's good enough for Phase Zero, or
Version 0.0.1, or Release Experimental Alpha, then I'm going to end up
ripping that out or reinventing something that already existed on top of
that named pipe.

Suppose I look ahead just a little, and use a socket in the first place.
Yes, you could argue that it's more than what was necessary and kick me
away.  Will you kick me again when you can build on it (I can't; I'm
gone) instead of having to rebuild what already worked?

I'm retired now, but I at one employer, I worked on products with (a)
lifetimes measured in decades, (b) extremely expensive (money, time,
convenience, etc.) upgrade/maintenance cycles, and therefore (c) strict
interoperability requirements.¹  A little bit of foresight and extra
analysis up front went a long way towards saving a lot of headaches and
development resources (and customers!)  in the long term.
Communications protocols in particular had to be well thought out, and
often more complex than was immediately necessary, because backwards and
forwards compatibility were not negotiable.

Again, I'm not (and no one else is, either) saying that your solution is
wrong or won't work.  Your solution may even be the be the best solution
to the OP's problem.  All I'm saying is that we can't know until the OP
tells us more.  Yes, the OP has a choice to make.  Maybe we have helped,
not by making that choice, but by giving it to the OP with enough
supporting information to make it.

¹ Think about a system containing dozens of individually field
upgradeable components.  It had to work when a customer upgraded one
component at a time (over the course of weeks or months), or plugged in
an old component while they were waiting for a broken one to be
repaired, or added a brand new component to a system that hadn't been
changed or upgraded for years.  There was no such thing as telling the
customer to wait, or to make them take down the entire system to upgrade
everything at once.  *That* was what was necessary.