Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #14359 > unrolled thread

How do you access the printer in Linux/C?

Back to article view | Back to comp.os.linux.misc

Contents

  How do you access the printer in Linux/C? pureheart@pacbell.net - 2015-04-06 17:07 -0700
    Re: How do you access the printer in Linux/C? Tim Watts <tw_usenet@dionic.net> - 2015-04-07 04:23 +0100
      Re: How do you access the printer in Linux/C? The Natural Philosopher <tnp@invalid.invalid> - 2015-04-07 05:46 +0100
      Re: How do you access the printer in Linux/C? floyd@apaflo.com (Floyd L. Davidson) - 2015-04-07 02:16 -0800
        Re: How do you access the printer in Linux/C? Tim Watts <tw_usenet@dionic.net> - 2015-04-07 11:30 +0100
          Re: How do you access the printer in Linux/C? The Natural Philosopher <tnp@invalid.invalid> - 2015-04-07 11:51 +0100
            Re: How do you access the printer in Linux/C? floyd@apaflo.com (Floyd L. Davidson) - 2015-04-07 03:11 -0800
              Re: How do you access the printer in Linux/C? The Natural Philosopher <tnp@invalid.invalid> - 2015-04-07 12:37 +0100
                Re: How do you access the printer in Linux/C? pureheart@pacbell.net - 2015-04-07 08:31 -0700
            Re: How do you access the printer in Linux/C? Tim Watts <tw_usenet@dionic.net> - 2015-04-07 12:24 +0100
          Re: How do you access the printer in Linux/C? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-04-07 16:26 +0000
        Re: How do you access the printer in Linux/C? The Natural Philosopher <tnp@invalid.invalid> - 2015-04-07 11:46 +0100
        Re: How do you access the printer in Linux/C? Unknown <dog@gmail.com> - 2015-05-06 08:50 +0000
          Re: How do you access the printer in Linux/C? Joe Beanfish <joebeanfish@nospam.duh> - 2015-05-06 13:36 +0000
            Re: How do you access the printer in Linux/C? Unknown <dog@gmail.com> - 2015-05-08 10:44 +0000
              Re: How do you access the printer in Linux/C? Joe Beanfish <joebeanfish@nospam.duh> - 2015-05-08 13:51 +0000
                Re: How do you access the printer in Linux/C? William Unruh <unruh@invalid.ca> - 2015-05-08 14:58 +0000
                  Re: How do you access the printer in Linux/C? Joe Beanfish <joebeanfish@nospam.duh> - 2015-05-11 13:24 +0000
                    Re: How do you access the printer in Linux/C? Robert Heller <heller@deepsoft.com> - 2015-05-11 14:40 -0500
              Re: How do you access the printer in Linux/C? William Unruh <unruh@invalid.ca> - 2015-05-08 14:55 +0000
    Re: How do you access the printer in Linux/C? The Natural Philosopher <tnp@invalid.invalid> - 2015-04-07 05:43 +0100
    Re: How do you access the printer in Linux/C? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-04-07 12:15 -0400
      Re: How do you access the printer in Linux/C? pureheart@pacbell.net - 2015-04-09 15:39 -0700

Page 1 of 2  [1] 2  Next page →

#14359 — How do you access the printer in Linux/C?

Might really be a programming question.

Back in my CBASIC days, the command LPRINTER would cause all PRINT statemets to be directed to the printer (LPT:) until you issued the command CONSOLE to return it to the screen (CON:).

When I wrote a simple envelope printing program when I changed over from CP/M to Linux (no MS in this house) I could not find how to do that with standard 'C'.

I ended up writing my input to a file and then calling 'mpage | lpr" with the system command. 

Works fine, but, tell me, how to I get to the printer w/o going throuph LP(R) in some way?

Pureheart in Aptos

Here's the whole thing.......

PS: I know I'm not supposed to use "gets", but it's for home use and just me, so I did.

#include <stdio.h>
#include <stdlib.h>

void hello();
void set_padding(int argc, char *argv[]);
void open_output_file(FILE *output);
int  TRUE = -1;
int  print_legal;

/* global variables */
    char name1[80], name2[80], address[80], city_state_zip[80];
    char *reset = "\x1b\x45";
/*    char *18_point-type = "\x1b\x28\x73"18"\x56";  */

/* rows down needed = 29 */
int rows_down = 29;
int lines_between_return_and_address = 11;

char *padding; 
/* 42 char for standard padding */
char standard_padding[] = "                                     ";

/* and currently 56 for the legal envelope */
char  legal_padding[] = "                                                        ";
char  c;

