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
ID Date Icon Author Author Email Category OS ELOG Version Subjectdown
  67655   Fri Jan 17 08:17:09 2014 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux2.9.2-2455Re: Subject attribute in bold type - threaded display

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 

  67656   Fri Jan 17 15:59:29 2014 Reply Paolopivato@science.unitn.itQuestionLinux2.9.2-2455Re: Subject attribute in bold type - threaded display

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

  69058   Mon Nov 11 13:09:35 2019 Reply Stefan Rittstefan.ritt@psi.chRequestAll3.1.4Re: Subdirectories in logbooks

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?

 

 

  462   Thu Jan 29 09:25:45 2004 Reply Stefan Rittstefan.ritt@psi.chBug reportMac OSX2.3.9Re: Strange timezone in email sent with Postfix
> 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
  67007   Fri Feb 4 10:20:12 2011 Reply Stefan Rittstefan.ritt@psi.chQuestionOther2.8.1Re: Strange problem with dates - need debugging help

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
  67008   Fri Feb 4 11:52:45 2011 Agree T. Ribbrockemgaron+elog@ribbrock.orgQuestionOther2.8.1Re: Strange problem with dates - need debugging help

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.

  67854   Wed Apr 1 20:25:21 2015 Reply Stefan Rittstefan.ritt@psi.chQuestionWindowsELOG V2.9.Re: Strange browser behaviour with chrome? </table>

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.
  67843   Mon Mar 30 17:48:06 2015 Reply Stefan Rittstefan.ritt@psi.chQuestionWindowsELOG V2.9.Re: Strange browser behaviour with chrome?
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