| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69069
|
Sat Nov 30 15:46:16 2019 |
 | Frank Baptista | caffeinejazz@gmail.com | Request | Windows | 3.1.3-fd7f1e2 | Re: Executing a shell command using elogd Windows service | Well, there I was, eating Thanksgiving dinner, when suddenly, it hit me (no, not indigestion). I can write a simple program that parses out the latest "Status" from the most recent logbook file -- a relatively easy task, since it's a text file. This solution avoids having to execute a shell command at all. GOOOOOOAAAAAAL!!! 
As always, I appreciate all your help...can't thank you enough!
All the best,
Frank
| Stefan Ritt wrote: |
|
Wow, having these color signal lamps really looke like a cute solution, made me laugh.
No, there is no other way than the Execute new thing. I have given up long time ago to use Windows services, because they are very hard to debug and very limited. So at our site everything runs under Linux.
Have you tried to specify the explicit path of your log file? Like Execute new = echo $Status > C:\Path\Last_status.log
Best,
Stefan
| Frank Baptista wrote: |
|
Sorry -- I somehow selected the wrong OS in my original message. Asleep at the wheel again.
| Frank Baptista wrote: |
|
Greetings!
We've been successfully running nearly a dozen separate logbooks on independent laptops -- all of them are running elogd as a Windows service. This works well, since I've also set up auto recovery options in the event that the service inadvertently stops.
Now, I have a need to place the value of an attribute of the latest log entry into a basic text file. Of course, this works just fine if I have launched elogd -x as a normal executable, using Execute new = echo $Status > Last_status.log in my CFG file. However, I would like to be able to do this using the Windows service which is running in the background.
Is there another way to write the value of an attribute into a separate file? If not, do I have to have a special build of ELOG in order to be able to enable the Windows service to execute shell commands? For the record, these logbooks are running on secure laptops that are isolated onto their own network, and the user is unable to edit the CFG file.
In case you're wondering about the reason for the separate text file -- I've written a separate program which illuminates one of 4 different color signal lamps (mounted on a test station), based on the latest "Status" of the test station. (Running, Idle, Broken, Other).
I appreciate any guidance here -- this is a "big deal" here, as one glance over the floor gives us an idea of what's running (or not).
Thanks!
Frank
|
|
|
|
|
68651
|
Sun Jul 30 07:39:23 2017 |
 | Gerardo Abihaggle | gabihaggle@gmail.com | Question | Windows | 3.1.3-fd7 | Enable LDAP on Windows | Hi All,
I'm running ELOG on a Windows machine and I would like to use LDAP for Authentication, however to achive this I need to compile elog. Any advice on how to do that on Windows?
Thanks! |
|
68666
|
Mon Aug 21 11:22:09 2017 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | 3.1.3-aded4ae | Problems with german_UTF8 language | Hi Stefan,
since recently (a few weeks) ELOG confuses the language translations.
Individual language strings are translated into garbage; most other strings are fine.
Currently I see the string "please select" translated into "ressed" (see attached picture), instead of what's written correctly in the language file "bitte auswählen".
But with every restart the corrupted strings vary: other strings are affected and other garbage strings are shown - some of them unreadable binary code (see Attachment 2).
I have the same version running in English: I see no problems there.
Kind regards
Andreas |
| Attachment 1: elog_lang_bug.png
|
|
| Attachment 2: elog_lang_config_bug.png
|
|
|
68667
|
Mon Aug 21 11:45:06 2017 |
 | Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | All | 3.1.3-aded4ae | Bug with Drafts and Language German | Hi Stefan,
