popen() system call hangs in HP-Ux 11.11

I have a program which calculates 'Printer Queues Total' value using '/usr/bin/lpstat' through popen() system call.

{
    int                     n=0;
    FILE                    *fp=NULL;

    printf("Before popen()");
    fp = popen("/usr/bin/lpstat -o | grep '^[^ ]*-[0-9]*[ \t]' | wc -l", "r");
    printf("After popen()");

    if (fp == NULL)
    {
            printf("Failed to start lpstat - %s", strerror(errno));
            return -1;
    }

    printf("Before fscanf");
    fscanf(fp, "%d", &n);
    printf("After fscanf");

    printf(开发者_开发技巧"Before pclose()");
    pclose(fp);
    printf("After pclose()");

    printf("Value=%d",n);
    printf("=== END ===");
    return 0;
}

Note: In the command line, '/usr/bin/lpstat' command is hanging for some time as there are many printers available in the network.

The problem here is, the execution is hanging at popen() system call, Where as I would expect it to hang at fscanf() which reads the output from the file stream fp.

If anybody can tell me the reasons for the hang at popen() system call, it will help me in modifying the program to work for my requirement.

Thanks for taking time in reading this post and your efforts.

---

What people expect does not always have a basis in reality :-)

The command you're running doesn't actually generate any output until it's finished. That would be why it would seem to be hung in the popen rather than the fscanf.

There are two possible reasons for that which spring to mind immediately.

The first is that it's implemented this way, with popen capturing the output in full before delivering the first line. Based on my knowledge of UNIX, this seems unlikely but I can't be sure.

Far more likely is the impact of the pipe. One thing I've noticed is that some filters (like grep) batch up their lines for efficiency. So, while popen itself may be spewing forth its lines immediately (well, until it gets to the delay bit anyway), the fact that grep is holding on to the lines until it gets a big enough block may be causing the delay.

In fact, it's almost certainly the pipe-through-wc, which cannot generate any output until all lines are received from lpstat (you cannot figure out how many lines there are until all the lines have been received). So, even if popen just waited for the first character to be available, that would seem to be where the hang was.

It would be a simple matter to test this by simply removing the pipe-through-grep-and-wc bit and seeing what happens.

---

Just one other point I'd like to raise. Your printf statements do not have newlines following and, even if they did, there are circumstances where the output may still be fully buffered (so that you probably wouldn't see anything until that program exited, or the buffer filled up).

I would start by changing them to the form:

printf ("message here\n"); fflush (stdout); fsync (fileno (stdout));

to ensure they're flushed fully before continuing. I'd hate this to be a simple misunderstanding of a buffering issue :-)

---

It sounds as if popen may be hanging whilst lpstat attempts to retrieve information from remote printers. There is a fair amount of discussion on this particular problem. Have a look at that thread, and especially the ones that are linked from that.