| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69143
|
Tue Apr 21 09:13:45 2020 |
 | Daniel Pfuhl | daniel.pfuhl@medizin.uni-leipzig.de | Request | Linux | Windows | Mac OSX | All | Other | 3.1.4 | Re: CSS for HTML Mails |
Hi Stefan,
I pulled the code from the repository but was not able to build it.
Sorry, I'm not a developer. Is there a good documentation you can recommend on how to do this for a Windows installation incl. how to setup a build environment?
No chance to get a more recent Windows version already precompiled? ^^
Regards,
daniel
| Stefan Ritt wrote: |
|
a04faf9f is pretty old: https://bitbucket.org/ritt/elog/commits/a04faf9fa9ca74657240cdc827bd2d0ae48a9df1
It's from September 2018, where the change with the CSS has been made on Decemb er 2018. You have to pull the current version from the git repository and recompile the program yourself.
/Stefan
| Daniel Pfuhl wrote: |
|
Hmm, I'm pretty sure that we are on the latest version already.
We use ELOG V3.1.4-a04faf9f
I downloaded a fresh install binary for Windows and compared the checksums:
SHA256: 0A98485134E0D43959CB6734F977B02DC9FA884D6994CE3BA141664451FDA5E5
SHA256: 0A98485134E0D43959CB6734F977B02DC9FA884D6994CE3BA141664451FDA5E5
same same.
Or do I have to change to config in order to include the CSS in the HTML?
regards,
daniel
| Stefan Ritt wrote: |
|
The CSS has been embedded in the email end of 2018, so just upgrade your server.
https://bitbucket.org/ritt/elog/commits/5165daf35cc1fb066071827719079fe0c9aa5ffb
/Stefan
| Daniel Pfuhl wrote: |
|
Hi there,
we extensively use Logbuch as a change documentation platform.
E-Mail notifications for new entries are very important for us.
Since we store sensible data in our logbooks the server is protected by a firewall.
After the firewall was activated the HTML mails are not rendered by the Outlook Mail clients we use - when they are located in an "external" net behind the firewall. I assume that's because of the css stylesheet which is linked in the source code of the HTML mail.
Is there any chance to include the CSS information in the HTML code? Otherwise we would need to make the CSS accessable from anywhere which requires in turn that the path of the CSS file can be customized.
Any idea how to solved this issue?
Best regards,
daniel
|
|
|
|
|
|
1693
|
Tue Feb 14 17:43:15 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.1 | Re: CONCERN: Cross-platform compiling at risk |
| Steve Jones wrote: | Stefan, I am concerned that there are becoming too many Linux dependencies in terms of required libraries and header files. Although we have a replacement for the forkpty() routine, I am running into many other dependencies, the latest of which is pty.h. Aren't there guidelines in GCC that point out what is available cross-platform and what is not? For example, any SVR# (System Five, Release XX) based Unix will not include the forkpty() function, but BSD derivatives will.
Currently we are stuck at eLog 2.5.9 because of this issue. |
The whole issue with the forkpty() came from the request of the shell subsitution. I managed to compile this under Linux and under Windows, so I was under the impression that this is not too specific (although I had to use completely different approaches for Linux and Windows). Now if you tell me that this is not true, we have basically two options:
1) Make the shell substitution an option. On systems which don't have a forkpty(), don't compile it in. I guess not many people need the shell substitution. Thos people who need it have to stick to certain Unix flavours.
2) Find equivalents of forkpty() on all systems. The problem with that is that I have to rely on others like you to supply me some code for other systems and test it.
Please let me know what option you prefer. Also other users are asked for their opinion.
Best regards,
Stefan |
|
1694
|
Tue Feb 14 22:31:08 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.1 | Re: CONCERN: Cross-platform compiling at risk |
| Steve Jones wrote: |
| Stefan Ritt wrote: |
| Steve Jones wrote: | Stefan, I am concerned that there are becoming too many Linux dependencies in terms of required libraries and header files. Although we have a replacement for the forkpty() routine, I am running into many other dependencies, the latest of which is pty.h. Aren't there guidelines in GCC that point out what is available cross-platform and what is not? For example, any SVR# (System Five, Release XX) based Unix will not include the forkpty() function, but BSD derivatives will.
Currently we are stuck at eLog 2.5.9 because of this issue. |
The whole issue with the forkpty() came from the request of the shell subsitution. I managed to compile this under Linux and under Windows, so I was under the impression that this is not too specific (although I had to use completely different approaches for Linux and Windows). Now if you tell me that this is not true, we have basically two options:
1) Make the shell substitution an option. On systems which don't have a forkpty(), don't compile it in. I guess not many people need the shell substitution. Thos people who need it have to stick to certain Unix flavours.
2) Find equivalents of forkpty() on all systems. The problem with that is that I have to rely on others like you to supply me some code for other systems and test it.
Please let me know what option you prefer. Also other users are asked for their opinion.
Best regards,
Stefan |
Stefan et al.
I think it would be preferrable if we could find a routine that performed the same function but that was available under Windows/Linux/Unix. Question: Is the functionality really just to issue an arbitrary command-string to a "shell" and have the result stuffed back into an eLog variable? I'm not an expert but it would seem that such a feature would be universally available or could be used to construct a suitable routine.
If possible, could one use the int system(const char *s); function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps char *tmpnam(char *s); , running a command via int system(const char *s); , then opening that file for a read would accomplish what is being desired?
|
|
|
1696
|
Wed Feb 15 18:25:15 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.1 | Re: CONCERN: Cross-platform compiling at risk |
| Steve Jones wrote: | Question: Is the functionality really just to issue an arbitrary command-string to a "shell" and have the result stuffed back into an eLog variable? I'm not an expert but it would seem that such a feature would be universally available or could be used to construct a suitable routine.
If possible, could one use the int system(const char *s); function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps char *tmpnam(char *s); , running a command via int system(const char *s); , then opening that file for a read would accomplish what is being desired?
|
Indeed the results from the "shell" need to be stuffed back into an elog attribute, that's why you cannot use the system() function directly. The idea with the tmpnam() could however be a clever workaround. I have to see if this works under Windows. If so, it would be a much more portable alternative to forkpty(). |
|
1697
|
Wed Feb 15 19:02:32 2006 |
| Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.1 | Re: CONCERN: Cross-platform compiling at risk |
| Steve Jones wrote: |
| Stefan Ritt wrote: |
| Steve Jones wrote: | Question: Is the functionality really just to issue an arbitrary command-string to a "shell" and have the result stuffed back into an eLog variable? I'm not an expert but it would seem that such a feature would be universally available or could be used to construct a suitable routine.
If possible, could one use the int system(const char *s); function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps char *tmpnam(char *s); , running a command via int system(const char *s); , then opening that file for a read would accomplish what is being desired?
|
Indeed the results from the "shell" need to be stuffed back into an elog attribute, that's why you cannot use the system() function directly. The idea with the tmpnam() could however be a clever workaround. I have to see if this works under Windows. If so, it would be a much more portable alternative to forkpty(). |
Yes, these routines are from the standard C libraries. tmpname() returns a pointer to a filename guaranteed to be unique, then you can create that file. tmpfile() actually creates a temporary file and returns a pointer to the filestream, and auto cleans up upon stream termination. system() passes the command string to the shell/commandproc if available. You could wrap these into a single callable function that is called 'shell()' and accomplish your first gola plus achieve cross-platformness again ;->
My 2 cents - hope that is enough!
|
|
|
1698
|
Fri Feb 17 13:31:00 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.1 | Re: CONCERN: Cross-platform compiling at risk |
| Steve Jones wrote: | If possible, could one use the int system(const char *s); function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps char *tmpnam(char *s); , running a command via int system(const char *s); , then opening that file for a read would accomplish what is being desired?
|
I implemented exprimentally such a code. Instead of tmpnam() (which the compiler claims to be obsolete), I use a hard-wired file name /tmp/elog-shell for that purpose. I put it under /tmp so that the "elog" user (under which elog should normally run) is able to write to. Can you please check if that works fine now under Solaris? |
|
1699
|
Mon Feb 20 17:50:33 2006 |
 | Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.1 | Re: CONCERN: Cross-platform compiling at risk |