/*---------------------------------------------------------------------*/
main(argc, argv)
int      argc;
char  *argv[];
{
  /*variables, whatnot */
  FILE	*output;
  int	i;
  
  hello();
  set_padding(argc, argv);  

  /* okay, he didn't quit. Open the file */
  output = fopen("envelope_output_file", "w");
  if ( output == (FILE *) NULL ) {
        printf("Dang! Could not open file, \'envelope_output_file\' for writing.\n");
        exit(0);
  }
  
  printf("           Name1: ");
  gets( name1 );
  if (strlen(name1) == 0) {
    exit(0);
    }
  
  printf("           Name2: ");
  gets( name2 );
  printf("         Address: ");
  gets( address );
  printf("City, State, ZIP: ");  
  gets( city_state_zip );
  
  
  printf("\n\n");
  printf("Okay, I\'m going to print:\n\n");
  printf("                  %s\n", name1);
  
  if (strlen( name2 ) != 0 ) {
  printf("                  %s\n", name2);
  }
  printf("                  %s\n", address);
  printf("                  %s\n", city_state_zip);
  
  if (print_legal == TRUE) {
      printf("\n                   On a LEGAL sized envelope.\n");
  }

  printf("\n     OK?  Press Q to quit, any other key to proceed...");
  if (toupper( getchar() )  == 'Q' ) {
    fclose( output );
    exit(0);
    /* why bother writing the file if he's not going to print it? */
  }
  
  /* okay, we're here...write out the envelope */
  /* space down to the beginning.... */
  for (i=0; i< rows_down; i++) {
    fprintf(output, "\n");
  }
  
  /* first the return address.... */  
  fprintf(output, "Dave \'Pureheart\' Steinbruner\n");
  fprintf(output, "3441 Redwood Drive\n");
  fprintf(output, "Aptos, CA  95003\n");

/* now space down to the addressee  */
  for (i=0; i< lines_between_return_and_address; i++) {
    fprintf(output, "\n");
  }  

/* now write the addressee */  
  fprintf(output,   "%s%s\n", padding, name1);
  if (strlen (name2)!= 0 ) {
    fprintf(output, "%s%s\n", padding, name2);
  }
  fprintf(output,   "%s%s\n", padding, address);
  fprintf(output,   "%s%s\n", padding, city_state_zip);
  
/* we're done....close the file and good-bye */
fclose(output);

  /* we will then call mpage -1lo test_envelope | lpr to print
     the file in our script file */
while (TRUE) {
  system( "mpage -1 -l -o envelope_output_file | lpr"); 
  printf("\nPrint another? (Y/N) ");
  if (toupper(getchar()  ) != 'Y') break;
  getchar();     /* consume the <CR> */
  printf("\n\n");
}

/* get rid of the file before we exit... */
unlink("envelope_output_file");
  
}  /* of main */
/*--------------------------------------------------------------------*/

/*--------------------------------------------------------------------*/
void hello() 
{
  /* clear the screen.... */
  system("clear");

  printf("                               ENVELOPE <legal>\n");
  printf("This program prints envelopes on the Hewlett Packard Inkjet Printer.\n");
  printf("(Entering \"legal\", or just \'l\' will cause it to expect a legal sized envelope.)\n");
  printf("------------------------------------------------------------------------------\n\n");
  printf("Press <CR> on first line to quit.....\n\n");  
}
/*-------------------------------------------------------------------/*---------------------------------------------------------------------*/

void set_padding(argc, argv)
int     argc;
char *argv[];
{
  /* let's set the padding */
  if (argc > 1) {
    c = tolower( *argv[1] );
    if ( c == 'l') {
       padding = legal_padding;
       print_legal = TRUE;
    }
  }
  else {
    padding = standard_padding;
    print_legal = 0;
  }
}
/*---------------------------------------------------------------------*/

[toc] | [next] | [standalone]

#14363

On 07/04/15 01:07, pureheart@pacbell.net wrote:
> Might really be a programming question.

It's more of an OS question.

The general answer to "without going through lpr" is "don't try".

Printers may be presented in a dozen different ways and speak one of 
several languages and dialects.

eg:

you could have a directly attached serial printer on /dev/ttyS? or a 
centronics printer on /dev/lp? or a USB printer on /dev/somerandomname

All of these you could at least fopen() and fprintf() to.

Then you have networked attached printers that could speak (usually over 
TCP) raw-bytes-stream, lpd protocol, ipp protocol or others.

In all cases the printer might accept ACSII and do something reasonable.

It might understand postscript or ESC/P or some other funky language.


Personally, if you must, then generate postscript, as most print 
subsystems (eg CUPS) will be able to interpret that even if the printer 
can't.

You might as well also go for the traditional unix way and just shove 
your output to STDOUT and let the user pipe it to the print clien tof 
choice, which might be lp or gtklp or a load of other possibles.


The print subsystems (either CUPS or even LPRng) do a way better job of 
driving printers than any one man could ever hope to achieve - the nasty 
stuff is best left to them.


Unless you have a very special embedded system with a fixed type of 
printer and cannot afford to have  afull print daemon running?

[toc] | [prev] | [next] | [standalone]

#14367

On 07/04/15 04:23, Tim Watts wrote:
> On 07/04/15 01:07, pureheart@pacbell.net wrote:
>> Might really be a programming question.
>
> It's more of an OS question.
>
> The general answer to "without going through lpr" is "don't try".
>
> Printers may be presented in a dozen different ways and speak one of
> several languages and dialects.
>
> eg:
>
> you could have a directly attached serial printer on /dev/ttyS? or a
> centronics printer on /dev/lp? or a USB printer on /dev/somerandomname
>
> All of these you could at least fopen() and fprintf() to.
>
> Then you have networked attached printers that could speak (usually over
> TCP) raw-bytes-stream, lpd protocol, ipp protocol or others.
>
> In all cases the printer might accept ACSII and do something reasonable.
>
> It might understand postscript or ESC/P or some other funky language.
>
>
> Personally, if you must, then generate postscript, as most print
> subsystems (eg CUPS) will be able to interpret that even if the printer
> can't.
>
> You might as well also go for the traditional unix way and just shove
> your output to STDOUT and let the user pipe it to the print clien tof
> choice, which might be lp or gtklp or a load of other possibles.
>
>
> The print subsystems (either CUPS or even LPRng) do a way better job of
> driving printers than any one man could ever hope to achieve - the nasty
> stuff is best left to them.
>
>
> Unless you have a very special embedded system with a fixed type of
> printer and cannot afford to have  afull print daemon running?
>
well most of te stuiff is done not by lp/lpr but by cupsd IIRC so a C 
interface to THAT is possbile

