> > as this url shows http://www.htmlhelp.com/tools/validator/problems.html#amp
> 

> > it should be used an HTML entity instead of the ampersand sign.<p>
> 
> Can you please be a bit more specific? In which URL should the ampersand be
> replaced?

uhmm...

http://midas.psi.ch/elogs/Forum/page2?mode=threaded&expand=0&last=7

the bug is also a "documentation bug", infact similar tricks are also
in FAQs (FAQ 5 for example)

I tried to substitute avery occurrence of hard coded "&" with "&amp;" but it does
not do the job at all ... infact the first time the HTML code is ok, but
following a link let the browser to automatically decode html entities .. and
everything turns wrong again ... maybe the encoding should be done in
printing-to-the-browser-time ..

> > > as this url shows http://www.htmlhelp.com/tools/validator/problems.html#amp
> > 

> > > it should be used an HTML entity instead of the ampersand sign.<p>
> > 
> > Can you please be a bit more specific? In which URL should the ampersand be
> > replaced?
> 
> uhmm...
> 
> http://midas.psi.ch/elogs/Forum/page2?mode=threaded&expand=0&last=7
> 
> the bug is also a "documentation bug", infact similar tricks are also
> in FAQs (FAQ 5 for example)
> 
> I tried to substitute avery occurrence of hard coded "&" with "&amp;" but it does
> not do the job at all ... infact the first time the HTML code is ok, but
> following a link let the browser to automatically decode html entities .. and
> everything turns wrong again ... maybe the encoding should be done in
> printing-to-the-browser-time ..

BTW, the current url (taht should be perfectly well formed makes the elog not to
display attachments ... so may be thare is a problema in the query string decoding
routine ...

http://somehost.it:8080/LBNAME/?mode=full&amp;attach=1

> > > as this url shows http://www.htmlhelp.com/tools/validator/problems.html#amp
> > 

> > > it should be used an HTML entity instead of the ampersand sign.<p>
> > 
> > Can you please be a bit more specific? In which URL should the ampersand be
> > replaced?
> 
> uhmm...
> 
> http://midas.psi.ch/elogs/Forum/page2?mode=threaded&expand=0&last=7
> 
> the bug is also a "documentation bug", infact similar tricks are also
> in FAQs (FAQ 5 for example)
> 
> I tried to substitute avery occurrence of hard coded "&" with "&amp;" but it does
> not do the job at all ... infact the first time the HTML code is ok, but
> following a link let the browser to automatically decode html entities .. and
> everything turns wrong again ... maybe the encoding should be done in
> printing-to-the-browser-time ..

BTW, the current url (taht should be perfectly well formed makes the elog not to
display attachments ... so may be thare is a problema in the query string decoding
routine ...

http://somehost.it:8080/LBNAME/?mode=full&amp;attach=1

Display subject = <b>$subject</b>

is printed to the browser encoded, so that it is diplayed as is..

> Hi to all,
> 
> I've prepared a new Debian package.  This version will probably be the one
> which you'll find in Sarge/stable.
> 
> There are some invasive changes in this version which call for a serious
> test.  In accordance with a suggestion, I've changed the configuration
> mechanism.  For details, please read the NEWS.Debian file attached.
> 
> Could the Debian users who follow this forum test it and give some feedback?
> You can download the package from the following link:
> 
>   http://l10n-turkish.alioth.debian.org/debian/elog_2.5.8+r1592-1_i386.deb
> 
> Thanks in advance for your participation,

It seems to work nice to me.
Just another suggestion: I think it would be better to insert a commented out
example for all allowed parameters in the distributed  /etc/default/elog

nice work :-)

When an attached image name contains a space in its filename and attachment
display is enabled elog builds a wrong url to the image:

http://arcolog.roma2.infn.it:8080/ARCO/050309_170709/peeling+002.jpg

instead of the correct one:

http://arcolog.roma2.infn.it:8080/ARCO/050309_170709_peeling+002.jpg

The more annoing thing is that elogs hangs on this. a strace shows a select
on fd n°3 and 5 that loops forever (returning a timeout error):

send(4, "<141>Mar 23 11:36:25 elogd[22189"..., 35, 0) = 35
rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
select(1024, [3 5], NULL, NULL, {1, 0}) = 0 (Timeout)
select(1024, [3 5], NULL, NULL, {1, 0}) = 0 (Timeout)


May be the better solution is, after fixing the bug for backward
compatibility with already uploaded images, to implement a forced characters
substitution at upload time, replacing spaces and every character not in a
"allowed chars" list with an underscore

> When an attached image name contains a space in its filename and attachment
> display is enabled elog builds a wrong url to the image:
> 
> http://arcolog.roma2.infn.it:8080/ARCO/050309_170709/peeling+002.jpg
> 
> instead of the correct one:
> 
> http://arcolog.roma2.infn.it:8080/ARCO/050309_170709_peeling+002.jpg
> 
> The more annoing thing is that elogs hangs on this. a strace shows a select
> on fd n°3 and 5 that loops forever (returning a timeout error):
> 
> send(4, "<141>Mar 23 11:36:25 elogd[22189"..., 35, 0) = 35
> rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
> select(1024, [3 5], NULL, NULL, {1, 0}) = 0 (Timeout)
> select(1024, [3 5], NULL, NULL, {1, 0}) = 0 (Timeout)
> 
> 
> May be the better solution is, after fixing the bug for backward
> compatibility with already uploaded images, to implement a forced characters
> substitution at upload time, replacing spaces and every character not in a
> "allowed chars" list with an underscore

A correction:
the url generated is correct, infact modifing by hand the names of the files and
the "Attachment:" entry in the .log all works fine

the same problem happens if the filename is, for example foo.JPG and not foo.jpg :
http://arcolog.roma2.infn.it:8080/ARCO/050221_171508/Graph3.JPG
loops forever

http://arcolog.roma2.infn.it:8080/ARCO/050221_171508/Graph3.jpg
works correctly


so, elog does not like spaces in filename and/or uppercase extensions. the
solution is, IMHO, to sanify the uploaded filename at uploading time :-)

> > When an attached image name contains a space in its filename and attachment
> > display is enabled elog builds a wrong url to the image:
> > 
> > http://arcolog.roma2.infn.it:8080/ARCO/050309_170709/peeling+002.jpg
> > 
> > instead of the correct one:
> > 
> > http://arcolog.roma2.infn.it:8080/ARCO/050309_170709_peeling+002.jpg
> 
> This is on purpose. If you want to save an attachment locally and right click on
> the attachment, and select "Save link as..." in your browser, then the default
> file name is taken from the link. If your original file namw was "peeling
> 002.jpg", then you want again the same name, and not "050309_170709_peeling
> 002.jpg, because you would have to delete the date/time part of the file name
> each time which would be annoying. That's why I have chosen to put an artificial
> "/" between the date/time and the original file name. On the elog side, it's
> converted correctly back to the file name.
> 

yes I notice this after posting :-) sorry

> The problem with blanks in attachment names I could not reproduce. See this
> post, which contains an attachment with a blank in it. As you can see, this does
> not crash the server. 

Ok I can confirm this.
The problem arises, for me, when upgrading to the new version of elog having yes
some old entries with attached filenames containing spaces and/or uppercase extensions.

It seems that uploading files with spaces in the name *now* works well... so the
problem should be somewhere in the handling of existing attachments, not rised when
the attachment is uploaded with the current version of elog ... it's quite strange