> > There are too many <table> tags when displaying a singel entry.  E.g.
> > in http://midas.psi.ch/elogs/Config+Examples/1 the row 'Configuration Name'
> > is not aligned with the others (see attachment).
> 
> The <table> tags are there on purpose. As you can combine several attributes
> into one line (see this forum for example), it's necessary to make an
> independent <table> for each line. 

Couldn't one include the extra <table> tag only when there is really more than
one attribute per line.  All other lines could then be aligned properly.

To increase the width is not really a solution, since this depends on the
text size used.  See attachment with really big text.

Everything after curly parenthesis is ignored in attribute entry boxes 
like 'Subject' above

What I typed in the subject line was exatcly this:

  'curly parenthesis problem {abc}'

I think the text display of ASCII files, which is new in version
2.5.4, is not a good idea.  E.g. I had a large ps file attached
to one entry and it took a long time display this entry (over DSL).
Then I saw that the ps-file is displayed as text, which is not really 
useful.  

Probably it is fine to display only files ending in '.txt' per default.
In addition a file that has more than say 1000 lines should probably 
also not be displayed (as default, optional OK).  

Cheers, Heiko

> Noee. Here it works immediately.
> 
> Can you try with a fresh server from the distribution, with the example 
> elogd.cfg, to see if there is any difference?
> 
> The killing is handled in the funciton ctrlc_handler(), which sets _abort = 
> TRUE. This  is checked in line 16195, just after the select(), and the main 
> loop is exited. The select finishes after one second, although I believe 
> that the kill signal also terminates the select prematurely. The kill 
> command and a Ctrl-C keystroke should work the same way, they both generate 
> a SIGTERM or SIGINT signal.

elogd does not exit if there is an 'unprocessed' HUP.  So when you do 

kill -HUP <pid>
kill <pid> 

elogd will only exit after it was accessed.

> > elogd does not exit if there is an 'unprocessed' HUP.  So when you do 
> > 
> > kill -HUP <pid>
> > kill <pid> 
> > 
> > elogd will only exit after it was accessed.
> 
> Can you please tell me how to reproduce this problem?
> 
> Even if I do a
> 
> kill -HUP <pid>; kill <pid>
> 
> it works immediately when I start elogd manually in interactive mode (not as daemon).

Even though I can't test this right now, I assume you have to wait a little
so that elogd jumps out of the 'select()' statement between the kill
commands.  Try: 

kill -HUP <pid>; sleep 2; kill <pid>

(I think the 'select()' timeout was 1 second.?)

> > [...]
> > > Probably it is fine to display only files ending in '.txt' per default.
> > > In addition a file that has more than say 1000 lines should probably 
> > > also not be displayed (as default, optional OK).  
> > 
> > No, '.txt' would definitely not be enough for me. I'm using elog to log all
> > administration of our network. In many cases, I simply attach a configuration
> > file. All those files are plain ASCII and none of them end in '.txt' - and I
> > would most definitely like them to be displayed inline like they are now. In
> > fact, this change was the main reason for me to upgrade to 2.5.4
> > 
> > Maybe a configuration option or a "display attachment" button would be the
> > best solution, then?
> > 
> > Cheerio,
> > 
> > Thomas
> 
> So to make everybody happy, it would probably be enough not to display inline any
> *.ps file, is that right? 

I think there should be size limit.  Imagine a multi MB text file (whatever it is;
elogd.c is already more than 1/2 MB and is likely to increase due to your
excellent support).  A client on an ISDN line would have to wait
several minutes and during this time elogd is busy and no other client can connect
(correct?).  Of course, if somebody really wants to see this file then there is
nothing to be done, but likely someone is flipping throught the messages using
to arrows on top to find the right entry....
So a configurable size limit seems appropriate, from which on 
only 'Display attachment' is displayed.  And/Or, for files
exceeding this limit, the first N (new config option) lines could be displayed.

But this should only influence ASCII files.  E.g. the behaviour for jpeg files
should not change, which is controlled by 'Hide default'.  Maybe a 'Display/Hide
defaut extension' option, where the extensions are listed that are to be displayed
is another idea, in addition to a 'Max Display ASCII inline size' option,
which can be set to zero to disable it altogether.

In any case, whatever you think is best.

Cheers, Heiko

> Is there any other ASCII format, which should not be
> displayed? PDF is binary, so it won't be displayed. What about long C files? Most
> people want to see them. In the recent version there is the "Hide attachment"
> link which can be clicked to not display an attachment inline. Mabe there should
> be a "Hide default = 0|1" config option...

> > - Use "and" and "or" operands in queries                                        
> 
> Elog supports now regular expressions. So for a "<str1> OR <str2>" one can write
> 
> <str1>|<str2>
> 
> and for a "<str1> AND <str2>" one can write
> 
> <str1>.*<str2>|<str2>.*<str1>
> 
> Looks a bit complicated, but maybe some day we will get some code which rewrites
> "AND" and "OR" as regular expressions.

It seems that the quick filter searches are now (2.5.4-6) case sensitive.
Could you add an option to specify this in the config file?  Or does it
exist already?

When compiling elogd on AMD64 (in 64 bit mode) there are many 
warnings like these:

src/regex.c:3769: warning: cast from pointer to integer of different size
src/regex.c:3769: warning: cast from pointer to integer of different size
src/regex.c:3775: warning: cast to pointer from integer of different size

The reason is the (int) cast, which (I think) is not necessary.