oracular (3) libsystem.3.gz

Provided by: libnetpbm-dev_11.07.00-2_amd64 bug

Name

       pm_system - run a Netpbm program with program input and output

Synopsis

       #include <netpbm/pm_system.h>

       pm_system(void                  stdinFeeder(int, void *),
                 void *          const feederParm,
                 void                  stdoutAccepter(int, void *),
                 void *          const accepterParm,
                 const char *    const shellCommand);

       pm_system_lp(const char *  const progName,
                    void                stdinFeeder(int, void *),
                    void *        const feederParm,
                    void                stdoutAccepter(int, void *),
                    void *        const accepterParm,
                    ...);

       pm_system_vp(const char *  const progName,
                    const char ** const argArray,
                    void                stdinFeeder(int, void *),
                    void *        const feederParm,
                    void                stdoutAccepter(int, void *),
                    void *        const accepterParm);

       pm_system2(void                  stdinFeeder(int, void *),
                  void *          const feederParm,
                  void                  stdoutAccepter(int, void *),
                  void *          const accepterParm,
                  const char *    const shellCommand,
                  int *           const termStatusP );

       pm_system2_lp(const char *  const progName,
                    void                stdinFeeder(int, void *),
                    void *        const feederParm,
                    void                stdoutAccepter(int, void *),
                    void *        const accepterParm,
                    int *         const terminationStatusP,
                    ...);

       pm_system2_vp(const char *  const progName,
                    const char ** const argArray,
                    void                stdinFeeder(int, void *),
                    void *        const feederParm,
                    void                stdoutAccepter(int, void *),
                    void *        const accepterParm,
                    int *         const termStatusP);

Example

       This simple example converts a PNM image on Standard Input to a JFIF (JPEG) image on Standard Output.  In
       this case, pm_system() is doing no more than system() would do.

           pm_system(NULL, NULL, NULL, NULL, "pnmtojpeg");

       This example does the same thing, but moves the data through memory buffers to illustrate use with memory
       buffers, and we throw in a stage to shrink the image too:
       #include <netpbm/pm_system.h>

       char              pnmData[100*1024];   /* Input file better be < 100K */
       char              jfifData[100*1024];
       struct bufferDesc pnmBuffer;
       struct bufferDesc jfifBuffer;
       unsigned int      jfifSize;

       pnmBuffer.size = fread(pnmData, 1, sizeof(pnmData), stdin);
       pnmBuffer.buffer = pnmData;
       pnmBuffer.bytesTransferredP = NULL;

       jfifBuffer.size = sizeof(jfifData);
       jfifBuffer.buffer = jfifData;
       jfifBuffer.bytesTransferredP = &jfifSize;

       pm_system(&pm_feed_from_memory, &pnmBuffer,
                 &pm_accept_to_memory, &jfifBuffer,
                 "pamscale .5 | pnmtojpeg");

       fwrite(jfifData, 1, jfifSize, stdout);

       This  example  reads  an  image  into libnetpbm PAM structures, then brightens it, then writes it out, to
       illustrate use of pm_system with PAM structures.
       #include <netpbm/pam.h>
       #include <netpbm/pm_system.h>

       struct pam       inpam;
       struct pam       outpam;
       tuple **         inTuples;
       tuple **         outTuples;
       struct pamtuples inPamtuples;
       struct pamtuples outPamtuples;

       inTuples = pnm_readpam(stdin, &inpam, sizeof(inpam));

       outpam = inpam;

       inPamtuples.pamP = &inpam;
       inPamtuples.tuplesP = &inTuples;
       outPamtuples.pamP = &outpam;
       outPamtuples.tuplesP = &outTuples;

       pm_system(&pm_feed_from_pamtuples, &inPamtuples,
                 &pm_accept_to_pamtuples, &outPamtuples,
                 "pambrighten -value +100");

       outpam.file = stdout;
       pnm_writepam(&outpam, outTuples);