| Stefan Ritt wrote: |
| Steve Jones wrote: | If possible, could one use the int system(const char *s); function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps char *tmpnam(char *s); , running a command via int system(const char *s); , then opening that file for a read would accomplish what is being desired?
|
I implemented exprimentally such a code. Instead of tmpnam() (which the compiler claims to be obsolete), I use a hard-wired file name /tmp/elog-shell for that purpose. I put it under /tmp so that the "elog" user (under which elog should normally run) is able to write to. Can you please check if that works fine now under Solaris? |
The compiled version runs fine under Solaris9. When executing Subst Subject = $shell(uname) I got:
"SunOS" !!! ;->
So, short of the items I pointed out below I would say that you have successfully re-rendered eLog as a truly cross platform application once again! My hat is off to you!
thanks
Steve |
|
69638
|
Wed Feb 1 11:31:10 2023 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 3.1.4 | Re: CKeditor Settings Cant Be Changed |
elogd checks for the "scripts/ckeditor/ckeditor.js" file to detect the presence of CKeditor.
| James Smallcombe wrote: |
|
I wanted to change some CKeditor settings so tried modifying elog/scripts/ckeditor to no avail.
I wiped elog/scripts/ and dropped a fresh download of CKeditor4, with only the basic extensions. But when I open the elog it still shows the full toolbar, with elog default style and with all extensions operational.
If I leave elog/scripts empty, I get "CKeditor NOT detected" when starting elogd and the HTML option is empty and shows nothing, all as expected.
Does anyone understand this? Is there some CKeditor configuration file elog is defering to that I've overlooked? I have tried system wide seaches just in case.
|
|