title: File Descriptor 0
body: <p>Drawing from <a href="https://stackoverflow.com/questions/3816774/is-the-file-pointed-by-stdin-file-descriptor-the-same-file-for-different-process">this thread</a> discussing file descriptors and tables;</p>
  
  <p><strong>I want to know how stdin (that is, file descriptor 0, not C's stdin FILE structure) is handled within shells.</strong></p>
  
  <p>When I run a piece of code like <code>read(0, buffer, 1024)</code> in C, which by default in C file descriptor 0 is connected to keyboard, the shell allows me to type text in, because, we assume, read is waiting to read the contents of the character device 'standard input', aka the keyboard. But wouldn't standard input simply be empty and produce that as its result? Alright, so let's say that 'connected to keyboard' path is the way of explaining it; if that's the case, then that must mean shells line buffer their command's, right? Calling a read on file descriptor 0 would mean that file descriptor 0 in a shell is connected to this line-buffered buffer output of standard input, and not directly to the keyboard, so what's making C wait around? Furthermore, why can we not use <code>lseek()</code> on standard input - does said 'file' always get overwritten every 'write' that's made to it and therefore there is nothing to seek around in as standard input (being the keyboard) is not really a file on a storage device per se? </p>