DESCRIPTION

       These library functions are part of Netpbm(1).

       pm_system() is a lot like the standard C library system() subroutine.  It runs a shell and has that shell
       execute a shell command that you specify.  But pm_system() gives you more control over the Standard Input
       and Standard Output of that shell command than  system().   system()  passes  to  the  shell  command  as
       Standard  Input  and Output whatever is the Standard Input and Output of the process that calls system().
       But with pm_system(), you specify as arguments subroutines to execute to  generate  the  shell  command's
       Standard Input stream and to process the shell command's Standard Output stream.

       Your  Standard Input feeder subroutine can generate the stream in limitless ways.  pm_system() gives it a
       file descriptor of a pipe to which to write the stream it generates.  pm_system() hooks up the other  end
       of that pipe to the shell command's Standard Input.

       Likewise,  your  Standard  Output  accepter  subroutine can do anything it wants with the stream it gets.
       pm_system() gives it a file descriptor of a pipe from which to read the stream.  pm_system() hooks up the
       other end of that pipe to the shell command's Standard Output.

       The  argument  stdinFeeder  is  a function pointer that identifies your Standard Input feeder subroutine.
       pm_system() runs it in a child process  and  waits  for  that  process  to  terminate  (and  accepts  its
       completion  status)  before  returning.   feederParm  is  the  argument  that  pm_system()  passes to the
       subroutine; it is opaque to pm_system().

       If you pass stdinFeeder = NULL, pm_system() simply passes your current Standard Input stream to the shell
       command (as system() would do), and does not create a child process.

       The  argument  stdoutAccepter  is  a  function  pointer  that  identifies  your  Standard Output accepter
       subroutine.  pm_system() calls it in the current process.   accepterParm  is  an  argument  analogous  to
       feederParm.

       If  you  pass stdoutAccepter = NULL, pm_system() simply passes your current Standard Output stream to the
       shell command (as system() would do.

       The argument shellCommand is a null-terminated string containing the shell command that the shell  is  to
       execute.   It can be any command that means something to the shell and can take a pipe for Standard Input
       and Output.  Example:

           pambrighten -vale +100 | pamdepth 255 | pamscale .5

       pm_system() creates a child process to run the shell and waits for that process to terminate (and accepts
       its completion status) before returning.

       If  the  shell  fails,  i.e. does not exit voluntarily with zero exit status, pm_system calls pm_error(),
       which normally issues an error message to Standard Error and exits the program.  Use pm_system2() if  you
       don't want that.

       Note  that the 'termination status' of a Unix process is a value which is a combination of 1) whether the
       process exited voluntarily or was killed by the operating system; 2) in the case of  termination  by  the
       OS,  what  class  of  signal did it; and 3) in the case of voluntary exit, what 'exit status' the program
       declared.

   Interface Header File
       These interfaces are declared by <netpbm/pm_system.h<.

   pm_system2()
       This is the same as pm_system() except that rather than respond to the shell process' termination status,
       it just returns it to you (via your termStatusP argument).

   pm_system_lp()
       pm_system_lp()  is  like pm_system() except that instead of running a shell, which in turn typically runs
       another program, you run a program of your choice directly.

       Argument progName identifies the program to run, the same way as with execlp() or a shell command: if  it
       contains a slash (/), it is the full name of the file that contains the program.  If not, it is a name to
       be looked up in the system's program search path (determined by the PATH environment variable).

       You identify the arguments to the program the same way as for execlp(): with the  variable  arguments  at
       the end of the pm_system_lp() argument list.  Each is a NUL-terminated string.  The last argument must be
       NULL to tell pm_system_lp() where the arguments end.

       Note that the first argument ("arg0") to a program is conventionally the first word of the  command  used
       to  run  the program, as if it were being run for a shell command.  In other words, typically the name of
       the program.

       Example:

           pm_system_lp("pnmtojpeg", NULL, NULL, NULL, NULL,
                        "pnmtojpeg", "mypicture.jpg", "-quality=50", NULL);

       pm_system_lp() is much safer than pm_system() when your program computes the arguments or gets them  from
       a  user.  If you build a shell command using such arguments, unless you're really careful, you may end up
       building a shell command that does something very different from what you intended, because the  argument
       could contain characters that mean something to the shell such as "|".

       pm_system_lp()  can also be considerably faster that pm_system(), since it skips the whole running of the
       shell.

       If the process fails, i.e. produces nonzero termination  status,  pm_system_lp  calls  pm_error(),  which
       normally  issues  an  error  message to Standard Error and exits the program.  Use pm_system2_lp() if you
       don't want that.

   pm_system2_lp()
       This is the same as pm_system_lp() except that rather than respond to the process' termination status, it
       just returns it to you (via your termStatusP argument).

   pm_system_vp()
       pm_system_vp()  is like pm_system_lp() except that instead of supplying the program arguments as variable
       arguments, you supply them as an array, as with execvp().  A NULL element in the array identifies the end
       of the arguments.

       Example:

           const char * argArray[3];

           argArray[0] = "pnmtojpeg";
           argArray[1] = "-quality=50";
           argArray[2] = NULL;

           pm_system_vp("pnmtojpeg", argArray, NULL, NULL, NULL, NULL);

       If  the  process  fails,  i.e.  produces nonzero termination status, pm_system_vp calls pm_error(), which
       normally issues an error message to Standard Error and exits the program.   Use  pm_system2_vp()  if  you
       don't want that.

   pm_system2_vp()
       This is the same as pm_system_vp() except that rather than respond to the process' termination status, it
       just returns it to you (via your termStatusP argument).