I definitely echo the thought of writing a PDF or PS output for it. I 
have used PDFliblite libraries for pretty decent outputs - formatted 
letterhead invoices and the like


-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[toc] | [prev] | [next] | [standalone]

#14372

Tim Watts <tw_usenet@dionic.net> wrote:
>On 07/04/15 01:07, pureheart@pacbell.net wrote:
>> Might really be a programming question.
>
>It's more of an OS question.
>
>The general answer to "without going through lpr" is "don't try".

That needs to be emphasised.  It should say:

  *"Don't even think about it!  Ever!"*

CUPS, or another print spooler, is there for a good
reason, and normal users on a multi-user multi-tasking
system should never directly access hardware such as a
printer.

Piping a file into lp or lpr using system() is one way,
and it works relatively well.  Using popen() to access
the spooler, and then fprint() to send it the data
without writing it to a file, is a much better way.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#14373

On 07/04/15 11:16, Floyd L. Davidson wrote:
> Tim Watts <tw_usenet@dionic.net> wrote:
>> On 07/04/15 01:07, pureheart@pacbell.net wrote:
>>> Might really be a programming question.
>>
>> It's more of an OS question.
>>
>> The general answer to "without going through lpr" is "don't try".
>
> That needs to be emphasised.  It should say:
>
>    *"Don't even think about it!  Ever!"*
>
> CUPS, or another print spooler, is there for a good
> reason, and normal users on a multi-user multi-tasking
> system should never directly access hardware such as a
> printer.
>
> Piping a file into lp or lpr using system() is one way,
> and it works relatively well.  Using popen() to access
> the spooler, and then fprint() to send it the data
> without writing it to a file, is a much better way.
>

I don't know how old the OP is, but it's also worth recalling the days 
of MS-DOS when the "OS" (and I use the term loosely) had no concept of a 
printer beyond presenting a raw character IO type device.

Every application had to have its own bundle of print drivers and it was 
a right PITA if one app did know know about a particular printer.

I'm with you totally in that noone should ever try to replicate that!

[toc] | [prev] | [next] | [standalone]

#14375

On 07/04/15 11:30, Tim Watts wrote:
> On 07/04/15 11:16, Floyd L. Davidson wrote:
>> Tim Watts <tw_usenet@dionic.net> wrote:
>>> On 07/04/15 01:07, pureheart@pacbell.net wrote:
>>>> Might really be a programming question.
>>>
>>> It's more of an OS question.
>>>
>>> The general answer to "without going through lpr" is "don't try".
>>
>> That needs to be emphasised.  It should say:
>>
>>    *"Don't even think about it!  Ever!"*
>>
>> CUPS, or another print spooler, is there for a good
>> reason, and normal users on a multi-user multi-tasking
>> system should never directly access hardware such as a
>> printer.
>>
>> Piping a file into lp or lpr using system() is one way,
>> and it works relatively well.  Using popen() to access
>> the spooler, and then fprint() to send it the data
>> without writing it to a file, is a much better way.
>>
>
> I don't know how old the OP is, but it's also worth recalling the days
> of MS-DOS when the "OS" (and I use the term loosely) had no concept of a
> printer beyond presenting a raw character IO type device.
>
> Every application had to have its own bundle of print drivers and it was
> a right PITA if one app did know know about a particular printer.
>
> I'm with you totally in that noone should ever try to replicate that!

I think we all agree on that, the more relevant question is at what 
level should the programmer tap into the whole cups process?

The quickest and simplest is to write the file to stdout or a tmp 
location and invoke a system() type call to handle it as a separate process.

Next up from that is to write the file and use the cups API to print it 
with no system call needed.

Finally you can hack the CUPS source to write to a socket connected 
CUPSD directly without needing an intermediate file.



-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[toc] | [prev] | [next] | [standalone]

#14376

The Natural Philosopher <tnp@invalid.invalid> wrote:
>The quickest and simplest is to write the file to stdout
>or a tmp location and invoke a system() type call to
>handle it as a separate process.
>
>Next up from that is to write the file and use the cups
>API to print it with no system call needed.

That is over complicating it by quite a bit.

The next step up from system() is using popen(),
which does not require that a file be written
to disk, but otherwise is essentially the exact same
interface.

>Finally you can hack the CUPS source to write to a
>socket connected CUPSD directly without needing an
>intermediate file.

That's getting rediculous.  Same with using the
API.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#14378

On 07/04/15 12:11, Floyd L. Davidson wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> The quickest and simplest is to write the file to stdout
>> or a tmp location and invoke a system() type call to
>> handle it as a separate process.
>>
>> Next up from that is to write the file and use the cups
>> API to print it with no system call needed.
>
> That is over complicating it by quite a bit.
>
> The next step up from system() is using popen(),
> which does not require that a file be written
> to disk, but otherwise is essentially the exact same
> interface.
>
>> Finally you can hack the CUPS source to write to a
>> socket connected CUPSD directly without needing an
>> intermediate file.
>
> That's getting rediculous.  Same with using the
> API.
>
Why?

It all depends on the context, and we don't know what the context is.

I've certainly raided and adapted UNZIP source to avoid invoking a 
process from a background daemon, for example.


