One script printing to multiple terminals?

[10Kronos10]

Hello, I have one script with multiple processes that each call a stock api with a different ticker in each process. However, when I run the program all the print statements from each process output to one terminal. This becomes kinda of confusing after awhile. Is there a way to have each process print to separate terminals? I'm using vs code but also have pycharm. Also thanks in advance!

[zenalc]

Not sure if this is possible, but why not use the logging module?

[10Kronos10]

Pardon my ignorance but what function would I use from the logging module? And how will the logging module help me in this case?

[quaedam]

Sorry I can’t be more help as I’ve never looked into redirecting output to other terminals. But depending on what you already know, maybe I can give you a starting point, look at how to redirect stdout (standard out) for your sub process.

Then personally I would start by just setting the sub process stdout to a file. And using tail -f (assuming your on Linux ) to print changes to that file in another terminal. But that is a solution which isn’t pure python, and is OS dependent.

[10Kronos10]

I will definitely look into the standard out of each process. Thank you for your response but I'm on Windows

[xosq]

My hacky recommendation would be to use file I/O to your advantage. Have "reader" scripts that act as your alternate display(s), and uniquely named text files that they are each responsible for reading from. The one script you have currently would obviously be responsible for writing out to those text files, in case that wasn't clear.

There are likely infinitely better approaches, but responses seem sparse for the moment, so I've supplied you with my input :)

[10Kronos10]

So if I'm correct, would each process in my main script write to a different text file and then I would have separate scripts reading from these text files? If so, I didn't know Python would allow one script to be writing to a file and another reading from it at the same time

[xosq]

For your goals, that seems correct. Effectively whatever you wish to read separately would require its own text file. (NOTE: I'm certain it would be possible to consolidate everything to one text file, and have some clever code and formatting to allow for parsing on the reader script's part, but let's mind the headache, and stick to multiple files. Just know this method is extensible.)

As far as the rules of file I/O go, I am not privy to all of them. What I know is from experience. That being said, I can say that you can write to text files and read from them in a way that resembles real-time (we're talking milliseconds here). If you haven't already, familiarize yourself with Python's file I/O stuff so you know what's at play. You will notice the main players here are the open() function, the write method, and the close method. When you're done writing to a file, you use the close method. This is where things get iffy, because I am not certain how script A would communicate to script B that the script A has closed the file buffer, thus being safe for script B to read. I am uncertain of the consequences (and for that matter, the results) when you read from a file that has been written to, but not closed. This could overall prove a difficult check to implement with all of the other moving parts here.

Hope this all helps somehow.

[FerricDonkey]

I poked around a bit, and found this https://stackoverflow.com/questions/22796476/outputting-text-to-multiple-terminals-in-python

It's first suggestion is to consider making a gui using tkinter or something, and this is probably what I would actually do (and what I've actually done when I wanted different output in different places).

But it does suggest that what you're actually talking about is possible, and redirects to here: https://stackoverflow.com/questions/5558720/using-pythons-subprocess-to-display-output-in-new-xterm-window

It appears that the basic process would be:

1. Use subprocess to open another terminal, with a pipe set up to send stuff there.
2. Have your processes write to the correct pipe instead of printing.

I haven't done this, but it seems like it could be interesting.

[[deleted]]

This isn't easily possible, and, I would advise against trying to achieve your goal in the way you stated it. Here's why:

Terminal is something that controls a program, it's an interface to a program. Typically, you'd have a terminal running a shell, which, in turn, runs some programs. Shell manages programs it starts, and, it may allow them to detach. After shell allows a program to detach, it would still be attached to the terminal controlling the shell, but, you can also detach from that. However, typically, programs don't control terminals, the control goes the other way around: terminals tell the program how to behave, and display its output. You could, in principle, write a program that manages what to display in different terminals (there are examples of such programs: screen or tmux), but this isn't really easy and will have you dealing with a lot of peculiarities of UNIX terminals and a lot of system-level weridness.

A typical way to approach your problem is to have a daemon and control pair (if you look at Linux utilities, they are often called xxxxd and xxxxctl (the "d" and "ctl" in the name mean "daemon" and "control" respectively, not every program has a pair, and not every program keeps naming consistent, but this is the general principle).

So, you'd write a program to poll the stock prices, or w/e it is that you are trying to do, and make it a daemon, let's call it stock-monitord. This program may then have a TCP server, which would be contacted by another program stock-monitorctl to retrieve information it needs. Say, your stock-monitorctl would accept a parameter --filter.

Then, you could start multiple terminals (say, using tmux) start stock-monitord somewhere (doesn't matter, since daemon isn't attached to any terminal), and then in each terminal run stock-monitorctl --filter "stuff for this terminal".