Applications

       The point of pm_system() and friends is to allow you to write  a  C  program  that  uses  other  programs
       internally, as a shell script would.  This is particularly desirable with Netpbm, because Netpbm consists
       of a lot of programs that perform basic graphic manipulations and you'd  like  to  be  able  to  build  a
       program  that  does  a more sophisticated graphic manipulation by calling the more basic Netpbm programs.
       These building block programs typically take input from Standard  Input  and  write  output  to  Standard
       Output.

       The  obvious  alternative  is  to  use a higher level language -- Bourne Shell or Perl, for example.  But
       often you want your program to do manipulations of your graphical data that are easier and more efficient
       in  C.   Or you want to use the Netpbm subroutine library in your program.  The Netpbm subroutine library
       is a C-linkage library; the subroutines in it are not usable from a Bourne Shell or Perl program.

       A typical use of pm_system() is to place the contents of some graphical  image  file  in  memory,  run  a
       Netpbm  program  against  it,  and  have  what would ordinarily go into an output file in memory too, for
       further processing.  To do that, you can use the memory buffer Standard Input feeder and Standard  Output
       accepter described below.

       If your program uses the Netpbm subroutine library to read, write, and manipulate images, you may have an
       image in an array of PAM tuples.  If you want to manipulate that image with  a  Netpbm  program  (perhaps
       remap  the  colors  using  pnmremap),  you can use the pamtuple Standard Input feeder and Standard Output
       acceptor described below.

Broken Pipe Behavior

       When you set up a shell command to take input from a pipe, as  you  do  with  pm_system(),  you  need  to
       understand  how  pipes  work  with respect to the programs at either end of the pipe agreeing to how much
       data is to be transferred.  Here are some notes on that.

       It is normal to read a pipe before the process on the other end has written the data you  hope  to  read,
       and  it  is  normal  to  write to a pipe before the process on the other end has tried to read your data.
       Writes to a pipe can be buffered until the reading end requests the data.  A process reading or writing a
       pipe can block until the other end is ready.  Or a read or write can complete with an indication that the
       other end is not ready at the moment and therefore  no  data,  or  less  data  than  was  requested,  was
       transferred.

       The  pipe  is  normally controlled by the writing end.  When you read from a pipe, you keep reading until
       the program on the other end of the pipe closes it, and then you get an end-of-file indication.  You then
       normally close the reading end of the pipe, since it is no longer useful.

       When  you  close  the  reading  end  of  a  pipe before getting the end-of-file indication and the writer
       subsequently tries to write to the pipe, that is an error condition for the writer.  In a typical default
       Unix  environment,  that  error  causes the writer to receive a SIGPIPE signal and that signal causes the
       writer process to terminate abnormally.  But if, alternatively, the writer has ordered  that  SIGPIPE  be
       blocked,  ignored,  or  handled,  the  signal does not cause the death of the writer.  Instead, the write
       operation simply completes with an error indication.

