Forum > Unix
Close/reopen text file
Thaddy:
--- Quote from: MarkMLl on January 09, 2022, 02:47:43 pm ---No, stdout is the unix handle with the default value 1.
--- End quote ---
Am I right that you suggest that the official documentation is incorrect? >:D ;D
You can also reverse it: Output is really an alias for stdout. Clear?
If you really feel bad about it, file a bug against documentation.
The point is that from the language point of view the documentation is correct, but from the platform point of view it is the other way around. I would stick to the language.
You will find that the handle - on unix flavors - is indeed 1 as expected in most cases.
MarkMLl:
--- Quote from: Thaddy on January 09, 2022, 05:07:15 pm ---If you really feel bad about it, file a bug against documentation.
--- End quote ---
If /you/ really feel bad about it, file a bug against unix.
MarkMLl
PascalDragon:
You two are talking about two different things:
Thaddy says that StdOut is an alias of Output which in the context of FPC is definitely correct.
MarkMLI says that StdOut is an alias for the Unix handle with value 1, which is also correct, but in the context of Unix. In the context of FPC that is named StdOutputHandle.
MarkMLl:
I know that, and I suspect he knows that as well :-)
And I did carefully say at the start 'relationship between "Output" and the "stdout" handle'... and since this is the unix topic I'd have thought that the reference to "handle" needed no further expansion.
This does of course xref to my slightly older https://forum.lazarus.freepascal.org/index.php/topic,57706.0.html , and when considering closing/reopening it looks as though the preferred behaviour should be slightly different depending on whether output is to a regular file (where reopening will truncate) vs anything else.
However all I'm trying to do at present is rough out "reasonable" behaviour for the various types... and as discussed I anticipate that doing this to a named pipe will have undesirable consequences (which I'm documenting but not prohibiting).
MarkMLl
Kays:
--- Quote from: MarkMLl on January 09, 2022, 03:14:08 pm ---[…] I anticipate that either the inotify API,
--- End quote ---
Inotify does not work (reliably) on pseudo file systems such as procfs(5) or devfs/devtmpfs.
--- Quote from: MarkMLl on January 09, 2022, 03:14:08 pm ---a signal or a runtime error condition (EPIPE?) will alert the reader to the fact that the writer's closed its end.
--- End quote ---
Files are only really deleted if they are not opened (confer output of lsof(8)) and their (hardlink) reference count hits zero. Similarly, as long as someone somewhere (e.g. another process) holds a valid FD to stdout, this stdout is not closed/“deleted”.
--- 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 assign(FD, '/dev/stdout'); rewrite(FD); fpClose(stdOutputHandle); writeLn(FD, 'Hi!'); { still works as expected } writeLn('Bye!'); { causes RTE 101 }end.On FreeBSD you could use revoke(2) to really close /dev/stdout for good.
Navigation
[0] Message Index
[#] Next page
[*] Previous page