Forum > Unix
Close/reopen text file
MarkMLl:
Is it possible to close and then reopen the "Output" device on Linux?
The situation is that I've got potential output to the unnamed "Output" device, to a named file, to a unix-domain pipe or to a FIFO (named pipe).
The output format does not, as standard, have any form of EOF marker so any cooperating programs have to use e.g. the inotify (FAM) API to monitor the writer's state.
If the writer program is looping, e.g. to process successive runs of an instrument capture, then it can close output routed to any of the named file types and then reopen it immediately before starting another run.
For the purpose of orthogonality, I would like to be able to handle "Output" in the same way. I appreciate that if this is being redirected or piped (by the shell) that the behaviour might be undefined, but for the moment I'm focussing on the writer and the relationship between "Output" and the "stdout" handle: any signals or error states seen by the reader is for another day.
MarkMLl
Thaddy:
--- Quote from: MarkMLl on January 09, 2022, 01:46:10 pm --- but for the moment I'm focussing on the writer and the relationship between "Output" and the "stdout" handle: any signals or error states seen by the reader is for another day.
MarkMLl
--- End quote ---
FYI stdout is simply an alias for output. They are interchangeble.
https://www.freepascal.org/docs-html/rtl/system/stdout.html
So relation part solved :D
As for eof, dunno. Afaik that is indeed not standard for output/stdout.
MarkMLl:
--- Quote from: Thaddy on January 09, 2022, 02:38:20 pm ---FYI stdout is simply an alias for output.
https://www.freepascal.org/docs-html/rtl/system/stdout.html
So relation part solved :D
As for eof, dunno. Afaik that is indeed not standard.
--- End quote ---
No, stdout is the unix handle with the default value 1.
I anticipate that closing/reopening "Output" hence stdout will break something if e.g. it's being piped to another program. I'm not all that bothered, "somebody else's problem".
MarkMLl
Kays:
--- Quote from: MarkMLl on January 09, 2022, 01:46:10 pm ---Is it possible to close and then reopen the "Output" device on Linux?
--- End quote ---
No, not the way you want it: Once /dev/stdout has been closed it is not connected to the respective terminal [or file myProgram > outfile] anymore. You cannot, at least not trivially, regain access to user’s console (or the file specified on the command line upon program invocation).
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---uses baseUnix;var FD: text;begin fpClose(stdOutputHandle); assign(FD, '/dev/stdout'); rewrite(FD); { causes RTE 2 "File not found" }end.
MarkMLl:
--- Quote from: Kays on January 09, 2022, 03:00:01 pm ---No, not the way you want it: Once /dev/stdout has been closed it is not connected to the respective terminal [or file myProgram > outfile] anymore. You cannot, at least not trivially, regain access to user’s console (or the file specified on the command line upon program invocation).
--- End quote ---
In practice, I think that's exactly what I want: I'd forgotten that special device.
I anticipate that either the inotify API, a signal or a runtime error condition (EPIPE?) will alert the reader to the fact that the writer's closed its end. If in practice the reader can't recover... that's not the writer's problem, the user should have set things up to use a unix-domain socket or a FIFO.
It might be possible for the reader to examine the writer's /proc/something/fd/1 and to reconnect, but again that's not the writer's problem.
MarkMLl
Navigation
[0] Message Index
[#] Next page