> 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}'

Just don't use curly brackets (;-)

Nevertheless I fixed it in the current version (see subject)

I was trying to do some hard coded spaces using:

Thread display = For: $Date for Shutdown.   $DataCenter:
$short summary. Coordinator: $Shutdown Coordinator.

The spacing actually works mthe first time, but upon going back into editing
the config file, the coded spaces are gone, replaced with real spaces, and
when saved all real multiple spaces are, as one would expect, ignored.  The
spacing reverts back to normal.

I tried other html tags but these show up as literals.

Thanks

> I was trying to do some hard coded spaces using:
> 
> Thread display = For: $Date for Shutdown.   $DataCenter:
> $short summary. Coordinator: $Shutdown Coordinator.
> 
> The spacing actually works mthe first time, but upon going back into editing
> the config file, the coded spaces are gone, replaced with real spaces, and
> when saved all real multiple spaces are, as one would expect, ignored.  The
> spacing reverts back to normal.
> 
> I tried other html tags but these show up as literals.

I fixed that in revision 1.448. The problem also showed up even in normal
logbook entry displays and in replies (before this fix, the   in this text
whould not have shown up). Get the new version from CVS.

> > I was trying to do some hard coded spaces using:
> > 
> > Thread display = For: $Date for Shutdown.   $DataCenter:
> > $short summary. Coordinator: $Shutdown Coordinator.
> > 
> > The spacing actually works mthe first time, but upon going back into editing
> > the config file, the coded spaces are gone, replaced with real spaces, and
> > when saved all real multiple spaces are, as one would expect, ignored.  The
> > spacing reverts back to normal.
> > 
> > I tried other html tags but these show up as literals.
> 
> I fixed that in revision 1.448. The problem also showed up even in normal
> logbook entry displays and in replies (before this fix, the   in this text
> whould not have shown up). Get the new version from CVS.

As always - fantastic!

Thanks

The help text on the website says the following:

"The command Select can be used to select multiple messages for deletion of
moving to other logbooks."

This is not clear but was the intent to indicate that SELECT can be used to
either select multiple log entries for deletion OR for moving to another
logbook?  If the latter, then this does not work if one adds the MOVE TO
menu item to the list.  If the former then the helptext is a little misleading.

Thanks!

I'm not sure if this is a configuration problem or a bug, but running
v2.5.4subver1.413, elogd runs as user ROOT (UID0) even though the following
is in the elogd.cfd file:

Usr = nobody
Grp = essadm

All other directives added to the cfg file work, so I know eLog is reading
the cfg file.  

The elogd binary *is not* setuid 0.

Thanks

> The help text on the website says the following:
> 
> "The command Select can be used to select multiple messages for deletion of
> moving to other logbooks."
> 
> This is not clear but was the intent to indicate that SELECT can be used to
> either select multiple log entries for deletion OR for moving to another
> logbook?  If the latter, then this does not work if one adds the MOVE TO
> menu item to the list.  If the former then the helptext is a little misleading.

SELECT can be used for deletion OR moving OR copying. To enable the copy and move
commands, they have to be present in the "Menu commands" list, like

Menu commands = Back, New, Edit, Delete, Reply, Find, Config, Logout, Move to, Copy
to, Help

I added an appropriate note to the documentation, sorry for the misleading descriptoin.

> I'm not sure if this is a configuration problem or a bug, but running
> v2.5.4subver1.413, elogd runs as user ROOT (UID0) even though the following
> is in the elogd.cfd file:
> 
> Usr = nobody
> Grp = essadm
> 
> All other directives added to the cfg file work, so I know eLog is reading
> the cfg file.  
> 
> The elogd binary *is not* setuid 0.

I could not reproduce your problem with the current version (Revision 1.460)
under Linux. I guess you made sure that user "nobody" and group "essadm" exist.
Try to run elogd interactively, if you see any error message (without "-D"
flag). In the most recent version (1.460), I added some more debugging code
which tells you if elogd successfully fell back to another user, if you use the
"-v" (verbose) flag.

If all that does not help, I guess it's some peculiarity of Solaris. Maybe
someone else using Solaris has some idea. All elogd does is a call to 

setuser("<user>");

I see no reason why this should not work on Solaris.