Also, inspecting bash code, this seems to be code to figure out if the file was changed from a non-regular file to a regular file between the stat and the open, so I'd say it's indeed a bug, but the problem is not the &&, but testing the wrong return code.
>From bash redir.c 631 /* OK, the open succeeded, but the file may have been changed from a 632 non-regular file to a regular file between the stat and the open. 633 We are assuming that the O_EXCL open handles the case where FILENAME 634 did not exist and is symlinked to an existing file between the stat 635 and open. */ 636 637 /* If we can open it and fstat the file descriptor, and neither check 638 revealed that it was a regular file, and the file has not been replaced, 639 return the file descriptor. */ 640 if ((fstat (fd, &finfo2) == 0) && (S_ISREG (finfo2.st_mode) == 0) && 641 r == 0 && (S_ISREG (finfo.st_mode) == 0) && 642 same_file (filename, filename, &finfo, &finfo2)) 643 return fd; 644 645 /* The file has been replaced. badness. */ 646 close (fd); 647 errno = EEXIST; 648 return (NOCLOBBER_REDIRECT); -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
