Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 301 of 808  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
    icon2.gif   Re: Subject attribute in bold type - threaded display, posted by Stefan Ritt on Fri Jan 17 08:17:09 2014 

Andreas Luedeke wrote:

Paolo wrote:
Hi all,
I am successfully using ELOG V2.9.2-2455 to manage several laboratory logs.
I am looking for a way, if possible, to format the subject attribute in bold type while in thread display.
I've used the following code
Display Subject = <b>$subject</b>
with no success, then I've tried
Subst Subject = <b>$subject</b>
again with no success. It seems that the <b> tag is not iterpreted.
Have you any suggestion about this?
Thank you in advance.
Paolo

 
English (auto-detected) » English
 
T
Hi Paolo,
you've made two little errors, one is partly driven by a bug in the documentation:

1st: If you want to use HTML tags in the display of attributes, you need to add "Allow HTML = 1" in the configuration.

2nd: The proper command is not "Display <attribute> = ..." but "Change <attribute> = ...". It is actually correct in the documentation (Change <attribute> = <string>), but the example is wrong (Display Telephone = <a href="http://any.company.com/telbook.cgi?search=$Name">$Name's telephone number</a>)

Stefan should fix the example in https://midas.psi.ch/elog/config.html#attrib some day.

Cheers
Andreas

 

Thanks, I fixed the documentation.

/Stefan 

    icon2.gif   Re: Subject attribute in bold type - threaded display, posted by Paolo on Fri Jan 17 15:59:29 2014 

Andreas Luedeke wrote:

Paolo wrote:
Hi all,
I am successfully using ELOG V2.9.2-2455 to manage several laboratory logs.
I am looking for a way, if possible, to format the subject attribute in bold type while in thread display.
I've used the following code
Display Subject = <b>$subject</b>
with no success, then I've tried
Subst Subject = <b>$subject</b>
again with no success. It seems that the <b> tag is not iterpreted.
Have you any suggestion about this?
Thank you in advance.
Paolo

 
English (auto-detected) » English
 
T
Hi Paolo,
you've made two little errors, one is partly driven by a bug in the documentation:

1st: If you want to use HTML tags in the display of attributes, you need to add "Allow HTML = 1" in the configuration.

2nd: The proper command is not "Display <attribute> = ..." but "Change <attribute> = ...". It is actually correct in the documentation (Change <attribute> = <string>), but the example is wrong (Display Telephone = <a href="http://any.company.com/telbook.cgi?search=$Name">$Name's telephone number</a>)

Stefan should fix the example in https://midas.psi.ch/elog/config.html#attrib some day.

Cheers
Andreas

 

 

Dear Andreas,

thank you very much for your prompt reply and for you suggestions, which helped me to solve the problem. Now it's all working perfectly.

Cheers,

Paolo

    icon2.gif   Re: Subdirectories in logbooks, posted by Stefan Ritt on Mon Nov 11 13:09:35 2019 

Just use groups as written in the manual: https://elog.psi.ch/elog/config.html#groups

Stefan

pavel wrote:

Hello, Is there any way to organize logbooks in some kind of tree with sublogbooks or just have a subdirectories in a logbook directory on the filesystem (treat it as a sublogbook if its name is different from 4 digits of year and pin above all the entries in a list) to structure entires a bit?

 

 

    icon2.gif   Re: Strange timezone in email sent with Postfix, posted by Stefan Ritt on Thu Jan 29 09:25:45 2004 
> Instead of something like "Date: Wed, 28 Jan 2004 14:46:16 -0600", the
> "-0600" is replaced by a large number that doesn't correspond with anything
> I can figure out.  This is the sort of thing that does no real harm, but the
> notebook users keep complaining. 

This is caused by the elogd program itself. To produce the "-0600", it uses the 
variable "timezone", which is defined as difference in seconds between local time 
and coordinated universl time. This works find under Windows, Linux, FreeBSD, but 
apparently not under MacOSX. Although this variable is defined, it's unassigned. 

The code where this is used is in sendmail(), at the lines

   time(&now);
   ts = localtime(&now);
   strftime(buf, sizeof(buf), "%a, %d %b %Y %H:%M:%S", ts);
   offset = (-(int) timezone);
   if (ts->tm_isdst)
      offset += 3600;

The current localtime gets written into "buf", then the timzone offset gets 
corrected by the daylight savings time, then the offset is used to produce the 
"-0600".

So if anybody being familiar with MacOSX has some idea, please let me know.

- Stefan
    icon2.gif   Re: Strange problem with dates - need debugging help, posted by Stefan Ritt on Fri Feb 4 10:20:12 2011 

T. Ribbrock wrote:

I have just installed elog 2.8.1 on my OpenBSD 4.8 server (I've added the necessary Makefile patch to "Contributions"). Everything seems to work fine, however, I ran into a very odd problems with the dates of the logbook entries: When I start a new entry, the current date/time is displayed correctly. When I submit the entry and look at it again, the date has changed to some value in 1996 . I've checked the actual logbook file and there, the entry has a Date line like this:

Date: Thu, 03 Feb 2011 23:53:28 -13049141
 

The "-13049141" looks very suspicious to me - but I have no idea whatsoever why this happens. I had elogd running with -v, but that did not give me any hints. Any ideas how to debug/resolve this would be much appreciated... 

The problem is most probably related to the time zone. elogd contains a function:


/* workaround for wong timezone under MAX OSX */
long my_timezone()
{
#if defined(OS_MACOSX) || defined(__FreeBSD__)
   time_t tp;
   time(&tp);
   return -localtime(&tp)->tm_gmtoff;
#else
   return timezone;
#endif
}
 
from which you can see that there is a different behavior between different Linux flavors and OSX/FreeBSD. Maybe you need an additional
 
|| defined(__OpenBSD__)
 
if the pre-compiler directive __FreeBSD__ is not defined on your system. The result of the function should be the time zone in seconds relative to GMT. So for central Europe, it should give "-3600".
 
Let me know if you find something out, I can then include it in the distribution.
 
Best regards,
 
  Stefan
    icon14.gif   Re: Strange problem with dates - need debugging help, posted by T. Ribbrock on Fri Feb 4 11:52:45 2011 

Stefan Ritt wrote:

The problem is most probably related to the time zone. elogd contains a function:

/* workaround for wong timezone under MAX OSX */
long my_timezone()
{
#if defined(OS_MACOSX) || defined(__FreeBSD__)
   time_t tp;
   time(&tp);
   return -localtime(&tp)->tm_gmtoff;
#else
   return timezone;
#endif
}
 
from which you can see that there is a different behavior between different Linux flavors and OSX/FreeBSD. Maybe you need an additional
 
|| defined(__OpenBSD__)
 
if the pre-compiler directive __FreeBSD__ is not defined on your system.
[...]
 

 BINGO! That was it - thank you! I've added the || defined(__OpenBSD__) in the place you described above and now the dates are correct. While I was at it, I also had a look at what other ifdefs there are for FreeBSD and the only other one I found was also in elogd.c:

#if defined (_BSD_VA_LIST_) && defined (__FreeBSD__)

I'm far from being a C programmer, but I did some quick and dirty compile tests with various ifdefs set and apparently, _BSD_VA_LIST_ is not set on OpenBSD, so I guess that this statement does not need modification. I will keep my eyes peeled for strange behaviour, though...

Cheerio,

Thomas

P.S.: One thing I noticed is that the OpenBSD variant of gcc throws these warnings when compiling elogd.c:

gcc -g -funroll-loops -fomit-frame-pointer -W -Wall -DHAVE_SSL -I../mxml -o elogd src/elogd.c crypt.o regex.o mxml.o strlcpy.o -lcrypto -lssl
/tmp//ccHhMZfy.o(.text+0xd2f): In function `int_vasprintf':
src/elogd.c:826: warning: vsprintf() is often misused, please use vsnprintf()
/tmp//ccHhMZfy.o(.text+0xae8): In function `xstrdup':
src/elogd.c:736: warning: strcpy() is almost always misused, please use strlcpy()
/tmp//ccHhMZfy.o(.text+0x13c7): In function `my_shell':
src/elogd.c:1197: warning: sprintf() is often misused, please use snprintf()
/tmp//ccHhMZfy.o(.text+0xf0ae): In function `el_correct_links':
src/elogd.c:5178: warning: strcat() is almost always misused, please use strlcat()

I'm not certain whether this is specific to this gcc variant, but I seem to remember that the OpenBSD folks added some extra warnings and suchlike as part of their overall code audit, so I thought I'd mention it.

    icon2.gif   Re: Strange browser behaviour with chrome? </table>, posted by Stefan Ritt on Wed Apr 1 20:25:21 2015 

Andreas Luedeke wrote:
Now I'm confused: if I create an entry with "elog -n 2 ...", then I put HTML code into elog and it is displayed as HTML. This HTML code does NOT convert a "<" into "&lt;", otherwise you could not display any HTML.
But of course this code can be wrongly formatted, for example it can contain a </table> tag without a <table> tag before it. This will definitely spoil the display in ELOG, and that was what I was refering to.
I agree that html tags in plain text entries will not have this problem.


Sure, in the main body text you can insert arbitrary HTML if this type of encoding is not prohibited. The &lt; encoding I meant was for attribute values. Proof of principe above in the Subject field.
    icon2.gif   Re: Strange browser behaviour with chrome?, posted by Stefan Ritt on Mon Mar 30 17:48:06 2015 
The (correct) display tells me that the colours are user-defined, probably by the configuration option

Style <attribute> <value> = <style>

which selects different styles for different rows. Now I do not know why your browser should change behaviour all over sudden, but I would double check the configuration. Like removing all style additions in the config file, then try again, then add one by one. There could also be a class defined with the "style" option which has not been added to the default style file themes directory of the elog installation.

Stefan
ELOG V3.1.5-3fb85fa6