> From [EMAIL PROTECTED] Fri Sep 8 14:05:02 2000
> From: [EMAIL PROTECTED]
> Date: Fri, 08 Sep 2000 13:10:05 -0000
> To: [EMAIL PROTECTED]
> Subject: LPRNGLIST Various problems with 1 major one
>
> 1. We are using LPRng 3.6.19 amd IFHP 3.3.17 as these are the
> versions pointed at by the "stable" link at the astart ftp site. Are
> these in fact the latest stable releases? I ask this because LPRng
> 3.6.21 is pointed to as the "latest" and therefore wonder if the links
> have been updated recently.
Well... I suppose that this is now out long enough and no serious problems
are reported, so I will make it the stable version.
>
>
> 2. The HOWTO for IFHP says that pcl_option strings can have
> embedded escape characters in them as long as they are defined by \nnn
> or \r,\t etc. Unfortunately we need to use such characters and we find
> that they are being stripped out.
This is fixed in the next release.
>
> We have debugged ifhp and found that Put_pcl in ifhp.c calls
> Fix_option_str(s,1,1,0) which then expands the escape characters only
> then to pass them through the C routine isspace which deletes not only
> spaces but also \011, \012, \013, \014 and \015. Therefore these
> escape characters (and only them ) are removed. We have fixed this by
> changing the call to Fix_option_str(s,0,0,0) which works.
>
> Does this change have any knock on effects? 3.3.19 seems to do exactly
> the same thing.
There is a problem if you have a variable set by using:
var = xxxx[space]
Also, if you have:
var = xxxx[space]
This will have the value ' xxxx '
Now you should be aware that extra spaces in the beginning setup will cause
the top of form position to change for PCL. This can cause much pain for
users. Now one way to do this would be to try to 'trim' the variable's
value BEFORE it gets expanded:
i.e. - ' xxxx ' -> 'xxxx' and now expand xxx.
I have looked at the code fairly carefully. I think (no guarantees) that
the following might do what you want:
void Put_pcl( char *s )
{
DEBUG4("Put_pcl: orig '%s'", s );
#if defined(TRIMPCL)
if( s ){
char *t;
while( isspace(cval(s)) ) ++s;
t = s + strlen(s);
while( t > s && isspace(cval(t-1)) ) --t;
*t = 0;
}
DEBUG4("Put_pcl: trimmed '%s'", s );
s = Fix_option_str( s, 0, 0, 0 );
#else
s = Fix_option_str( s, 1, 1, 0 );
#endif
DEBUG4("Put_pcl: final '%s'", s );
Put_outbuf_str( s );
if(s)free(s);s=0;
}
You should set the CFLAGS=-DTRIMPCL to use this...
Notice now that I trim the 'incoming' string, which will remove the 'start and end'
whitespace. I then expand the string, as you did, with no trimming.
This is VERY dangerous, and depends on having no whitespace.
>
>
> 3. We have a site defined filter which is called by ifhp. We
> noticed that on occasion the parameters passed to it were being
> truncated. This happened particularly when files were printed with
> long path names. We debugged this and found that Fix_option_str in
> ifhp.c has a definition "char num[SMALLBUFFER]". We changed this to
> use LARGEBUFFER and all is well.
>
> Again does this have any knock on effects? 3.3.19 seems to do exactly
> the same thing.
There is a problem with stack size - if you have [ x ] then the
Fix_option_str gets called recursively. But this is not serious.
>
>
> 4. The site filter is called by ifhp as "filter_name \%s{T}
> \%s{ARGV}". The filter is not receiving the T options from printcap.
>
> If ifhp is called from the command line with -Toption1,option2,...
> then the filter receives a comma separated list of option1,option2...
> together with -Toption1,option2...
>
> However when ifhp is called from lpd the filter only receives the
> standard filter options -A etc defined in Filter_options_DYN as
> expanded by Fix_dollars in linelist.c.
>
> Ifhp must be reading printcap to find the value of model because it
> prints OK and debugging shows this to happen. However it does not seem
> to take the options from printcap and pass them through. We are stuck
> here because we are not sure how these options were intended to be
> passed on. We need help. We need to have these options passed
> through without having to name each possible option from all printers
> in the call within ifhp.conf.
The following will do what you want:
DEBUG1("main: Model_id '%s'", Model_id );
DEBUG1("main: LANG '%s', 'TRANSLATE TEST' is '%s'",
getenv("LANG"), _("TRANSLATE TEST"));
* /* now we fix up the Upperopts['T'-'A'] */
* Upperopts['T'-'A'] = Join_line_list_with_sep(&Topts,",");
/* read the configuration file(s) */
if( Read_file_list( &Raw, Config_file, "\n", 0, 0, 0, 0, 1, 0, 1 ) == 0 ){
Add the indicated line.
>
>
> 5. We have a central server accepting spool requests from a
> number of remote servers. All servers are using the same version of
> LPRng. The central server runs on Red Hat version 6.2 and the remote
> machines run a variety of linux and solaris. The remote servers are
> set up to spool locally before sending the request to the central
> server.
>
> We find that if requests are made on a remote server very close
> together then sometimes the request will print on the wrong printer.
> We can force this to happen by putting three lpr requests in a shell
> script on a remote machine (running under solaris ) and runnig the
> script. The central server then receives three requests all showing
> the correct queue ( -Q ) information but with the printer ( -P )
> information interchanged, causing the requests to be printed on the
> wrong printer.
I find this VERY strange... Are you saying that the 'lpr' client
is SENDING jobs with the wrong printer name OR that the 'lpd' client
is putting them in the wrong queue?
Note: you can modify the LPD code to make a quick 'one line dump' of
the incoming request - this will give you a REALLY quick and dirty
way to find out what is going on. You need to do something like:
{
static fd;
char msg[512];
if( fd == 0 ){
fd = open( "/var/tmp/lpd.log", O_CREAT|O_APPEND, 0600 );
}
if( fd > 0 ){
SNPRINTF(msg,sizeof(msg),"%s '%s'\n", Time_str(0,0),
stuff_you_want_to_record);
Write_fd_str(fd, msg);
}
}
This is ugly, but very handy when you have problems. Note the Time_str
to help you figure out what is going on.
>
> We can stop this by putting 10 second sleeps between the calls in the
> script. However as the remote machines are becoming loaded we are
> finding that incorrect printing is happening more often.
>
> We have tried to debug this. However the level 5 debug, which seems to
> be necessary, stops the problem, presumably because of the time taken
> to write the debug info!!!!!!!!!!! Can you suggest a way forward
> here as this is now a real problem?
>
>
>
> This is my first post and I hope I've not inadvertently contravened
> any etiquette. I have looked at previous posts but could not find any
> relevent ones.
>
>
No problems.
Patrick Powell Astart Technologies,
[EMAIL PROTECTED] 9475 Chesapeake Drive, Suite D,
Network and System San Diego, CA 92123
Consulting 858-874-6543 FAX 858-279-8424
LPRng - Print Spooler (http://www.astart.com)
-----------------------------------------------------------------------------
If you need help, send email to [EMAIL PROTECTED] (or lprng-requests
or lprng-digest-requests) with the word 'help' in the body. For the impatient,
to subscribe to a list with name LIST, send mail to [EMAIL PROTECTED]
with: | example:
subscribe LIST <mailaddr> | subscribe lprng-digest [EMAIL PROTECTED]
unsubscribe LIST <mailaddr> | unsubscribe lprng [EMAIL PROTECTED]
If you have major problems, send email to [EMAIL PROTECTED] with the word
LPRNGLIST in the SUBJECT line.
-----------------------------------------------------------------------------
