(abc|def).*(abc|def)

(abc.*def)|(def.*abc)

We are exploring whether it's possible/feasible to import ELog logbooks into a another database for special purposes (plotting/statisical, etc). Target database is TBD (perhaps Access).

Does anyone have or know of a logbook parser program? From cut/pasting into, for example, Excel, it does appear that the data fields are already line-feed delimited so offhand it would seem possible to parse if one really wanted to pursue it.

Regards,

- Alan

You can export to CSV (comma-separated-values) if you go to "Find" and then click on "Export: CSV". These fiels you ran read right into Excel or other spreadsheet programs for further analysis. 

excuse my butting in ...  I've found the exports useful in the past - however, is is possible to run the export from a script in order to produce reports?  Utilities like wget won't work as the export process doesn't return the data as html.

regards

Steve

That's not true. wget does work. Try that one:

wget --no-check-certificate -O export.csv https://midas.psi.ch/elogs/linux+demo/?mode=CSV1

actaully wget doesn't care if the return is HTML or a GIF image or anything else, it just saves it into the output file.

you're right, of course, on all counts!

when I was testing wget/elog to try to automate an extract I was getting a lot of stuff like:

/Change_Log/587">Software Only</a></td><td class="92^M^H<88>^\ÿ^Y"ÿ"><a href="../Change_Log/587">23416</a></td><td class="92^M^H<88>^\ÿ^Y"Ã<a href="../Change_Log/587">New</a></td><td class="92^M^H<88>^\ÿ^Y"ÿ"><a href="../Change_Log/587">Awaited</a></td>

but I must have been getting something wrong, using your command line as an example it works perfectly!  Thanks again for elog!!

 Steve, just a word of thanks for "butting in" ... my next thought was how could I schedule an export to feed the other database so it wouldn't have to be done manually each day. Your question took care of that for me!  :)

Good community. Thanks.

(For some reason I could not add this in Dennis's thread.)

I like this new feature, BUT

I happen to have two Options:   Options System, and Options Status.

System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
this is made up)

Options System: 3.1, NT, 2000, XP, Vista

where the natural order here is chronological.

Perhaps the configuration file option could be more specific, for example

Sort attribute Options Status = 1

which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
the original syntax which defaults to sort *all* Options.

I've just noticed that it has also sorted another Option, which are selected as radio buttons.  Again, this is a
list which has a natural - again, in this case, chronological - order.

Because of this, I'm going to have to turn off this feature as it is on my system.  I hope something can be sorted
on this.


> (For some reason I could not add this in Dennis's thread.)
> 
> I like this new feature, BUT
> 
> I happen to have two Options:   Options System, and Options Status.
> 
> System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
> Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> this is made up)
> 
> Options System: 3.1, NT, 2000, XP, Vista
> 
> where the natural order here is chronological.
> 
> Perhaps the configuration file option could be more specific, for example
> 
> Sort attribute Options Status = 1
> 
> which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
> the original syntax which defaults to sort *all* Options.

Ok, that makes sense, so I changed it to

Sort Attribute Options Status = 1

as you suggested.

> (For some reason I could not add this in Dennis's thread.)
> 
> I like this new feature, BUT
> 
> I happen to have two Options:   Options System, and Options Status.
> 
> System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
> Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> this is made up)
> 
> Options System: 3.1, NT, 2000, XP, Vista
> 
> where the natural order here is chronological.
> 
> Perhaps the configuration file option could be more specific, for example
> 
> Sort attribute Options Status = 1
> 
> which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
> the original syntax which defaults to sort *all* Options.

Thanks Stefan!  Works great.

