Hello Denys! > This requires writable filesystem.
That depends on what you want to do. You only need a writable file system, when you create a temporary file using open or creat. If you use a pipe you do not need a writable file system. > But this leaks a file descriptor. It will never leak a file descriptor! Keep in mind, file descriptors are automatically closed when processes terminate. > The code itself is not that hard. bash does something like this: That's exactly what I mentioned using the pipe/fork variant. It uses /proc/self but this is a feature that may be dangerous, as it is not possible to export this filename to a sub shell or forked process. It is better to include the process Id into the filename. Besides this, that kind of code works ... and it does this for 30 years now, without failures. > See? fd 63 in the child LEAKS. No! It doesn't leak. File descriptors could never leak on a fully functional kernel/process management. File descriptors get always closed, as soon as the process terminates. > Child doesn't realize it has it open. True. That's the way this feature works in bash. > If child will decide to close the "file" it opened, > fd 63 will still be open, and the reading process will not see the EOF! True. This is exactly what happens at this point. The reading process waits until the writing end of the pipe gets closed, which is at termination of the child process. That is the way it will never leak. As soon, as the child process terminates the reading end of the process sees the EOF and continues it's work. > The second read() in the parent will not return 0 (EOF) at once, > it will wait 3 seconds for child to exit. > > This is wrong. What's wrong with this? It is exactly the way this feature works! Beside you are using this feature at the write end of the pipe. Initially I assumed you want to use the pipe on the read side like <$(foo). The write end of the pipe easily allows the usage of /proc/self where the read end will fail on /proc/self if you would use it in the shell, so the insertion of the process id (of the shell process, which created the pipe) in the name is required. You asked, how that feature in bash works. It works exactly like your example shows. So what is your problem with this? There is no file descriptor leakage. You won't see an explicit close of the file descriptor in your strace, but all open file descriptors are always closed implicitly on process termination. That close finishes writing the pipe and let the reading side see the EOF. -- Harald _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
