elinks.1.in, elinkskeys.5, and elinks.conf.5 are included in the Git tree,
so they are initially in the srcdir, and that's were the new versions must go.
(cherry picked from commit 9cae6a4fa4)
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 by Witek; original patch by me; adapted to 0.11 by Witek;
commit message by me. --KON ]
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.
Update elinks.conf(5) while at it.
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>
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]
ELinks does not yet work with Lua 5.1 (see bug 742),
so the configure script should not suggest that it does.
When bug 742 is eventually fixed, ELinks should probably
prefer Lua 5.1 over 5.0, as the newer version seems likely
to be kept installed longer.
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.
(cherry picked from commit a3d093bd25
but moved the NEWS entry into the 0.11.4rc0 section)
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.11.4rc0 section)
With Autoconf 2.60a, the default values of datadir, infodir, and
mandir refer to ${datarootdir}. If Makefile.config.in does not define
datarootdir, Autoconf detects this and expands ${datarootdir} when it
substitutes expressions like @datadir@, but it also outputs the
following warning:
config.status: creating Makefile.config
config.status: WARNING: /home/Kalle/src/elinks/Makefile.config.in seems to ignore the --datarootdir setting
According to a comment in config.status, "This hack should be removed
a few years after 2.60." So it seems best to prepare for that now by
defining datarootdir = @datarootdir@ in Makefile.config.in. Earlier
versions of Autoconf may leave that line unexpanded; but because the
makefiles do not directly refer to ${datarootdir}, there's no harm.
(cherry picked from commit 388b1b0efd)
Use the localedir variable so configure's --localedir option is
honoured. Expand the variable twice to first expand the datadir
and then the prefix variable referenced by datadir.
Noticed by Witold, who also made a similar fix (modulo --localedir)
in elinks-0.12 098fb87065.
get_keymap_id returns -1 when it can't find the keymap. Because the return
type of get_keymap_id is enum keymap_id and enum keymap_id did not have any
explicit values defined, it could be unsigned, which meant that when
get_keymap_id returned -1, it was really returning a huge positive number.
This meant that when callers checker whether the return value was negative,
they were essentially performing no check at all, so they might give
get_keymap_id an invalid keymap name, get back an invalid keymap_id, and
use that invalid keymap_id.
This commit adds KEYMAP_INVALID = -1 to enum keymap_id and makes all
functions that deal with the enumeration use that symbol.
The previous check (integer > (off_t) integer * 10) did not detect all
overflows. Examples with 32-bit off_t:
integer = 0x1C71C71D (0x100000000/9 rounded up);
integer * 10 = 0x11C71C722, wraps to 0x1C71C722 which is > integer.
integer = 0x73333333;
integer * 10 = 0x47FFFFFFE, wraps to 0x7FFFFFFE which is > integer.
Examples with 64-bit off_t:
integer = 0x1C71C71C71C71C72 (0x10000000000000000/9 rounded up);
integer * 10 = 0x11C71C71C71C71C74, wraps to 0x1C71C71C71C71C74
which is > integer.
integer = 0x7333333333333333;
integer * 10 = 0x47FFFFFFFFFFFFFFE, wraps to 0x7FFFFFFFFFFFFFFE
which is > integer.
It is unclear to me what effect an undetected overflow would actually
have from the user's viewpoint, so I'm not adding a NEWS entry.
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.
It is unlikely because the standard members of struct sockaddr_in
(sin_family, sin_port, sin_addr) already require at least 8 bytes
and I don't know of any system that has size_t larger than that.
Besides, at least glibc pads the structure to 16 bytes.
When get_pasv6_socket was merged into get_pasv_socket on 2005-04-15,
the AF_INET6 of get_pasv6_socket was lost and the merged function
always returned AF_INET sockets. This then made getsockname fill
only part of the struct sockaddr_in6, and ELinks sent to the server
an EPRT command that had half the bits missing from the IPv6 address.
At least ftp.funet.fi then rejected the command, helpfully saying
what the address should have been.
This commit fixes active FTP over IPv6. Passive FTP was already fixed
in 0.11.3.GIT (887d650efe), on 2007-05-01.
