"Although it is typically not important to know, it’s worth stating anyway that while you can access these file descriptors though the above paths they actually exist in the memory allocated to the program by libc."
Incorrect. The file descriptors exist in kernel memory, and user code simply refers to them by number. (Sure, you have to allocate memory for the number, but that's not necessarily done by libc.)
Randal Schwartz used to give out the "Useless use of `cat' award" to annoyed posters in comp.unix.shell because of the relative obscurity of the `<' operator.
(actually his main point was that most unix commands take a file as an arguments, but for the ones that don't you can just slurp it into stdin with `<')
Nowadays, we could say the same thing about useless uses of `echo', given the modern `<<<' operator.
This article is a little bit imprecise at times. It refers to pipes as FIFOs and seems to mix up FILE* and file descriptors.
Also it has a lot more IO redirection and not really much file descriptors except for the very beginning. The description of how redirection works is rather vague. There should be something about how the shell dup()'s over standard file descriptors to create redirection.
I disagree. The post seems to me like it is aimed at learning new things, not an in-depth investigation on how the things you're already doing work in the background.
The things in the article are explained on their own level, and then a level below it, i.e. the file descriptors. How the file descriptors work, where they're stored, things like that, are well out of the scope of the article.
Incorrect. The file descriptors exist in kernel memory, and user code simply refers to them by number. (Sure, you have to allocate memory for the number, but that's not necessarily done by libc.)