-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[toc] | [prev] | [next] | [standalone]

#14379

On Tuesday, April 7, 2015 at 4:37:26 AM UTC-7, The Natural Philosopher wrote:
> On 07/04/15 12:11, Floyd L. Davidson wrote:
> > The Natural Philosopher  wrote:
> >> The quickest and simplest is to write the file to stdout
> >> or a tmp location and invoke a system() type call to
> >> handle it as a separate process.
> >>
> >> Next up from that is to write the file and use the cups
> >> API to print it with no system call needed.
> >
> > That is over complicating it by quite a bit.
> >
> > The next step up from system() is using popen(),
> > which does not require that a file be written
> > to disk, but otherwise is essentially the exact same
> > interface.
> >
> >> Finally you can hack the CUPS source to write to a
> >> socket connected CUPSD directly without needing an
> >> intermediate file.
> >
> > That's getting rediculous.  Same with using the
> > API.
> >
> Why?
> 
> It all depends on the context, and we don't know what the context is.
> 
> I've certainly raided and adapted UNZIP source to avoid invoking a 
> process from a background daemon, for example.
> 
> 

Thanks to all for the great information in this thread.  Especially to the Natural Philosopher for the CUPS example, Floyd D. for the good ground rules of good procedure (in his first post/reply) and Tim for giving me the scoop on the Unix way.  eg: repiping STDOUT to the LPR.

I felt I was really missing something in that I had to waste all the overhead of making a file etc. etc.  Now I don't feel so bad.

I'll read up on the CUPS example...it would be nice to have larger font for the Addressee and smaller font for the return address, etc.

I date back to when CP/M first came along and 64K Z80A 4MHz boxes were king.
That's why I still use Joe in it's WordStar cloning version for my text editing.

Thanks for the great replies, gang.

Pureheart in Aptos

[toc] | [prev] | [next] | [standalone]

#14377

On 07/04/15 11:51, The Natural Philosopher wrote:
> On 07/04/15 11:30, Tim Watts wrote:

>> I don't know how old the OP is, but it's also worth recalling the days
>> of MS-DOS when the "OS" (and I use the term loosely) had no concept of a
>> printer beyond presenting a raw character IO type device.
>>
>> Every application had to have its own bundle of print drivers and it was
>> a right PITA if one app did know know about a particular printer.
>>
>> I'm with you totally in that noone should ever try to replicate that!
>
> I think we all agree on that, the more relevant question is at what
> level should the programmer tap into the whole cups process?

On a side note I find it hugely ironic that Android (at least pre 
Kitkat) did not bother with a printing subsystem either - and neither do 
the apps. So you have a huge kludge of installing a random app that 
knows about your printer and understands some random subset of document 
formats.


> The quickest and simplest is to write the file to stdout or a tmp
> location and invoke a system() type call to handle it as a separate
> process.

Personally, I'd stick with this - it's the unix way and it makes it 
possible to specify the spawned command (and optionally args) in a 
config file.

> Next up from that is to write the file and use the cups API to print it
> with no system call needed.
>
> Finally you can hack the CUPS source to write to a socket connected
> CUPSD directly without needing an intermediate file.

[toc] | [prev] | [next] | [standalone]

#14383

On 2015-04-07, Tim Watts <tw_usenet@dionic.net> wrote:

> I don't know how old the OP is, but it's also worth recalling the days 
> of MS-DOS when the "OS" (and I use the term loosely) had no concept of a 
> printer beyond presenting a raw character IO type device.

