From: A M. <debian@Tonelli.sns.it> - 2001-10-23 14:16:32
Attachments:
printcap-malefico
|
hi actually I sent an e-mail on the same problem some time ago (febraury?) a Debian user has sent me bug #115980 [1] saying that gpr fails on the printcap in attachment the printcap was generated by lprngtool ; it is not conformant, (see 'man 5 termcap'), but it works for lprng specifically, the printcap lacks the ':\' sequence before newline gdb reports: Program received signal SIGSEGV, Segmentation fault. get_printer_menu (ppd=0x806f750) at interface.c:1602 1602 *end = '\0'; if I add the ':\' before newline, gpr works I have asked the mantainer of lprng (see bug #116246 [1]) to change lprngtool so that it adds the ':\' s/he is thinking about it in the meantime I am also looking for a quickfix bye a. [1] bugs are accessible through bugs.debian.org -- A Mennucc "È un mondo difficile. Che vita intensa!" (Renato Carotone) |
From: A M. <debian@Tonelli.sns.it> - 2001-10-23 14:45:25
Attachments:
gp
|
hi here is a quickfix to the problem a. On Tue, Oct 23, 2001 at 04:16:18PM +0200, A Mennucc1 wrote: > > hi > > actually I sent an e-mail on the same problem some time ago (febraury?) > > a Debian user has sent me bug #115980 [1] > saying that gpr fails on the printcap in attachment > > the printcap was generated by lprngtool ; it is not conformant, > (see 'man 5 termcap'), but it works for lprng > > specifically, the printcap lacks the ':\' sequence before newline > > gdb reports: > Program received signal SIGSEGV, Segmentation fault. > get_printer_menu (ppd=0x806f750) at interface.c:1602 > 1602 *end = '\0'; > > if I add the ':\' before newline, gpr works > > I have asked the mantainer of lprng (see bug #116246 [1]) to change lprngtool > so that it adds the ':\' > s/he is thinking about it > > in the meantime I am also looking for a quickfix > > > bye > > a. > > [1] bugs are accessible through bugs.debian.org > > -- > A Mennucc > "È un mondo difficile. Che vita intensa!" (Renato Carotone) > # /etc/printcap: printer capability database. See printcap(5). > # You can use the filter entries df, tf, cf, gf etc. for > # your own filters. See the printcap(5) manual page for further > # details. > > ##LPRNGTOOL## REMOTE POSTSCRIPT 600x600 a4 {} PostScript Default 1 > lp > : > :sd=/var/spool/lpd/lp > :sh > :cm=infoprint 20 B4-7 > :ml=0 > :mx=0 > :af=/var/spool/lpd/lp/acct > :lf=/var/spool/lpd/lp/log > :cd=/var/spool/lpd/lp > :lp=PASS@9.87.250.164 > #:if=/etc/magicfilter/ljet2p-filter > :if=/etc/magicfilter/ljet4050-filter > : > -- A Mennucc "È un mondo difficile. Che vita intensa!" (Renato Carotone) |
From: Ben W. <be...@zo...> - 2001-11-05 22:40:31
|
That patch looks good to me. I've applied it to the main tree. > > --rQ2U398070+RC21q > Content-Type: text/plain; charset=iso-8859-1 > Content-Disposition: inline > Content-Transfer-Encoding: 8bit > > > hi > > here is a quickfix to the problem > > a. > > On Tue, Oct 23, 2001 at 04:16:18PM +0200, A Mennucc1 wrote: > > > > hi > > > > actually I sent an e-mail on the same problem some time ago (febraury?) > > > > a Debian user has sent me bug #115980 [1] > > saying that gpr fails on the printcap in attachment > > > > the printcap was generated by lprngtool ; it is not conformant, > > (see 'man 5 termcap'), but it works for lprng > > > > specifically, the printcap lacks the ':\' sequence before newline > > > > gdb reports: > > Program received signal SIGSEGV, Segmentation fault. > > get_printer_menu (ppd=0x806f750) at interface.c:1602 > > 1602 *end = '\0'; > > > > if I add the ':\' before newline, gpr works > > > > I have asked the mantainer of lprng (see bug #116246 [1]) to change lprngtool > > so that it adds the ':\' > > s/he is thinking about it > > > > in the meantime I am also looking for a quickfix > > > > > > bye > > > > a. > > > > [1] bugs are accessible through bugs.debian.org > > > > -- > > A Mennucc > > "È un mondo difficile. Che vita intensa!" (Renato Carotone) > > > # /etc/printcap: printer capability database. See printcap(5). > > # You can use the filter entries df, tf, cf, gf etc. for > > # your own filters. See the printcap(5) manual page for further > > # details. > > > > ##LPRNGTOOL## REMOTE POSTSCRIPT 600x600 a4 {} PostScript Default 1 > > lp > > : > > :sd=/var/spool/lpd/lp > > :sh > > :cm=infoprint 20 B4-7 > > :ml=0 > > :mx=0 > > :af=/var/spool/lpd/lp/acct > > :lf=/var/spool/lpd/lp/log > > :cd=/var/spool/lpd/lp > > :lp=PASS@9.87.250.164 > > #:if=/etc/magicfilter/ljet2p-filter > > :if=/etc/magicfilter/ljet4050-filter > > : > > > > > -- > A Mennucc > "È un mondo difficile. Che vita intensa!" (Renato Carotone) > > --rQ2U398070+RC21q > Content-Type: text/plain; charset=iso-8859-1 > Content-Disposition: attachment; filename=gp > Content-Transfer-Encoding: 8bit > > --- ../../../prdownloads.sourceforge.net/gpr-0.7/src/interface.c Fri May 18 20:48:04 2001 > +++ src/interface.c Tue Oct 23 16:34:46 2001 > @@ -1563,7 +1563,22 @@ > if (spool_dir != NULL) { > spool_dir = spool_dir + 4; /* move 4 spaces to the right */ > end = strchr(spool_dir, ':'); > - *end = '\0'; > + if(end) > + *end = '\0'; > + else { > + g_warning("\ > +The file /etc/printcap is not conformant. As 'man 5 termcap' tells,\n\ > + Termcap entries must be defined on a single logical line,\n\ > + with `\\' used to suppress the newline. Fields are sepa\n\ > + rated by `:'. The first field of each entry starts at the\n\ > + left-hand margin, and contains a list of names for the\n\ > + terminal, separated by '|'.\n\ > +It is actually customary to have one field for line, and to have ':\\'\n\ > +before the newline. gpr may have failed in parsing your /etc/printcap"); > + end = strchr(spool_dir, '\n'); > + if(end) > + *end = '\0'; > + } > > if (local_ppd->spool_dir == NULL) > local_ppd->spool_dir = g_strdup(spool_dir); > @@ -1598,8 +1613,18 @@ > else > /* now back to the original code */ > end = strchr(printer_name, ':'); > - > - *end = '\0'; > + if(end) > + *end = '\0'; > + else > + g_warning("\ > +The file /etc/printcap is not conformant. As 'man 5 termcap' tells,\n\ > + Termcap entries must be defined on a single logical line,\n\ > + with `\\' used to suppress the newline. Fields are sepa\n\ > + rated by `:'. The first field of each entry starts at the\n\ > + left-hand margin, and contains a list of names for the\n\ > + terminal, separated by '|'.\n\ > +It is actually customary to have one field for line, and to have ':\\'\n\ > +before the newline. gpr may have failed in parsing your /etc/printcap"); > > current_printer_item = gtk_menu_item_new_with_label(printer_name); > gtk_menu_append(GTK_MENU(printer_menu), current_printer_item); > > --rQ2U398070+RC21q-- > > _______________________________________________ > Lpr-discuss mailing list > Lpr...@li... > https://lists.sourceforge.net/lists/listinfo/lpr-discuss |
From: Ben W. <be...@zo...> - 2001-11-05 22:32:11
|
> > --mYCpIKhGyMATD0i+ > Content-Type: text/plain; charset=iso-8859-1 > Content-Disposition: inline > Content-Transfer-Encoding: 8bit > > > hi > > actually I sent an e-mail on the same problem some time ago (febraury?) > This is a bit of a pain in the butt. As far as LPR goes, that is not a valid printcap file. The routines that GPR uses to parse printcap files were taken right out of LPR (unfortunately). Since that point, I've written a new printcap parsing library which works MUCH better. Eventually, the plan is to convert everything over to using this library. When that is done, things will work a lot better. The thing is even at that point, I don't know if it will handle this situation properly. Like I said before, this is not a valid printcap file according to the specifications that I am looking at. It seem like it would be just as valid to suggest that LPRng tool fix the printcap's that it generates. I created a bug in SF's bug tracking system to track this: http://sourceforge.net/tracker/index.php?func=detail&aid=478472&group_id=3800&atid=103800 > a Debian user has sent me bug #115980 [1] > saying that gpr fails on the printcap in attachment > > the printcap was generated by lprngtool ; it is not conformant, > (see 'man 5 termcap'), but it works for lprng > > specifically, the printcap lacks the ':\' sequence before newline > > gdb reports: > Program received signal SIGSEGV, Segmentation fault. > get_printer_menu (ppd=0x806f750) at interface.c:1602 > 1602 *end = '\0'; The thing that bother's me is the SEGV not the fact that it can't handle the printcap. I think it should fail gracefully. If I make gpr fail gracefully rather then SEGV would that be enough to resolve your bug in the debian bug system? > > if I add the ':\' before newline, gpr works > > I have asked the mantainer of lprng (see bug #116246 [1]) to change lprngtool > so that it adds the ':\' > s/he is thinking about it > > in the meantime I am also looking for a quickfix > > > bye > > a. > > [1] bugs are accessible through bugs.debian.org > > -- > A Mennucc > "È un mondo difficile. Che vita intensa!" (Renato Carotone) > > --mYCpIKhGyMATD0i+ > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename=printcap-malefico > > # /etc/printcap: printer capability database. See printcap(5). > # You can use the filter entries df, tf, cf, gf etc. for > # your own filters. See the printcap(5) manual page for further > # details. > > ##LPRNGTOOL## REMOTE POSTSCRIPT 600x600 a4 {} PostScript Default 1 > lp > : > :sd=/var/spool/lpd/lp > :sh > :cm=infoprint 20 B4-7 > :ml=0 > :mx=0 > :af=/var/spool/lpd/lp/acct > :lf=/var/spool/lpd/lp/log > :cd=/var/spool/lpd/lp > :lp=PASS@9.87.250.164 > #:if=/etc/magicfilter/ljet2p-filter > :if=/etc/magicfilter/ljet4050-filter > : > > > --mYCpIKhGyMATD0i+-- > > _______________________________________________ > Lpr-discuss mailing list > Lpr...@li... > https://lists.sourceforge.net/lists/listinfo/lpr-discuss |