SCO-Linux portability for 4GL

Specifically, the call to a printer. I am porting a number of programs, many of which are reports, from out long standing SCO 4GL application. The only significant change I need to make is for the call to the printer; ie start report to pipe "lp -d" printer_name. On Linux (RedHat5.2) this call needs to be lpr -P. Rather than maintain two versions I would like to use a switch. So, I'm asking for suggestions on preferred methods of determining what particular system the application is running on. I'm aware that I could signal this with fgl_getenv("SOME_VARIABLE_FOR_SYSTEM_NAME") but would prefer to avoid additional arbitrary environmental variables if at all possible. Thanks -- --------------------------------------------------------------------- Scott Holmes http://www.pacificnet.net/~sholmes -Run Linux- sholmes@pacificnet.net Database Programmer/Analyst Passport 4GL HTML Composer Informix 4GL, SQL --------------------------------------------------------------------- There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy ---------------------------------------------------------------------

If you are willing to launch your program with command line arguements, you could use NUM_ARGS() and ARG_VAL() to set a global variable within you code to designate the OS and/or the print command. Also, you could use RUN with RETURNING to 'cat' or 'find' a file unique to either Linux or SCO. A non-zero return value will tell the tale. Scott Holmes wrote: > Specifically, the call to a printer. I am porting a number of programs, many > of which are reports, from out long standing SCO 4GL application. The only > significant change I need to make is for the call to the printer; ie start > report to pipe "lp -d" printer_name. On Linux (RedHat5.2) this call needs to > be lpr -P. Rather than maintain two versions I would like to use a switch. > > So, I'm asking for suggestions on preferred methods of determining what > particular system the application is running on. I'm aware that I could > signal this with fgl_getenv("SOME_VARIABLE_FOR_SYSTEM_NAME") but would prefer > to avoid additional arbitrary environmental variables if at all possible. > > Thanks > > -- > --------------------------------------------------------------------- > Scott Holmes http://www.pacificnet.net/~sholmes > -Run Linux- sholmes@pacificnet.net > > Database Programmer/Analyst Passport 4GL > HTML Composer Informix 4GL, SQL > --------------------------------------------------------------------- > There are more things in heaven and earth, Horatio, > than are dreamt of in your philosophy > --------------------------------------------------------------------- > >

He could pass in the output of uname(1). I believe uname(1) exists on all UNIX variants. For example the output of uname(1) on AIX is "AIX", and on Solaris is "SunOs". I don't have a SCO system available, but I suspect the output of uname(1) on SCO would be distinct too. The minimalistic command line would be: $ pgm `uname` I'm guessing that simpler solutions than uname(1) exists, but this works. Larry Benoit wrote: > If you are willing to launch your program with command line arguements, you could > use NUM_ARGS() and ARG_VAL() to set a global variable within you code to > designate the OS and/or the print command. > > Also, you could use RUN with RETURNING to 'cat' or 'find' a file unique to either > Linux or SCO. A non-zero return value will tell the tale. > > Scott Holmes wrote: > > > Specifically, the call to a printer. I am porting a number of programs, many > > of which are reports, from out long standing SCO 4GL application. The only > > significant change I need to make is for the call to the printer; ie start > > report to pipe "lp -d" printer_name. On Linux (RedHat5.2) this call needs to > > be lpr -P. Rather than maintain two versions I would like to use a switch. > > > > So, I'm asking for suggestions on preferred methods of determining what > > particular system the application is running on. I'm aware that I could > > signal this with fgl_getenv("SOME_VARIABLE_FOR_SYSTEM_NAME") but would prefer > > to avoid additional arbitrary environmental variables if at all possible. > > > > Thanks > > > > -- > > --------------------------------------------------------------------- > > Scott Holmes http://www.pacificnet.net/~sholmes > > -Run Linux- sholmes@pacificnet.net > > > > Database Programmer/Analyst Passport 4GL > > HTML Composer Informix 4GL, SQL > > --------------------------------------------------------------------- > > There are more things in heaven and earth, Horatio, > > than are dreamt of in your philosophy > > --------------------------------------------------------------------- > > > >

On SCO Openserver 5.0.x, uname returns SCO_SV On Sun, 25 Apr 1999 10:12:07 -0400, Vic Glass <icc@injersey.infi.net> wrote: >He could pass in the output of uname(1). I believe uname(1) exists on all UNIX >variants. For example the output of uname(1) on AIX is "AIX", and on Solaris is >"SunOs". I don't have a SCO system available, but I suspect the output of uname(1) on >SCO would be distinct too. The minimalistic command line would be: > $ pgm `uname`

Scott Holmes wrote: > > Specifically, the call to a printer. I am porting a number of programs, many > of which are reports, from out long standing SCO 4GL application. The only > significant change I need to make is for the call to the printer; ie start > report to pipe "lp -d" printer_name. On Linux (RedHat5.2) this call needs to > be lpr -P. Rather than maintain two versions I would like to use a switch. > > So, I'm asking for suggestions on preferred methods of determining what > particular system the application is running on. I'm aware that I could > signal this with fgl_getenv("SOME_VARIABLE_FOR_SYSTEM_NAME") but would prefer > to avoid additional arbitrary environmental variables if at all possible. All of the other replies make good suggestions about how to do what you say you need to do. However, you ask for the "preferred" method so I am adding my $0.02. In 4GL the preferred method to send a report to the printer is: REPORT TO PRINTER rather than REPORT TO PIPE "lpr -P.." Then the choice of printer pipe is determined by the DBPRINT environment variable: DBPRINT="lpr -P mylaserjet"; export DBPRINT Art S. Kagel