Control stript which is runing in background.

[jak]

Il 01/01/2021 14:49, 2QdxY4RzWzUUiLuE at potatochowder.com ha scritto:
> 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.
> 
Sorry if I made you argumentative. It was not my intention. Let me
reiterate once again that my intention was to offer an alternative to
the OP and that I never claimed my way was better than the other
suggestions. Furthermore, the OP will have already made its choice by
now. Just one last comment: I understand your point of view but I
disagree because the difficulty in providing assistance as the customer
wishes depends on how you have designed the product and not on how you
develop the pieces that compose it. One more thing: you probably don't
care anymore, but people have taught me that if you give a customer
something, you can't sell it to him anymore.

Sorry again.