Standard Feeders And Acceptors

       You can supply anything you like as a Standard Input feeder or Standard Output acceptor, but  the  Netpbm
       subroutine library comes with a few that perform commonly needed functions.

   Memory Buffer
       These  routines  are  for  when you just want to treat an area of memory as a file.  If the shell command
       would ordinarily read a 513 byte regular file from its Standard Input, you want it to take 513 bytes from
       a certain address in your process' memory.  Whatever bytes the shell command wants to write to its output
       file you want it to store at another address in your process' memory.

       The Standard Input feeder for this is  called  pm_feed_from_memory.   The  Standard  Output  accepter  is
       pm_accept_to_memory.

       For both of these, the argument is a pointer to a struct bufferDesc, which is defined as follows:

       struct bufferDesc {
           unsigned int    size;
           unsigned char * buffer;
           unsigned int *  bytesTransferredP;
       };

       size is the size of the memory buffer and buffer is its location in memory (address).  The Standard Input
       feeder will attempt to feed the entire buffer to the shell command's Standard Input; the Standard  Output
       accepter  will  not  accept  any  more data from the shell command's Standard Output than will fit in the
       buffer.  Both return the actual amount of data read or written, in bytes, at the location  identified  by
       bytesTransferredP.  Unless bytesTransferredP is NULL.

       Because  a process typically terminates abnormally when it is not able to write everything to a pipe that
       it wanted to, bytesTransferredP is not usually useful in the Standard Input feeder case.

   File Stream
       These routines are for using an actual file as input or output.
         I.e. Standard Input comes from a file and Standard Output goes to a file.
         You open the file and create a libc file stream (type FILE) from it and pass
         that stream object to the standard input feeder or standard output accepter.

       When you do this (using output as an example), your process writes to
         Standard Output, which is a pipe, the standard output accepter then reads
         from that pipe into a buffer, and then the standard output accepter writes
         from that buffer to your file.  You could alternatively just arrange for the
         Standard Input or Output of your process to be the file and skip a copy, but
         it might be more complex coding.

       Note that if the calling program's Standard Output is already set up
         as the file to which you want your process' output to go, you
         don't need this.  All you have to do is decline to specify a Standard
         Output accepter (use NULL in place of the Standard Output accepter pointer)
         and your process' output will go there.

       The Standard Input feeder for this is called pm_feed_from_filestream.  The Standard  Output  accepter  is
       pm_accept_to_filestream.

       For both of these, the argument is a pointer to a Standard C library
         FILE object.

       Example:

             int termStatus;
             FILE * myFileP;
             myFileP = fopen('tmp/myfile', 'r');
             pm_system2(pm_feed_from_filestream, myFileP,
                        NULL, NULL,
                        'grep myword', &termstatus);

       These routines were new in Netpbm 11.05 (December 2023).

   Pamtuple
       These  routines  are  for when you have images in memory in the data structures used by the PAM family of
       subroutines in the Netpbm library -- i.e. struct PAM and an array of struct tuple.  With these  routines,
       you  can run a Netpbm program against such an image just as you would against the same image in a regular
       file.

       The Standard Input feeder for this is called pm_feed_from_pamtuples.  The  Standard  Output  accepter  is
       pm_accept_to_pamtuples.

       For both of these, the argument is the address of a struct pamtuples, which is defined as follows:

       struct pamtuples {
           struct pam * pamP;
           tuple ***    tuplesP;
       };

       For the Standard Input feeder, you supply a struct pam, valid up through the tuple_type member (except it
       doesn't matter what the file member is) and array of tuples.

       For the Standard Output Accepter, you supply only space in memory for the struct pam and the  address  of
       the tuple array.  The routine fills in the struct pam up through the tuple_type member (except leaves the
       file member undefined) and allocates space for the tuple array with malloc().  You  are  responsible  for
       freeing that memory.

HISTORY

       pm_system() was introduced in Netpbm 10.13 (January 2003).

       pm_system_lp() and pm_system_vp() were introduced in Netpbm 10.40 (September 2007).

       pm_system2(), pm_system2_lp(), and pm_system2_vp() were introduce in Netpbm 10.75 (June 2016).

DOCUMENT SOURCE

       This  manual  page was generated by the Netpbm tool 'makeman' from HTML source.  The master documentation
       is at

              http://netpbm.sourceforge.net/doc/libsystem.html

netpbm documentation                               12 Netpbm1subroutine library: pm_system() subroutine, etc.(3)