I think this is reasonable. All the HTML-files which I want insert (created with the software
INCA) are not shown correctly. My testfiles made with OpenOffice are shown correctly. Maybe
you have the time to program an option for the attachement "Show inside/Show in new window or
tab", so that the user can choose, how his HTML file is shown. Similiar to the option "Submit
as HTML text".

> > I upgraded from ver 2.5.5-2 to 2.5.8-2 and found that none of my preset text
> > worked any longer.  I struggled with it for several hours and then reverted
> > back to 2.5.5-2 and the preset text worked again.  I have attached my
> > elgd.cfg file for review.  Thanks in advance for your help...
> 
> Your config file really helped. You found a bug which happens only if one uses
> conditions with lowercase letters, so that's why nobody else saw it before. I
> fixed it and released V2.5.8-3

Thanks for the information.

ELOG is terrific!

> Ok, fixed. I do however not evaluate the conditional attribute, but just remove any
> empty attribute, I guess that makes more sense.

ok, it work perfectly, tnx .. I agree with you choice of course :-)

> > I ask because I get a dependency that I did not have before with 2.5.3. 
> > Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
> > strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.
> 
> mxml.h and strlcpy.h are part of the elog tar ball. When untar'ed, they get copied
> into a separate directory:
> 
> ...
> -rwxr-xr-x ritt/lke      15090 2005-05-09 13:09:54 elog-2.5.9/eloglang.japanese
> -rwxr-xr-x ritt/lke      17587 2005-05-09 13:09:54 elog-2.5.9/eloglang.spanish
> drwxr-xr-x ritt/lke          0 2005-05-09 13:09:54 mxml/
> -rwxr-xr-x ritt/lke      45577 2005-05-09 13:09:54 mxml/mxml.c
> -rwxr-xr-x ritt/lke       2198 2005-05-09 13:09:54 mxml/strlcpy.c
> -rwxr-xr-x ritt/lke       4359 2005-05-09 13:09:54 mxml/mxml.h
> -rwxr-xr-x ritt/lke        567 2005-05-09 13:09:54 mxml/strlcpy.h
> 
> I have right now no access to 3.4. Once I get it, I will address the errors
> occuring there.

Ah, now I need to figure out how to pickup the new includes.  
BTW, personally I wouldn't take my word regarding the 3.4 errors -- I was simply
trying an alternative version and it is likely that the way ours is configured is the
problem.

Thanks!

> > > I ask because I get a dependency that I did not have before with 2.5.3. 
> > > Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
> > > strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.
> > 
> > mxml.h and strlcpy.h are part of the elog tar ball. When untar'ed, they get copied
> > into a separate directory:
> > 
> > ...
> > -rwxr-xr-x ritt/lke      15090 2005-05-09 13:09:54 elog-2.5.9/eloglang.japanese
> > -rwxr-xr-x ritt/lke      17587 2005-05-09 13:09:54 elog-2.5.9/eloglang.spanish
> > drwxr-xr-x ritt/lke          0 2005-05-09 13:09:54 mxml/
> > -rwxr-xr-x ritt/lke      45577 2005-05-09 13:09:54 mxml/mxml.c
> > -rwxr-xr-x ritt/lke       2198 2005-05-09 13:09:54 mxml/strlcpy.c
> > -rwxr-xr-x ritt/lke       4359 2005-05-09 13:09:54 mxml/mxml.h
> > -rwxr-xr-x ritt/lke        567 2005-05-09 13:09:54 mxml/strlcpy.h
> > 
> > I have right now no access to 3.4. Once I get it, I will address the errors
> > occuring there.
> 
> Ah, now I need to figure out how to pickup the new includes.  
> BTW, personally I wouldn't take my word regarding the 3.4 errors -- I was simply
> trying an alternative version and it is likely that the way ours is configured is the
> problem.
> 
> Thanks!


Ok, now I see the issue - the tar extract created the mxml directory in the root (not
under the created directory elog-2.5.9).  Is there a reason why these includes are not
placed in the src dir like the regex.h/.c include?

> Ok, now I see the issue - the tar extract created the mxml directory in the root (not
> under the created directory elog-2.5.9).  Is there a reason why these includes are not
> placed in the src dir like the regex.h/.c include?

Yes. I use these files in several other projects as well, and want to maintain only a
single copy. So I have

elogd-x.x.x/
elogd-x.x.x/src/
....
mxml/
mxml/strlcpy.h
mxml/strlcpy.c
mxml/mxml.c
mxml/mxml.c
...
other-project-x.x.x/
other-project-x.x.x/

So both elogd and "other-project" can use strlcpy.c and mxml.c. If I would copy it to
elogd-x.x.x/src and fix a bug there, "other-project" would use a separate copy and not
profit from the bug fix. So I would have to mainain verious copies of the same file, which
make things complicated. I compile everything also under windows, so I cannot use soft
links. If there is a better way of how to do it, please let me know.

> [ritt@pc5082 /tmp]$ tar -xzvf elog-2.5.9-2.tar.gz
> elog-2.5.9/
> elog-2.5.9/doc/
> elog-2.5.9/doc/adminguide.html
> ...
> mxml/
> mxml/mxml.c
> mxml/strlcpy.c
> mxml/mxml.h
> mxml/strlcpy.h
> [ritt@pc5082 /tmp]$ cd elog-2.5.9
> [ritt@pc5082 elog-2.5.9]$ make
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elog src/elog.c
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o regex.o src/regex.c
> ... skipping warnings ...
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o mxml.o ../mxml/mxml.c
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o strlcpy.o ../mxml/strlcpy.c
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -I../mxml -o elogd src/elogd.c regex.o
> mxml.o strlcpy.o
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elconv src/elconv.c
> [ritt@pc5082 elog-2.5.9]$
> 
> --------------
> No undefined functions here. I guess you have an old Makefile? Just use the complete tar
> package from the last version.

Ok, now I have it.  Old Makefile because I had to perform some deletions to make "make" work
right under Solaris.  Basically, I took out the ifdef structures - "make" was blowing up on
these.  Everything now compiles perfectly -- don't change anything.  Thanks for that last pointer.

Steve