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.
(cherry picked from commit 81f8ee1fa2)
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)
The comment said "it is not possible to call kill_timer from a timer
handler." Sure, such calls used to crash occasionally, but that was
bug 868 and has already been fixed.
The second argument of PERL_SYS_INIT3 should be a char ***
but ELinks was giving it a char *(*)[1].
Also, enlarge the array to 2 elements, so that my_argv[my_argc] == NULL
like in main(). PERL_SYS_INIT3 seems hardly documented at all so I'm
not sure this is necessary, but it shouldn't hurt.
(cherry picked from commit 8d0677e76a)
Without this patch, ELinks showed garbage at
<http://www.dwheeler.com/oss_fs_why.html> when bzip2 decompression was
enabled. safe_read() in bzip2_read() did not see all of the body
bytes that ELinks had received from the server. After bzip2_read()
received EAGAIN from safe_read() and returned 0, something skipped
1460 bytes.
decompress_data() apparently assumed that read_encoded() returning 0
meant the end of the file, and returned even though len still was
nonzero, i.e. it had not yet written to the pipe all the data that
the caller (read_chunked_http_data() or read_normal_http_data()) had
provided. The caller did not know this, and discarded the data.
(cherry picked from commit 7e5e05ca60)
*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)
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.
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.)
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)
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.
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)
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.
Previously, bzip2_decode_buffer and deflate_decode_buffer left
*new_len unchanged if the compressed input data ended unexpectedly.
This behaviour was also inherited by decode_encoded_buffer,
whose only caller render_encoded_document preinitializes the variable
and so did not crash.
With this change, the functions now store in *new_len the number of
bytes that were successfully decoded, even if more bytes were expected.
An error should perhaps be reported to the user, but I don't think the
previous version did that either, as it returned a non-NULL pointer.
If a newline has a backslash in front of it, then str_rd replaces it
with a space. However, the newline was in the original config file,
so the line number must still be incremented.
On AMD64 apparently, off_t is long but ELinks detected SIZEOF_OFF_T == 8
and defined OFF_T_FORMAT as "lld", which expects long long and so causes
GCC to warn about a mismatching format specifier. Because --enable-debug
adds -Werror to $CFLAGS, this warning breaks the build. When both
SIZEOF_LONG and SIZEOF_LONG_LONG are 8, ELinks cannot know which type
it should use.
To fix this, do not attempt to find a format specifier for off_t itself.
Instead cast all printed off_t values to a new typedef off_print_T that
is large enough, and replace OFF_T_FORMAT with OFF_PRINT_FORMAT which
is suitable for off_print_T altough not necessarily for off_t. ELinks
already had a similar scheme with time_print_T and TIME_PRINT_FORMAT.
There are warnings about casts in the Debian amd64 build logs:
http://buildd.debian.org/fetch.cgi?&pkg=elinks&ver=0.11.3-2&arch=amd64&stamp=1200348983&file=log
[CC] src/intl/gettext/dcigettext.o
/build/buildd/elinks-0.11.3/src/intl/gettext/dcigettext.c: In function '_nl_find_msg':
/build/buildd/elinks-0.11.3/src/intl/gettext/dcigettext.c:745: warning: cast from pointer to integer of different size
/build/buildd/elinks-0.11.3/src/intl/gettext/dcigettext.c:746: warning: cast from pointer to integer of different size
...
[CC] src/network/ssl/socket.o
/build/buildd/elinks-0.11.3/src/network/ssl/socket.c: In function 'ssl_connect':
/build/buildd/elinks-0.11.3/src/network/ssl/socket.c:219: warning: cast to pointer from integer of different size
The warnings in _nl_find_msg were caused by alignof, which I already
fixed. This commit ought to fix the gnutls_transport_set_ptr call in
ssl_connect. This warning did not yet happen in bug 464384 because
the others broke the build before it got that far.
This patch prevents handle_itrm_stdin() and clear_handlers(itrm->in.std) to be
called when -remote is set and in.std < 0.
It adds two assertions for in.std >= 0 in handle_itrm_stdin() and
unhandle_itrm_stdin().
May be a bad fix, please test and review.
[Added a NEWS entry. --KON]
Do not clear the IXON flag in termios.c_iflag.
Bug 54 did not actually ask for this flag to be kept,
but the cable I am using doesn't seem to have the handshake
lines connected right, so XON/XOFF is a must at 38400 bps,
at least until ELinks learns to send padding based on terminfo.
Any user who has bound actions to Ctrl+S or Ctrl+Q and finds that
they no longer work should just "stty -ixon" before running ELinks.
We don't have any default bindings for those keys, fortunately.
Actually, don't use the cfmakeraw function at all,
and don't look for it during configure either.
(cherry picked from commit 87f1661314
but moved the NEWS entry into the 0.12 section)
Previously, it only pretended to rewrite the configuration file, so it
set or cleared OPT_MUST_SAVE but never changed or output any options.
Now, it actually sets the options when ELinks is loading the
configuration file. Also, when ELinks is rewriting the configuration
file, it now compares the values in the included file to the current
values of the options, and sets or clears OPT_MUST_SAVE accordingly.