> Ok, that makes sense, so I changed it to
> 
> Sort Attribute Options Status = 1
> 
> as you suggested.
> 
> > (For some reason I could not add this in Dennis's thread.)
> > 
> > I like this new feature, BUT
> > 
> > I happen to have two Options:   Options System, and Options Status.
> > 
> > System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
> > Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> > sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> > this is made up)
> > 
> > Options System: 3.1, NT, 2000, XP, Vista
> > 
> > where the natural order here is chronological.
> > 
> > Perhaps the configuration file option could be more specific, for example
> > 
> > Sort attribute Options Status = 1
> > 
> > which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
> > the original syntax which defaults to sort *all* Options.

Yes, many thanks, Stefan, from me, too! It's really great that you respond so quickly to requests and suggestions.

And thanks to David for the fine tuning, great suggestion.

Dennis

> Thanks Stefan!  Works great.
> 
> > Ok, that makes sense, so I changed it to
> > 
> > Sort Attribute Options Status = 1
> > 
> > as you suggested.
> > 
> > > (For some reason I could not add this in Dennis's thread.)
> > > 
> > > I like this new feature, BUT
> > > 
> > > I happen to have two Options:   Options System, and Options Status.
> > > 
> > > System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
> > > Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> > > sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> > > this is made up)
> > > 
> > > Options System: 3.1, NT, 2000, XP, Vista
> > > 
> > > where the natural order here is chronological.
> > > 
> > > Perhaps the configuration file option could be more specific, for example
> > > 
> > > Sort attribute Options Status = 1
> > > 
> > > which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
> > > the original syntax which defaults to sort *all* Options.

Hello Stefan.

Currently this is defined as a maximum of 100 literals in the cfg file. I would like to see the option to reference an external text file as input for this. 

As a side question, I would also like to increase the max to a greater value, for example, even 5000. I assume I can change the source (I recall var was something like "List_Option_Max") and see if that would still work, but would you know offhand if that would cause a problem anywhere else?

Regards,

Alan

