This reverts commit d0be89a16c, and thus
restores the ELinks 0.11 behaviour: always copy the data to a
temporary file before passing it to a MIME handler, even if the
"file:" URI scheme is being used. Previously, ELinks 0.12.GIT passed
the name of the original file directly to the handler. That was more
efficient but unfortunately gave the wrong result with local CGI.
The commit being reverted also claims to partially fix bug 238
(caching of local files). That bug is still open.
Currently, when ELinks passes the name of a local file to an external
MIME handler program, it encodes the name as a URI. Programs
typically do not expect this, and they then fail to open the file.
This patch makes ELinks instead quote the file name for the shell.
(The patch was attachment 425 of bug 991, by Witold Filipczyk.
This commit message was written by Kalle Olavi Niemitalo.)
Currently, when ELinks passes the name of a local file to an external
MIME handler program, it encodes the name as a URI. Programs
typically do not expect this, and they then fail to open the file.
ELinks should instead quote the file name for the shell.
Unfortunately, Debian has lines like this in /etc/mailcap:
audio/mpeg; xmms '%s'; test=test "$DISPLAY" != ""
If ELinks were changed to replace the %s with e.g.
'/home/Kalle/doc/Topfield/How to upgraded the Firmware(English).pdf'
(quotes included), then the quotes would cancel out and the shell
would split the file name into multiple arguments. That could even
provide a way for malicious persons to make ELinks run arbitrary
shell commands.
The examples in RFC 1524 all have %s without any quotes.
Debian has two bug reports about the quoting behaviour:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=90483http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221717
This patch therefore tries to detect whether the %s has been quoted
already, and remove the quotes if so. That way, the next patch will
be able to safely add its own quotes. This removal of quotes applies
only to mailcap files; MIME handlers defined in elinks.conf should
already be in the format preferred by ELinks.
(The patch was attachment 438 of bug 991, by Witold Filipczyk.
This commit message was written by Kalle Olavi Niemitalo.)
This version takes about 1/300 of the time of the shell version
and fixes several errors in the output, most importantly that
option descriptions were being truncated at the first empty line.
Because help2doc is run only from make update-man, and the distributed
tarballs include prebuilt man pages, people building ELinks need not
have Perl installed.
This syncs some changes (ie. -> e.g. etc.) from elinks-0.12 or beyond.
I noticed them while updating the web pages, and apologize that I will
not spent the time to attribute it to the individual commits.
(cherry picked from commit 2bfc7b3724,
omitting generated files)
This adopts customized docbook manpage header from git's
Documentation/asciidoc.conf and does away with a couple of
ugly hacks.
(cherry picked from commit 0ecc8b9d60,
omitting generated files)
In set and unset commands, the <option> must not be quoted. In the
sample protocol.user.mailto.unix setting, the internal quotes were
using some manpage syntax, resulting in incorrect HTML output.
It basically rewrites the nroff formatting of the elinks(1) manpage and
is mainly checked in separately to make it easier to review later
updates.
This corresponds to commit b09b149986
in ELinks 0.11.4rc0.GIT.
Previously, file extensions added or modified via the menu did not get
saved to elinks.conf when config.saving_style was 3 (the default).
This patch makes the file-extension dialog box call option_changed,
which then sets OPT_TOUCHED, so that the option appears modified in
the option manager and will be saved.
Reported and patch reviewed by Witold Filipczyk.
AFAIK, all bugs in it have been fixed. Some bugs may still be lurking
but they are more likely to get caught if compression is enabled.
I also replaced COMP_NOTE with static text because xgettext does not
support macros in the argument of N_.
Run: python w32.py. The server listens on port 8900.
It handles only one request. The proper output are numbers
0 through 33999. I have no free disk to test it, but I'm afraid
that the ELinks will hang on Windows after reading 65536 bytes.
Let me know of results of such a test. The ELinks must be compiled
with the zlib library.
Git describe happily picks whatever annotated tag is closest to the
commit. I make use of many annotated tags that correspond not to
ELinks releases but rather to patches posted in bugzilla or sent in
email. So with git describe, the About window can display e.g.
"email/witekfl/2008-02-29-2-g705acfa-dirty", which is not the intended
use of this tag.
In the "next" branch of git.git, git describe apparently supports a
--match option with which it could be made to consider ELinks releases
only. However, that option is not yet in any released version of Git,
and anyhow ELinks should support older versions too.
Instead of using git describe, just show the full SHA-1, like
cg-commit-id would. The About dialog box also displays VERSION
from configure.in, so it isn't even particularly useful to show
the name of the latest tag. (The commit count might help though.)
The build ID now includes both last tagged version, commit generation
since last tagged version, as well as the leading characters of the
commit ID and a flag for dirty working tree.
(cherry picked from commit c2a0d3b969)
The bug was reported by Paul B. Mahol on elinks-users. The example is
from the FTP site he provided:
ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-ia64/
Message-ID: <3a142e750802262008l6fd55be5v44207bc4479dd3fc@mail.gmail.com>
(cherry picked from commit c069403b75)
... so all the tests with responses stretching multiple lines are
actually tested in their entirety.
(cherry picked from commit aa9a847c00,
resolving a conflict due to the use of get_test_opt)
To segregate the historical commits (can't remember why),
I originally placed their pack in an alternate object store,
but later I found that a *.keep file does the job as well.
This gives a considerable speedup in git gc. It takes some
more disk space but OTOH you might then run gc more often
and have fewer loose objects.
real user sys (tested in this order)
1m15.900s 0m59.732s 0m4.336s gc after clone&graft without *.keep
0m23.162s 0m17.549s 0m1.588s gc after clone&graft with *.keep
0m06.932s 0m04.440s 0m0.588s gc after clone&graft&gc with *.keep
0m32.214s 0m24.138s 0m2.284s gc after clone&graft&gc without *.keep
Total size of .git/objects/pack/ was 90592 KiB without *.keep
and 97397 KiB with *.keep. So *.keep reduced gc time by 70-80%
but increased disk space usage by 7.5%.
deflate.c used to call inflateInit2(stream, MAX_WBITS + 32).
This makes zlib first check for a gzip header, and if it doesn't
find one, assume a zlib header. However, if the server said
"Content-Encoding: deflate", then neither header is there, and
zlib does not detect this automatically. So ELinks has to
distinguish between the gzip and deflate encodings, and tell
zlib which one was meant.
This bug resulted in blank pages at blogs.msdn.com accessed
through proxy.suomi.net.
The fully dashed form git-update-server-info is deprecated
in Git 1.5.4 and will cease to work in Git 1.6.0 (unless
PATH is modified). Use git update-server-info instead.
