Conflicts:
NEWS (bug 939 was listed twice)
doc/man/man5/elinks.conf.5 (regenerated)
po/fr.po (only in comments and such)
po/pl.po (only in comments and such)
src/protocol/fsp/fsp.c (the relevant changes were already here)
*fresult pointed to nowhere. On FreeBSD *fresult == NULL
and directories weren't displayed.
Check also if safe_write writes all data.
(cherry picked from commit 06bcc48487)
cached->id => cached->cache_id
document->id => document->cache_id
onload_snippets_owner => onload_snippets_document_id
Added the distinct document->document_id.
Always reset ecmascript when a document changes for example a next chunk
of it is loaded.
This bug was revelead while using bittorrent.
For filenames started with a dot and two slashes .//
the open_bittorrent_file returned -1 and set errno to EEXIST.
elinks --config-help used to sort options like this:
document.history
document.history.global
document.history.global.enable
document.history.global.max_items
document.history.global.display_type
document.history.keep_unhistory
Now it'll instead be:
document.history
document.history.keep_unhistory
document.history.global
document.history.global.enable
document.history.global.max_items
document.history.global.display_type
i.e. all the options listed under a subheading are children of the
tree named by it. This makes elinks.conf(5) look saner.
The primary motivation for this change is that the disclaimer now
refers to the author whereas it used to refer to the copyright holder.
The ISC license is the preferred license for new code in OpenBSD.
http://www.openbsd.org/policy.htmlhttp://www.openbsd.org/cgi-bin/cvsweb/src/share/misc/license.template?rev=1.2
I am also removing the reference to "the same terms as Perl itself"
because those terms are not being distributed with ELinks. Anyway,
Perl 5 is dual licensed under the Artistic License and the GNU General
Public License (version 1 or later), and the ISC license seems GPL
compatible to me.
Without this, "make --directory=doc V=1 keymap-defaults.txt"
would not display the command it runs, because the command is
LC_ALL=C LANGUAGE=en /home/Kalle/src/elinks-0.12/doc/tools/keys2doc /home/Kalle/src/elinks-0.12/src/config/kbdbind.c keymap-defaults.txt > keymap-defaults.txt
and the build system would run
echo LC_ALL=C LANGUAGE=en /home/Kalle/src/elinks-0.12/doc/tools/keys2doc /home/Kalle/src/elinks-0.12/src/config/kbdbind.c keymap-defaults.txt > keymap-defaults.txt && LC_ALL=C LANGUAGE=en /home/Kalle/src/elinks-0.12/doc/tools/keys2doc /home/Kalle/src/elinks-0.12/src/config/kbdbind.c keymap-defaults.txt > keymap-defaults.txt
so, the initial echo was redirected to keymap-defaults.txt too,
and then overwritten with the intended output. Now, the build
system instead runs
echo 'LC_ALL=C LANGUAGE=en /home/Kalle/src/elinks-0.12/doc/tools/keys2doc /home/Kalle/src/elinks-0.12/src/config/kbdbind.c keymap-defaults.txt > keymap-defaults.txt' && LC_ALL=C LANGUAGE=en /home/Kalle/src/elinks-0.12/doc/tools/keys2doc /home/Kalle/src/elinks-0.12/src/config/kbdbind.c keymap-defaults.txt > keymap-defaults.txt
which echoes the redirection instead of executing it. This change
also makes the output correctly preserve quotes in some other rules.
If the user opens the same file again after it is in the cache, then
ELinks does not always open a new connection, so download->conn can be
NULL in init_type_query(), and download->conn->cgi would crash.
Don't read that, then; instead add a new flag cache_entry.cgi, which
http_got_header() sets or clears as soon as possible after the cache
entry has been created.
CGI scripts are distinguishable from normal files. I hope that this
fixes the bug 991. This commit also reverts the previous revert.
(cherry picked from commit 7ceba1e461)
libsmbclient's stdout and stderr interferred with ELinks's stdout
and stdin. That caused an assertion failure. Now the ELinks uses
different streams for processing of the smb protocol.
This reverts commit 7ceba1e461,
which is causing an assertion to fail if I open the same PDF
twice in a row, even if I cancel the dialog box when ELinks
first asks which program to run:
INTERNAL ERROR at /home/Kalle/src/elinks-0.12/src/session/download.c:980: assertion download && download->conn failed!
Forcing core dump! Man the Lifeboats! Women and children first!
But please DO NOT report this as a segfault!!! It is an internal error, not a
normal segfault, there is a huge difference in these for us the developers.
Also, noting the EXACT error you got above is crucial for hunting the problem
down. Thanks, and please get in touch with us.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1216698688 (LWP 17877)]
0xb7a02d76 in raise () from /lib/libc.so.6
(gdb) backtrace 6
at /home/Kalle/src/elinks-0.12/src/util/error.c:179
fmt=0x816984c "assertion download && download->conn failed!")
at /home/Kalle/src/elinks-0.12/src/util/error.c:122
cached=0x8253ca8) at /home/Kalle/src/elinks-0.12/src/session/download.c:980
cached=0x8253ca8, frame=0)
at /home/Kalle/src/elinks-0.12/src/session/download.c:1339
at /home/Kalle/src/elinks-0.12/src/session/task.c:493
(More stack frames follow...)
There is a fix available but I don't trust it yet.
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.)
