Problems when test whether standard input is capable of seeking

Question

I reversed statements in if/else, corrected now.

---

I am reading a code snippet from Advanced Programming in the UNIX® Environment:

The program tests its standard input to see whether it is capable of seeking.

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
int main(void){

    if(lseek(STDIN_FILENO,0, SEEK_CUR) == -1)
        printf("cannot seek\n");
    else{
        printf("seek ok\n");
    }
}

I compile and run it (under Ubuntu 18.04.2 LTS) but don't understand the following behaviors.

//1
$ ./a.out 
cannot seek

//2
$ ./a.out < /etc/passwd
seek OK

//3
$ cat < /etc/passwd | ./a.out
cannot seek

//4
$ ./a.out < /var/spool/cron/FIFO
cannot seek

Why //1 is cannot seek? Empty stdin should be able to seek I think. Is it because stdin has not been opened yet? Because I heard that normally stdin, stdout and stderr are opened when a program starts to run.

Why //2 is OK and //3 is not? I think they are the same.

Answer 1

//1 ./a.out:

If you do no redirection of stdin (no pipe and no <), stdin is inherited from the parent process. As you run a.out interactively in a shell, it inherits the terminal device that gets your keyboard input as stdin.

Terminal devices aren't usually seekable because they represent user interaction, but according to the POSIX standard lseek may return success and simply do nothing. On Linux lseek fails with an ESPIPE.

//2 ./a.out < /etc/passwd:

Here stdin is redirected to an open file. As /etc/passwd should be a regular file, it is seekable.

//3 cat < /etc/passwd | ./a.out:

Here you start two processes (cat and ./a.out) and connect them with a pipe.

cat (without other arguments) reads it stdin (/etc/passwd) and copies it to its stdout (the pipe connecting to ./a.out). This is not the same case as //2. From the perspective of ./a.out the stdin cannot seek because it is only a pipe connecting to another process.

//4 ./a.out < /var/spool/cron/FIFO:

Here you have a named pipe or similar special file. This case is similar to //3. You have an unidirectional connection to another process. And these are not seekable.