On 2021-06-29 20:59:51 -0700, L A Walsh wrote: > On 2021/06/29 17:55, Vincent Lefevre wrote: > > On 2021-06-29 13:30:53 -0700, L A Walsh wrote: > > > --- > > > No. the pwd utility has had its stdout redirected by its > > > parent, "the shell". Since the faulty redirection was done by parent, > > > is the error in the child or the parent? > > > > The redirection is not faulty. /dev/full is a valid file, with > > permissions to write to it. But it behaves as a full file system > > (like what may happen with any normal file system), i.e. yielding > > an ENOSPC error when writing to it. > --- > Sorry, difference of terminology. By faulty, I mean that the > parent application, (bash in this case), chose to redirect to > a location that was "full". I.e. it is a "faulty redirection", > in that it is redirected to a destination that will cause a > "fault" or "failure".
Note that in practice, one doesn't know when a file system is full; and it can become full during the process (after the redirection). So, the redirection is entirely valid. Here, /dev/full is used only for *testing* in order to test the behavior with ENOSPC errors (though this kind of testing is a bit limited, because the file system is full at the beginning... I wished the system could provide a FS similar to /dev/full or /dev/null, but with n remaining bytes, instead of 0 or infinity, respectively). > In a similar way, I made sure my /dev/zero was read only (AFAIK, it is > only for generating a stream of binary zeros), but I am not aware of > any useful effect of writing to it (unless it be the equivalent of > /dev/null, but I can use /dev/null for writing to, so at least for > now, I made my /dev/zero read-only. Then I ran both pwd and 'cd' with > output redirected to the read-only /dev/zero. Both failed and their action > was not performed -- verifiable by noting that "cd ~ >& /dev/zero" doesn't > change to my home directory. Note that under Linux, /dev/zero is not read-only. > Anyway, it is the parent that is directed the output to a location that > won't work as an output destination. In my example with >/dev/zero, I > got a permission denied from the parent process. If I had a /dev/full > I'd expect the same thing -- an error message from bash when it closes > the pipe to /dev/full. No, /dev/full is different: there is write permission, and as long as nothing is written to it, there should be no errors. When writing to it, the error is *not* due to a write permission, but due to a full file system. > the 'pwd' application cannot know or respond to the error, since the output > can be buffered and 'pwd' would exit, and the output would possibly be > closed > for pwd upon its exit -- unless the output was still open in the parent, and > only upon the final close, would you be guaranteed to get an error from the > 'close' operation as the buffers would fail to find space (on /dev/full). The solution is fflush(), which is actually needed independently of error checking, since when a built-in terminates, its effects must be visible. -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