(PS: Just getting started with ELog. Please excuse if these questions sound newbie. I also searched the Forum first but haven't found any answers to them yet.)

I will put this on the wish list. 

I limited this to 100 entries because it will be hard to handle it. Imagine a drop-down list box with 5000 entries. It would fill your complete screen and you still won't see all 5000 entries. In that case it might be better to use a free text field and enter the attribute value as free text.

You can increase MAX_N_LIST in elogd.c, but at some point you will get a stack overflow and elogd will just crash.

- Stefan

Hi,

I am using syntax like (from the doc):

Display Telephone = <a href="http://any.company.com/telbook.cgi?search=$Name">$Name's telephone number</a>

Until yesterday this was interpreted as HTML.

After upgrading to 2.7.7, I still get a valid link but the full HTML code is also displayed: the user sees
''<a href="http://any.company.com/telbook.cgi?search=myname">myname's telephone number</a>''
where he should only see:
''myname's telephone number''

I am 99% sure this is a consequence of the upgrade. Is there a way to get the original behaviour back?
Thanks a lot
Soren Poulsen

Display Telephone = <a href="http://any.company.com/telbook.cgi?search=$Name">$Name's telephone number</a>

Until yesterday this was interpreted as HTML.

After upgrading to 2.7.7, I still get a valid link but the full HTML code is also displayed: the user sees
''<a href="http://any.company.com/telbook.cgi?search=myname">myname's telephone number</a>''
where he should only see:
''myname's telephone number''

I am 99% sure this is a consequence of the upgrade. Is there a way to get the original behaviour back?
Thanks a lot
Soren Poulsen

 I have more precise information about the nature of this issue, which concerns the display of E-logs

In the previous version 2.7.6, E-log would generate HTML like this:

td class="attribvalue">
<a href="https://edms.cern.ch/camms/plsql/d7i_report_CV_WO_VIEW.form_7?event=15403690&button=Search">15403690</a>&nbsp;</td>

In the latest version 2.7.7, E-log generates HTML like this (for the same attribute):

<td class="attribvalue">
&lt;a href="<a href="https://edms.cern.ch/camms/plsql/d7i_report_CV_WO_VIEW.form_7?event=15575045&amp;button=Search">https://edms.cern.ch/camms/plsql/d7i_report_CV_WO_VIEW.form_7?event=15575045&amp;button=Search</a>"&gt;15575045&lt;/a&gt;&nbsp;</td>

Soren Poulsen

Display Telephone = <a href="http://any.company.com/telbook.cgi?search=$Name">$Name's telephone number</a>

Until yesterday this was interpreted as HTML.

After upgrading to 2.7.7, I still get a valid link but the full HTML code is also displayed: the user sees
''<a href="http://any.company.com/telbook.cgi?search=myname">myname's telephone number</a>''
where he should only see:
''myname's telephone number''

I am 99% sure this is a consequence of the upgrade. Is there a way to get the original behaviour back?
Thanks a lot
Soren Poulsen

You need

Allow HTML = 1

in your configuration file. See the documentation for details. This featue is new in 2.7.7.

Display Telephone = <a href="http://any.company.com/telbook.cgi?search=$Name">$Name's telephone number</a>

Until yesterday this was interpreted as HTML.

After upgrading to 2.7.7, I still get a valid link but the full HTML code is also displayed: the user sees
''<a href="http://any.company.com/telbook.cgi?search=myname">myname's telephone number</a>''
where he should only see:
''myname's telephone number''

I am 99% sure this is a consequence of the upgrade. Is there a way to get the original behaviour back?
Thanks a lot
Soren Poulsen

Thanks a lot. In fact I did not read the 2.7.7 version of the documentation, which I should have done.

Have a good aftenoon

Soren

Under some circumstances the New/Edit entry screen can invoke the init_resize() function in the onload handler for the <body> tag, but the init_resize() function is not defined.  In my case there is a log where the encoding is plain text (Default encoding = 1) and the message height is restricted (Message height = 4).  Creating or editing entries in this log generates warnings in the Firefox error console and alert boxes in IE about init_resize being undefined.

I think there is some missing logic.  In revision 2246 of elogd.c

• at line 9924, if enc_selected = 1 then init_resize() is included in the onload handler, but
• at line 9801, if enc_selected = 1 but at least one of the  "Message height" or "Message width" attributes is set then the code defining init_resize() is not include

I think you need to duplicate the checks on the Message height and Message width attributes at lines 9924, so that the init_resize() function is only included when defined.

Richard S

Perfect! Not only your analysis but also your suggested solution. I implemented that in revision 2249.

Stefan 

Hi,

I'm trying to synchronize an elog in my computer with my personal elog in my institute's server. The two elogd.cfg files are necessarily different since the elog in my institute is for many people's elogs, so I'm not completely sure this is supposed to work.  

I've copied the configuration of my (remote) elog into my local elogd.cfg file, and added in the global section of the local file:

Mirror server = https://www.pp.rhul.ac.uk:8080/

Mirror Config = 1

Mirror cron = 0 7-19 * * 0-5

Mirror user = ricardo

Password file = [my password file]

Then I relaunched my local elogd demon and tried both to synchronize the local elog and to wait for the cron job to do it. When I try to synchronize the "ATLAS Trigger" elog I get in the browser:

"Safari can’t open the page “https://localhost:8080/ATLAS+Trigger/?cmd=Synchronize” because Safari can’t establish a secure connection to the server “localhost”"

(the local elog is in https://localhost:8080/ATLAS+Trigger/)

When I wait for cron to update from the mirror this is what I get in the log:

28-Jul-2009 18:51:09 [] SSLServer listening on port 8080 ...

28-Jul-2009 18:50:00 [] Cron job started

28-Jul-2009 18:50:00 [] {ATLAS Trigger} MIRROR: Remote server is not an ELOG server

Yepp. Synchronizing over SSL does not yet work. I have it on my to-do list since quite some time, but can't find the time to implement it. So at the moment you have to synchronize without SSL. 

 Hi,

Ok, to see if I understand. You mean setting SSL = 0 in my cfg file and leaving the rest as it is, right? Then I synchronize by hand and I guess I'll be prompted for the password. Perhaps I should remove my local password file to avoid that the password is send unencrypted?

Cheers,

Ricardo

That's correct. The password will be sent unencrypted if you get prompted, but if you use the automatic scheme the password will be encrypted (but not the logbook entries of course). But your concerns are right, running this thing not over SSL is a bad thing these days...

 Ok, thanks a lot! I'll try asap and report back.

Cheers,

Ricardo

Unfortunately I only got 1/2 hour to go back to this... I was trying to avoid copying the whole remote elog server from 20 people (that's what I get with the automatic cloning, right?)

So, I set SSL=0 and removed the password file, but still got the same result. Then I looked in the code a bit, and can see that the problem happens in retrieve_remote_md5(...) in the lines:

   p = strstr(text, "ELOG HTTP ");
   if (!p) {
      if (isparam("debug"))
         rsputs(text);
      sprintf(error_str, loc("Remote server is not an ELOG server"));

in elogd.c, where I see text is filled by retrieve_url()

So what seems to fail is that retrieve_url() gets back a string from the remote server which doesn't include the string "ELOG HTTP ". But I don't know what that really means. Here is what I get if I try:

bash-3.2$ /usr/local/sbin/elogd -v -m -p 8080 -c /usr/local/elog/elogd.cfg -D

I get the following output:

Indexing logbook "ATLAS Trigger" in "/usr/local/elog/logbooks/ATLAS Trigger/" ... 

Config [ATLAS Trigger],                           MD5=1FAE83FC1D3B920AFDB3DC5F49C25FAF

Entries:

  ID   1, 090728a.log, ofs     0, thead, MD5=8D8E44C14FCFA9E2FC24CEC14E60D5ED

After sort:

  ID   1, 090728a.log, ofs     0

ok

Indexing logbook "Top physics and SLT" in "/usr/local/elog/logbooks/Top/" ... 

Config [Top physics and SLT],                           MD5=C6A82A4BD6FF708BFDA3EA8719ECE48C

Found empty logbook "Top physics and SLT"

Indexing logbook "Trigger Slices and Core SW" in "/usr/local/elog/logbooks/Slices/" ... 

Config [Trigger Slices and Core SW],                           MD5=316B8D7A8FBA661518FD61D3BAC39F3C

Entries:

  ID   2, 090727a.log, ofs     0, thead, MD5=AA8B0B0972718F9BD95F5BA89E70DD97

  ID   3, 090727a.log, ofs  3870, thead, MD5=A69E46D18074A59C4445B72EE72F025D

  ID   4, 090727a.log, ofs  8354, thead, MD5=0DC3AF86F2A88ACD76E766FA1AA08665

  ID   5, 090730a.log, ofs     0, thead, MD5=59299CDFA98983EB33EC08CF1A8FF7C0

  ID   6, 090730a.log, ofs 10120, thead, MD5=0039C61DA667AA36D06A5772F8E3D0FA

After sort:

  ID   2, 090727a.log, ofs     0

  ID   3, 090727a.log, ofs  3870

  ID   4, 090727a.log, ofs  8354

  ID   5, 090730a.log, ofs     0

  ID   6, 090730a.log, ofs 10120

ok

Retrieving entries from "https://www.pp.rhul.ac.uk:8080/ATLAS Trigger"...

Remote server is not an ELOG server

Your problem is here. I wrote that synchronization is not possible through SSL, but you try to access https://www.pp.rhul.ac.uk:8080 which is SSL (because you have https:// not http://). 

 Ah, I see. Hmm, ok it doesn't work without the s either. I can't access the server in that case. Ok, I think I'll just wait for this feature to be available. Thanks for your help!

 Of course you also have to switch your mirror server not to use SSL as well. You can check this then by accessing it directly via http://www.pp.rhul.ac.uk:8080/ATLAS Trigger from the same computer. Also make sure that you don't have any firewall issue.