when one creates a new entry, and a draft entry exists for the logbook, then a menu appears (see attachment).
If one select "Neuen Eintrag anlegen" then it should ignore the draft and create a new entry.
This feat is done by adding a "&ignore=1" to the "new" command: "<URL>/?cmd=New&ignore=1".
The problem is, that it should not be "cmd=New&..." but "cmd=Neu", since the commands are part of the translation.
Due to this, no new entry can be created as long as a draft exists; at least not in any language other than english.
This problem apparently existed since the beginning of drafts, but it only created problems at our site recently.
Kind Regards
Andreas
PS: Here's a patch that works:
diff elogd.c elogd.c-orig
9575,9576c9575,9576
< rsprintf("<input type=button value=\"%s\" onClick=\"window.location.href='?cmd=%s&ignore=1';\">\n", loc("Create new entry"),
< loc("New"));
---
> rsprintf("<input type=button value=\"%s\" onClick=\"window.location.href='%s';\">\n", loc("Create new entry"),
> "?cmd=New&ignore=1"); |
| Attachment 1: elog_lang_pending_draft_bug.png
|
|
|
68668
|
Mon Aug 21 12:16:05 2017 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | All | 3.1.3-aded4ae | Re: Bug with Drafts and Language German | I've quickly checked: there are a couple more commands in the source code that are not language encoded. I guess some of them needs correction.
> egrep -n "cmd=[A-Za-z]" elogd.c
10293: rsprintf(" r.open('GET', '?jcmd=Unlock&edit_id=%d', true);\n", message_id);
11784: ("<label for=\"ELCode\"><a target=\"_blank\" href=\"?cmd=HelpELCode\">ELCode</a> </label>\n");
13663: "\r\n%s URL : %s?cmd=Config&cfg_user=%s&unm=%s\r\n", loc("Logbook"),
14562: redirect(lbs, "?cmd=Config");
14625: sprintf(str, "../%s/?cmd=Config", getparam("lbname"));
14678: sprintf(str, "../%s/?cmd=Config", lbn);
15703: combine_url(lbs, host, "?cmd=GetMD5", url, sizeof(url), &ssl);
16378: strcat(str, "?cmd=GetConfig"); // request complete config file
16380: strcat(str, "?cmd=Download"); // request config section of logbook
16570: strcat(str, "?cmd=GetPwdFile"); // request password file
17575: rsprintf("<br><b><a href=\"../%s/?cmd=Synchronize&confirm=1\">", lbs->name_enc);
17577: rsprintf("<br><b><a href=\"%s/?cmd=Synchronize&confirm=1\">", lbs->name_enc);
17579: rsprintf("<br><b><a href=\"../%s/?cmd=Synchronize&confirm=1\">", lbs->name_enc);
18959: if (strstr(ref, "cmd=Search&"))
18960: strlcpy(strstr(ref, "cmd=Search&"), strstr(ref, "cmd=Search&") + 11, sizeof(str));
26728: rsprintf("<a href=\"?cmd=Synchronize\">%s</a></td>\n", loc("Synchronize all logbooks"));
| Andreas Luedeke wrote: |
|
Hi Stefan,
when one creates a new entry, and a draft entry exists for the logbook, then a menu appears (see attachment).
If one select "Neuen Eintrag anlegen" then it should ignore the draft and create a new entry.
This feat is done by adding a "&ignore=1" to the "new" command: "<URL>/?cmd=New&ignore=1".
The problem is, that it should not be "cmd=New&..." but "cmd=Neu", since the commands are part of the translation.
Due to this, no new entry can be created as long as a draft exists; at least not in any language other than english.
This problem apparently existed since the beginning of drafts, but it only created problems at our site recently.
Kind Regards
Andreas
PS: Here's a patch that works:
diff elogd.c elogd.c-orig
9575,9576c9575,9576
< rsprintf("<input type=button value=\"%s\" onClick=\"window.location.href='?cmd=%s&ignore=1';\">\n", loc("Create new entry"),
< loc("New"));
---
> rsprintf("<input type=button value=\"%s\" onClick=\"window.location.href='%s';\">\n", loc("Create new entry"),
> "?cmd=New&ignore=1");
|
|
|
68678
|
Wed Aug 23 15:11:32 2017 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | 3.1.3-aded4ae | Re: Problems with german_UTF8 language | Just an update: I've re-compiled, reinstalled and restarted elogd for other reasons and now the corrupted strings are all gone. Everthing looks fine now.
But I never worry when a problem goes away before I could understand it: I'm confident that I will have plenty of time later, when the problem magically re-appears - likely I'll be called on a Friday night :-)
| Andreas Luedeke wrote: |
|
Hi Stefan,
since recently (a few weeks) ELOG confuses the language translations.
Individual language strings are translated into garbage; most other strings are fine.
Currently I see the string "please select" translated into "ressed" (see attached picture), instead of what's written correctly in the language file "bitte auswählen".
But with every restart the corrupted strings vary: other strings are affected and other garbage strings are shown - some of them unreadable binary code (see Attachment 2).
I have the same version running in English: I see no problems there.
Kind regards
Andreas
|
|
|
69125
|
Fri Mar 20 14:07:59 2020 |
| Gianluca Rigoletti | gianluca.rigoletti@cern.ch | Question | Linux | All | 3.1.3-7933898 | How does attributes substitution work? | Hello,
Let's say I have a logboook where I define two attributes:
[TOTEM]
Comment = TOTEM Gas System Status
Attributes = Author, D, M, Y, h, min, ...
I would like to modify the "Last submission" so that I display something like %D/%M/%Y, %h:%min
so in my elogd.cfg I added this line:
Last submission = $D / $M / $Y , $h : $min by $Author
however, when display in the selection page instead of getting $min displayed i get the attribute $M+'in' displayed. How does attributes substitution work? is it case unsensitive? how does it behave when different attributes starts with the same name? |
|
69126
|
Fri Mar 20 14:24:28 2020 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | All | 3.1.3-7933898 | Re: How does attributes substitution work? | There could be a bug which is triggered by the fact that $M is a substring of $min. Try to rename $M to $Month or so.
Stefan
| Gianluca Rigoletti wrote: |
|
Hello,
Let's say I have a logboook where I define two attributes:
[TOTEM]
Comment = TOTEM Gas System Status
Attributes = Author, D, M, Y, h, min, ...
I would like to modify the "Last submission" so that I display something like %D/%M/%Y, %h:%min
so in my elogd.cfg I added this line:
Last submission = $D / $M / $Y , $h : $min by $Author
however, when display in the selection page instead of getting $min displayed i get the attribute $M+'in' displayed. How does attributes substitution work? is it case unsensitive? how does it behave when different attributes starts with the same name?
|
|
|