features:
---------
* transfer rate throttling with the new `rate' command. syntax:
rate direction [max [incr]]
where direction is `all', `get' or `put'.
if max is not supplied, the current settings are displayed.
if max is supplied, then transfers in the given direction will
be throttled to this value.
if incr is supplied, the increment for the `on-the-fly' scaling
will be set to that, otherwise `1024' is used.
currently implemented for binary get, binary put, and url fetches.
not yet supported for ascii get or put, or local file copies.
* on-the-fly scaling of the throttle based on signals:
- SIGUSR1 raises the throttle rate by the increment for that direction
- SIGUSR2 lowers the throttle rate by the increment for that direction
* -T dir,max[,incr] option to set rate from the command line
* `k', `m', `g' suffix support for bytecounts in the `hash', `rate',
`rcvbuf' and `sndbuf' commands)
bug fixes and code mods:
------------------------
* fix up ftp_login() so that ruserpass() is always called, even for
command-line url fetches.
* implement strsuftoi(), which parses a given number into a int with
suffix support. replaces getsockbufsize()
* implement parserate(), which does the argv parsing for -T and rate
* save and restore errno in signal handlers (may not be necessary, but
it doesn't hurt)
notes:
------
the rate command has had reasonable testing, but I'd like feedback
if it doesn't do the right thing, especially from people on slower
(i.e, modem) links.
I haven't tested the rate throttle against a http server which does
`transfer-encoding: chunked' because I couldn't find a server to
test against.
transfer stats are printed when verbose is enabled even if ftp is compiled
with -DNO_PROGRESS/-DSMALL. this adds back some feedback that existed
in traditional ftp that was lost when i added the progress meter. (noticed
when ftp-ing from the -DSMALL version of ftp that's on the 1.4 boot floppy)
to 0,0 was unnecessary because wclear() is documented to do that. also,
the immediate wrefresh() done by msg_clear() means that if we can take
advantage of full screen clear sequence, we will.
is _bogus_ in the face of printf-like message formatting! Instead,
calcuate the max size to format when the message window is set. We know
that we'll never want to format more characters than can fit in the window.
NO_PROGRESS. -DSMALL still implies all of those. progress meter support
isn't necessary for the smallest possible ftp client, but it adds very
little space and makes users' lives much better. Therefore, it should
be enabled for installation media if at all possible.
(say width or height).
* work harder to make menu fit width-wise. (if necessary, move the menu
further left, and if that's not good enough exit with an error.)
* move menu system initialization out of process_menu() so that it can
be called earlier (e.g. by the sysinst main()), since it initializes
curses and other code might want to access the curses data structures
before process_menu() is invoked.
which is one too many). Also, msgc manual page says that 'def' and 'val'
can be the same string, but the way input was done (characters typed
went directly into val) meant that the contents of 'def' would be corrupted.
If the user backspaced to the beginning of the line and hit return (to accept
the default), they'd get a combination of the old default string and the
new characters they typed. alloca() a buffer an put new input there to
avoid this problem.
they check at that level whether or not to build binaries.
A reference to telnet was also here (protected by .if make(obj)...,
but since A) it's already referenced in the main SUBDIR list and b)
the telnet Makefile does this checking as well, it's gone too.