And thanks to that, Windows text files to this day use CRLF as
a record terminator.  It probably explains the TCP/IP convention
as well.  (That dreadful 0x1a file terminator goes back to CP/M;
it should never have been brought forward into file systems that
store the file's exact length in bytes.)

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

[toc] | [prev] | [next] | [standalone]

#14374

On 07/04/15 11:16, Floyd L. Davidson wrote:
> Tim Watts <tw_usenet@dionic.net> wrote:
>> On 07/04/15 01:07, pureheart@pacbell.net wrote:
>>> Might really be a programming question.
>>
>> It's more of an OS question.
>>
>> The general answer to "without going through lpr" is "don't try".
>
> That needs to be emphasised.  It should say:
>
>    *"Don't even think about it!  Ever!"*
>
> CUPS, or another print spooler, is there for a good
> reason, and normal users on a multi-user multi-tasking
> system should never directly access hardware such as a
> printer.
>
> Piping a file into lp or lpr using system() is one way,
> and it works relatively well.  Using popen() to access
> the spooler, and then fprint() to send it the data
> without writing it to a file, is a much better way.
>

There is a perfectly good CUPS API if you want to be economical with 
process space.


http://www.cups.org/doc-1.1/spm.html#3_2_2

This still requires an intermediate file to be constructed however.

If you really dont want that,. this is the source of  part of the cups 
library that actually sends data to a cups socket after getting it from 
a file. It could send data from memory as well if adapted...

 From file util.c in the cups source package

I don't have time to go through it in detail, but it looks not a 
massively hard job to spool a print job from an in-memory constructed 
byte stream with no other process called except a socket level 
connection to cupsd.

Of course if you dont want to run CUPS at all, that's a whole new ball 
game...



int					/* O - Job ID or 0 on error */
cupsPrintFiles2(
     http_t        *http,		/* I - Connection to server or @code 
CUPS_HTTP_DEFAULT@ */
     const char    *name,		/* I - Destination name */
     int           num_files,		/* I - Number of files */
     const char    **files,		/* I - File(s) to print */
     const char    *title,		/* I - Title of job */
     int           num_options,		/* I - Number of options */
     cups_option_t *options)		/* I - Options */
{
   int		i;			/* Looping var */
   int		job_id;			/* New job ID */
   const char	*docname;		/* Basename of current filename */
   const char	*format;		/* Document format */
   cups_file_t	*fp;			/* Current file */
   char		buffer[8192];		/* Copy buffer */
   ssize_t	bytes;			/* Bytes in buffer */
   http_status_t	status;			/* Status of write */
   _cups_globals_t *cg = _cupsGlobals();	/* Global data */
   ipp_status_t	cancel_status;		/* Status code to preserve */
   char		*cancel_message;	/* Error message to preserve */


   DEBUG_printf(("cupsPrintFiles2(http=%p, name=\"%s\", num_files=%d, "
                 "files=%p, title=\"%s\", num_options=%d, options=%p)",
                 http, name, num_files, files, title, num_options, 
options));

  /*
   * Range check input...
   */

   if (!name || num_files < 1 || !files)
   {
     _cupsSetError(IPP_STATUS_ERROR_INTERNAL, strerror(EINVAL), 0);

     return (0);
   }

  /*
   * Create the print job...
   */

   if ((job_id = cupsCreateJob(http, name, title, num_options, options)) 
== 0)
     return (0);

  /*
   * Send each of the files...
   */

   if (cupsGetOption("raw", num_options, options))
     format = CUPS_FORMAT_RAW;
   else if ((format = cupsGetOption("document-format", num_options,
				   options)) == NULL)
     format = CUPS_FORMAT_AUTO;

   for (i = 0; i < num_files; i ++)
   {
    /*
     * Start the next file...
     */

     if ((docname = strrchr(files[i], '/')) != NULL)
       docname ++;
     else
       docname = files[i];

     if ((fp = cupsFileOpen(files[i], "rb")) == NULL)
     {
      /*
       * Unable to open print file, cancel the job and return...
       */

       _cupsSetError(IPP_STATUS_ERROR_DOCUMENT_ACCESS, NULL, 0);
       goto cancel_job;
     }

     status = cupsStartDocument(http, name, job_id, docname, format,
			       i == (num_files - 1));

     while (status == HTTP_STATUS_CONTINUE &&
	   (bytes = cupsFileRead(fp, buffer, sizeof(buffer))) > 0)
       status = cupsWriteRequestData(http, buffer, (size_t)bytes);

     cupsFileClose(fp);

     if (status != HTTP_STATUS_CONTINUE || cupsFinishDocument(http, 
name) != IPP_STATUS_OK)
     {
      /*
       * Unable to queue, cancel the job and return...
       */

       goto cancel_job;
     }
   }

   return (job_id);

  /*
   * If we get here, something happened while sending the print job so 
we need
   * to cancel the job without setting the last error (since we need to 
preserve
   * the current error...
   */

   cancel_job:

   cancel_status  = cg->last_error;
   cancel_message = cg->last_status_message ?
                        _cupsStrRetain(cg->last_status_message) : NULL;

   cupsCancelJob2(http, name, job_id, 0);

   cg->last_error          = cancel_status;
   cg->last_status_message = cancel_message;

   return (0);
}


-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[toc] | [prev] | [next] | [standalone]

#14718

On Tue, 07 Apr 2015 02:16:56 -0800, Floyd L. Davidson wrote:

> Tim Watts <tw_usenet@dionic.net> wrote:
>>On 07/04/15 01:07, pureheart@pacbell.net wrote:
>>> Might really be a programming question.
>>
>>It's more of an OS question.
>>
>>The general answer to "without going through lpr" is "don't try".
> 
> That needs to be emphasised.  It should say:
> 
>   *"Don't even think about it!  Ever!"*
> 
> CUPS, or another print spooler, is there for a good reason, and normal
> users on a multi-user multi-tasking system should never directly access
> hardware such as a printer.
> 
> Piping a file into lp or lpr using system() is one way, and it works
> relatively well.  Using popen() to access the spooler, and then fprint()
> to send it the data without writing it to a file, is a much better way.

If the office M$ system was closed for 2 weeks, and you needed to
desperately print some files from your portable *nix computer via the
office-HP-3055-Laser-Jet, how would you drive the printer via an eth0
cable from your portable?

What's a simple script to probe the printer to find its IP?
Can nc do that?

You've previously always just given your text-files to the M$-user on
 a USBstik, so you've never setup `cups` etc. on a computer, and you want
 to be able to just plug in your ethO cable and call a single script, and
 not need to work at the inconveniently located printer.

How to simplify even further, so that the portable device, that brings the
files to the eth0 connected printer, has no display/kybrd, and is just
programmed to <print when it's powered up>.
No that's not fantacy : it's been playing <the next *.wav> flawlessly, 
when
powered-up 1000 times.

==TIA.

[toc] | [prev] | [next] | [standalone]

#14719

On Wed, 06 May 2015 08:50:56 +0000, Unknown wrote:
> If the office M$ system was closed for 2 weeks, and you needed to
> desperately print some files from your portable *nix computer via the
> office-HP-3055-Laser-Jet, how would you drive the printer via an eth0
> cable from your portable?
> 
> What's a simple script to probe the printer to find its IP?
> Can nc do that?
> 
> You've previously always just given your text-files to the M$-user on
>  a USBstik, so you've never setup `cups` etc. on a computer, and you
>  want to be able to just plug in your ethO cable and call a single
>  script, and not need to work at the inconveniently located printer.
> 
> How to simplify even further, so that the portable device, that brings
> the files to the eth0 connected printer, has no display/kybrd, and is
> just programmed to <print when it's powered up>.
> No that's not fantacy : it's been playing <the next *.wav> flawlessly,
> when powered-up 1000 times.

Well, playing a local sound file through the known/built-in audio device
is not at all the same as probing the entire network for any/all printers,
determining their make/model, and pumping the source document through
the right conversion and driver to send to the printer. You'll be lucky
to find a command-line only solution, much less a blind one. And you're
certainly not going to be develop a solution in isolation and have it
just work when you're at said office. You'll need to develop the procedure
at the office. A couple useful tools might be nmap for discovery and
smbspool for sending data to the printer.

Perhaps a call to the office to at least find out the make and model
of printer would be helpful.

[toc] | [prev] | [next] | [standalone]

#14728

On Wed, 06 May 2015 13:36:45 +0000, Joe Beanfish wrote:

> On Wed, 06 May 2015 08:50:56 +0000, Unknown wrote:
>> If the office M$ system was closed for 2 weeks, and you needed to
>> desperately print some files from your portable *nix computer via the
>> office-HP-3055-Laser-Jet, how would you drive the printer via an eth0
>> cable from your portable?
>> 
>> What's a simple script to probe the printer to find its IP? Can nc do
>> that?
>> 
>> You've previously always just given your text-files to the M$-user on
>>  a USBstik, so you've never setup `cups` etc. on a computer, and you
>>  want to be able to just plug in your ethO cable and call a single
>>  script, and not need to work at the inconveniently located printer.
>> 
>> How to simplify even further, so that the portable device, that brings
>> the files to the eth0 connected printer, has no display/kybrd, and is
>> just programmed to <print when it's powered up>. No that's not fantacy
>> : it's been playing <the next *.wav> flawlessly, when powered-up 1000
>> times.
> 
> Well, playing a local sound file through the known/built-in audio device
> is not at all the same as probing the entire network for any/all
> printers, determining their make/model,

Perhaps a picture will help? Disconnect existing eth0 cable from printer

[rPi in shoe-box with 6V acco]--eth0Cable-->[HP-3055-Laser-Jet]

> and pumping the source document
> through the right conversion and driver to send to the printer. You'll
> be lucky to find a command-line only solution, much less a blind one.
> And you're certainly not going to be develop a solution in isolation and
> have it just work when you're at said office. You'll need to develop the
> procedure at the office. A couple useful tools might be nmap for
> discovery and smbspool for sending data to the printer.
> 
nmap - Network exploration tool and security / port scannersmbspool - 
smbspool - send a print file to an SMB printer

That looks interesting. Thanks.

I've read that a common printer:IP = 192.168.0.9100 [or something]
Does it mess their network if I just unplug their eth0->printer,
and plug rPi to do: ping common Printer IP/s and save results ?

> Perhaps a call to the office to at least find out the make and model of
> printer would be helpful.

That was listed in OP. Think from 1st principles; not ito *YOUR* office.

[toc] | [prev] | [next] | [standalone]

#14735

On Fri, 08 May 2015 10:44:55 +0000, Unknown wrote:

> On Wed, 06 May 2015 13:36:45 +0000, Joe Beanfish wrote:
> 
>> On Wed, 06 May 2015 08:50:56 +0000, Unknown wrote:
>>> If the office M$ system was closed for 2 weeks, and you needed to
>>> desperately print some files from your portable *nix computer via the
>>> office-HP-3055-Laser-Jet, how would you drive the printer via an eth0
>>> cable from your portable?
>>> 
>>> What's a simple script to probe the printer to find its IP? Can nc do
>>> that?
>>> 
>>> You've previously always just given your text-files to the M$-user on
>>>  a USBstik, so you've never setup `cups` etc. on a computer, and you
>>>  want to be able to just plug in your ethO cable and call a single
>>>  script, and not need to work at the inconveniently located printer.
>>> 
>>> How to simplify even further, so that the portable device, that brings
>>> the files to the eth0 connected printer, has no display/kybrd, and is
>>> just programmed to <print when it's powered up>. No that's not fantacy
>>> : it's been playing <the next *.wav> flawlessly, when powered-up 1000
>>> times.
>> 
>> Well, playing a local sound file through the known/built-in audio
>> device is not at all the same as probing the entire network for any/all
>> printers, determining their make/model,
> 
> Perhaps a picture will help? Disconnect existing eth0 cable from printer
> 
> [rPi in shoe-box with 6V acco]--eth0Cable-->[HP-3055-Laser-Jet]

You still need to know/find the IP of the printer. And if it's dhcp
it my try to renew it's lease while you're connected. If that fails
I don't know if it will keep the same ip or drop off the network.

> 
>> and pumping the source document through the right conversion and driver
>> to send to the printer. You'll be lucky to find a command-line only
>> solution, much less a blind one. And you're certainly not going to be
>> develop a solution in isolation and have it just work when you're at
>> said office. You'll need to develop the procedure at the office. A
>> couple useful tools might be nmap for discovery and smbspool for
>> sending data to the printer.
>> 
> nmap - Network exploration tool and security / port scannersmbspool -
> smbspool - send a print file to an SMB printer
> 
> That looks interesting. Thanks.
> 
> I've read that a common printer:IP = 192.168.0.9100 [or something]
> Does it mess their network if I just unplug their eth0->printer,
> and plug rPi to do: ping common Printer IP/s and save results ?

That IP is wrong. The "9100" you've seen before is a port number used
by hp printers' "jetdirect" protocol (possibly others?). It looks like
you can send a byte stream directly to that to printer using nc.

http://danieru.com/2013/06/06/what-is-port-9100-how-to-print-to-it/

I just tried it. Seems to work for plain text files. But be sure your
files have CR+LF not just LF as most *nix files will have.

sed 's/$/\x0d/' <YOUR_TEXT_FILE|nc 192.168.x.y 9100

Also, it looks like you'll have to insert form feeds, \x0c or ^L, as
needed. My test dropped everything that didn't fit on the page. So add
a form feed after 60 lines, or whatever fits on whatever size paper
you have (I have US letter size). 

> 
>> Perhaps a call to the office to at least find out the make and model of
>> printer would be helpful.
> 
> That was listed in OP. Think from 1st principles; not ito *YOUR* office.

Oops, my bad. My office uses "dvihp" to convert latex dvi files for
a laserjet 4050. I think that still relies on lpr to actually send
the data to the printer.

[toc] | [prev] | [next] | [standalone]

#14741

On 2015-05-08, Joe Beanfish <joebeanfish@nospam.duh> wrote:
> On Fri, 08 May 2015 10:44:55 +0000, Unknown wrote:
>
>> On Wed, 06 May 2015 13:36:45 +0000, Joe Beanfish wrote:
>> 
>>> On Wed, 06 May 2015 08:50:56 +0000, Unknown wrote:
>>>> If the office M$ system was closed for 2 weeks, and you needed to
>>>> desperately print some files from your portable *nix computer via the
>>>> office-HP-3055-Laser-Jet, how would you drive the printer via an eth0
>>>> cable from your portable?
>>>> 
>>>> What's a simple script to probe the printer to find its IP? Can nc do
>>>> that?
>>>> 
>>>> You've previously always just given your text-files to the M$-user on
>>>>  a USBstik, so you've never setup `cups` etc. on a computer, and you
>>>>  want to be able to just plug in your ethO cable and call a single
>>>>  script, and not need to work at the inconveniently located printer.
>>>> 
>>>> How to simplify even further, so that the portable device, that brings
>>>> the files to the eth0 connected printer, has no display/kybrd, and is
>>>> just programmed to <print when it's powered up>. No that's not fantacy
>>>> : it's been playing <the next *.wav> flawlessly, when powered-up 1000
>>>> times.
>>> 
>>> Well, playing a local sound file through the known/built-in audio
>>> device is not at all the same as probing the entire network for any/all
>>> printers, determining their make/model,
>> 
>> Perhaps a picture will help? Disconnect existing eth0 cable from printer
>> 
>> [rPi in shoe-box with 6V acco]--eth0Cable-->[HP-3055-Laser-Jet]
>
> You still need to know/find the IP of the printer. And if it's dhcp
> it my try to renew it's lease while you're connected. If that fails
> I don't know if it will keep the same ip or drop off the network.
>
That is also silly. The other computers have to know what the IP is of
the printer so they can print. Having the printer jumping around with
its IP is a non-starter. 

Note that if the printer supports cups (ipp protocol) it may be set up
to broadcast itself to the other systems on the net.



>> 
>>> and pumping the source document through the right conversion and driver
>>> to send to the printer. You'll be lucky to find a command-line only
>>> solution, much less a blind one. And you're certainly not going to be
>>> develop a solution in isolation and have it just work when you're at
>>> said office. You'll need to develop the procedure at the office. A
>>> couple useful tools might be nmap for discovery and smbspool for
>>> sending data to the printer.
>>> 
>> nmap - Network exploration tool and security / port scannersmbspool -
>> smbspool - send a print file to an SMB printer
>> 
>> That looks interesting. Thanks.
>> 
>> I've read that a common printer:IP = 192.168.0.9100 [or something]
>> Does it mess their network if I just unplug their eth0->printer,
>> and plug rPi to do: ping common Printer IP/s and save results ?
>
> That IP is wrong. The "9100" you've seen before is a port number used
> by hp printers' "jetdirect" protocol (possibly others?). It looks like
> you can send a byte stream directly to that to printer using nc.
>
> http://danieru.com/2013/06/06/what-is-port-9100-how-to-print-to-it/
>
> I just tried it. Seems to work for plain text files. But be sure your
> files have CR+LF not just LF as most *nix files will have.
>
> sed 's/$/\x0d/' <YOUR_TEXT_FILE|nc 192.168.x.y 9100
>
> Also, it looks like you'll have to insert form feeds, \x0c or ^L, as
> needed. My test dropped everything that didn't fit on the page. So add
> a form feed after 60 lines, or whatever fits on whatever size paper
> you have (I have US letter size). 
>
>> 
>>> Perhaps a call to the office to at least find out the make and model of
>>> printer would be helpful.
>> 
>> That was listed in OP. Think from 1st principles; not ito *YOUR* office.
>
> Oops, my bad. My office uses "dvihp" to convert latex dvi files for
> a laserjet 4050. I think that still relies on lpr to actually send
> the data to the printer.

[toc] | [prev] | [next] | [standalone]

#14753

On Fri, 08 May 2015 14:58:52 +0000, William Unruh wrote:
>>> Perhaps a picture will help? Disconnect existing eth0 cable from
>>> printer
>>> 
>>> [rPi in shoe-box with 6V acco]--eth0Cable-->[HP-3055-Laser-Jet]
>>
>> You still need to know/find the IP of the printer. And if it's dhcp it
>> my try to renew it's lease while you're connected. If that fails I
>> don't know if it will keep the same ip or drop off the network.
>>
> That is also silly. The other computers have to know what the IP is of
> the printer so they can print. Having the printer jumping around with
> its IP is a non-starter.

DHCP can be configured to assign a consistent address. Sometimes that
is easier than messing with the goofy config methods of various IoT.

> 
> Note that if the printer supports cups (ipp protocol) it may be set up
> to broadcast itself to the other systems on the net.

That too.

[toc] | [prev] | [next] | [standalone]

#14754

At Mon, 11 May 2015 13:24:06 +0000 (UTC) Joe Beanfish <joebeanfish@nospam.duh> wrote:

> 
> On Fri, 08 May 2015 14:58:52 +0000, William Unruh wrote:
> >>> Perhaps a picture will help? Disconnect existing eth0 cable from
> >>> printer
> >>> 
> >>> [rPi in shoe-box with 6V acco]--eth0Cable-->[HP-3055-Laser-Jet]
> >>
> >> You still need to know/find the IP of the printer. And if it's dhcp it
> >> my try to renew it's lease while you're connected. If that fails I
> >> don't know if it will keep the same ip or drop off the network.
> >>
> > That is also silly. The other computers have to know what the IP is of
> > the printer so they can print. Having the printer jumping around with
> > its IP is a non-starter.
> 
> DHCP can be configured to assign a consistent address. Sometimes that
> is easier than messing with the goofy config methods of various IoT.

Right. For *all* 'fixed' devices (anything that is always there or is often
there) on your LAN, you should in general give them fixed addresses. ALL
Broadband Router appliances can be configured to give out fixed addresses for
selected MAC addresses. And if you are running dhcpd on your Linux machine,
you just add sections like this:

        host gollum {
                hardware ethernet 00:09:6b:fa:68:4b;
                fixed-address 192.168.250.5;
                option host-name "gollum.deepsoft.com";
        }

to dhcpd.conf (somewhere under /etc/).

> 
> > 
> > Note that if the printer supports cups (ipp protocol) it may be set up
> > to broadcast itself to the other systems on the net.
> 
> That too.
>                                                             

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                                                             

[toc] | [prev] | [next] | [standalone]

#14740

On 2015-05-08, Unknown <dog@gmail.com> wrote:
> On Wed, 06 May 2015 13:36:45 +0000, Joe Beanfish wrote:
>
>> On Wed, 06 May 2015 08:50:56 +0000, Unknown wrote:
>>> If the office M$ system was closed for 2 weeks, and you needed to
>>> desperately print some files from your portable *nix computer via the
>>> office-HP-3055-Laser-Jet, how would you drive the printer via an eth0
>>> cable from your portable?
>>> 
>>> What's a simple script to probe the printer to find its IP? Can nc do
>>> that?
>>> 
>>> You've previously always just given your text-files to the M$-user on
>>>  a USBstik, so you've never setup `cups` etc. on a computer, and you
>>>  want to be able to just plug in your ethO cable and call a single
>>>  script, and not need to work at the inconveniently located printer.
>>> 
>>> How to simplify even further, so that the portable device, that brings
>>> the files to the eth0 connected printer, has no display/kybrd, and is
>>> just programmed to <print when it's powered up>. No that's not fantacy
>>> : it's been playing <the next *.wav> flawlessly, when powered-up 1000
>>> times.
>> 
>> Well, playing a local sound file through the known/built-in audio device
>> is not at all the same as probing the entire network for any/all
>> printers, determining their make/model,
>
> Perhaps a picture will help? Disconnect existing eth0 cable from printer
>
> [rPi in shoe-box with 6V acco]--eth0Cable-->[HP-3055-Laser-Jet]
>
>> and pumping the source document
>> through the right conversion and driver to send to the printer. You'll
>> be lucky to find a command-line only solution, much less a blind one.
>> And you're certainly not going to be develop a solution in isolation and
>> have it just work when you're at said office. You'll need to develop the
>> procedure at the office. A couple useful tools might be nmap for
>> discovery and smbspool for sending data to the printer.
>> 
> nmap - Network exploration tool and security / port scannersmbspool - 
> smbspool - send a print file to an SMB printer

An HP is not an SMB printer. Why do you not ask someone what the IP
address is of the printer, instead of trying to search for it on the
net? There is the other possibility that it is not a network printer but
rather is a printer hanging off one of the Windows boxes (eg usb). So,
why not find out about the printer. Of course maybe you are an intruder
and do not want anyone to know you are using the printer. Sorry cannot
help then.

>
> That looks interesting. Thanks.
>
> I've read that a common printer:IP = 192.168.0.9100 [or something]
> Does it mess their network if I just unplug their eth0->printer,
> and plug rPi to do: ping common Printer IP/s and save results ?

Yes. 
nd that is NOT an IP address. And that is NOT a commoen printer IP
address. 

>
>> Perhaps a call to the office to at least find out the make and model of
>> printer would be helpful.
>
> That was listed in OP. Think from 1st principles; not ito *YOUR* office.

Why not also stipulate that this is an experimental office in which the
next generation of IP-- IP v8 is being tested out and you do not have
any idea what it is becuase it is still top secret. 
Go ask.

>
>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web