edh@ux.acs.umn.edu (Eric D. Hendrickson) (09/27/90)
On a local Sun, I am able to create a named pipe with "mknod filename p". The mknod command on Umax 4.3 doesn't appear to be capable of this. Is there some other way to create a named pipe on Multimaxen? Thanks, Eric -- /---------"Oh carrots are divine, you get a dozen for dime, its maaaagic."--- |Eric (the "Mentat-Philosopher") Hendrickson Academic Computing Services |edh@ux.acs.umn.edu The game is afoot! University of Minnesota \----"What does 'masochist' and 'amnesia' mean? Beats me, I don't know."---
jdarcy@encore.com (Floating Exception) (09/28/90)
edh@ux.acs.umn.edu (Eric D. Hendrickson) writes: >On a local Sun, I am able to create a named pipe with "mknod filename p". >The mknod command on Umax 4.3 doesn't appear to be capable of this. Is >there some other way to create a named pipe on Multimaxen? Mknod(1) will not (to the best of my knowledge) allow you to make a named pipe. On the other hand, mknod(2) is quite happy with the idea. In fact, and contrary to what the man page says, mknod(2) does *not* require that you be superuser in order to create a named pipe. It also seems that the manifest S_IFIFO is not mentioned in some man pages where one might expect it to be, such as stat(2). All these facts aside, here is a program you can use to create named pipes: ======================================================= #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #define ERROR (-1) int main (argc, argv) int argc; char **argv; { int errors = 0; if (argc <= 1) { fprintf(stderr,"Usage: %s path [...]\n",*argv); return(ERROR); } for (++argv; --argc; ++argv) { if (mknod(*argv,S_IFIFO|0666,0) == ERROR) { perror(*argv); ++errors; } } return(errors); } ======================================================= As usual, nothing I say here has anything at all to do with my being an employee at Encore. Encore does not monitor outgoing posts, assumes no responsibility for the usability or fitness for any particular purpose of the above code fragment, for any consequences arising from its use or misuse (or abuse), or for support thereof, and so on and on ad infinitum. Furthermore, Encore and its affiliates, business partners, customers and even those who've just heard of us in the trade rags are not responsible for the tedious and excessive nature of this disclaimer. As a matter of fact, any of the above-mentioned parties would probably be surprised and displeased if they knew I was posting this. Have I covered everything? For those who collect them: :-) :-) :-) :-) -- Jeff d'Arcy, Generic Software Engineer - jdarcy@encore.com Nothing was ever achieved by accepting reality