The FTP coprocess formerly wrote the output of the "get | tar vxf -" pipe
to stderr, which resulted in no output to the feedback pipe (stdout), and
thus the timeout was not updated for any line printed by the "tar" process.
This was now changed to also feed back the chars to the expect() routine,
updating the timeout handler. The "also" part is implemented by passing
the output through "tee /dev/stderr".
At least NetBSD and Solaris have this, so no problem there.
Thanks to Frank van der Linden for helping me to debug this.
- keep the case consistent between the actual name and what's referenced.
e.g, if it's `foo', don't use '.Nm Foo' at the start of a sentence.
- remove unnecessary `.Nm foo' after the first occurrence (except for
using `.Nm ""' if there's stuff following, or for the 2nd and so on
occurrences in a SYNOPSIS
- use Sx, Ic, Li, Em, Sq, and Xr as appropriate
Found during a post-install of a fresh machine:
1. setenv PKG_PATH ftp://smaug.fh-regensburg.de/pub/NetBSD/arch/i386ELF/All
2. pkg_add tcsh ssh XF86Config
3. Run XF86Config
4. pkg_add kde
5. Be done.
We should do this from /etc/rc.local on first boot... :-)
as this will remove things like trailing '}' etc. and doesn't work in general.
As mentioned in the already-existing comment, doing TRT here would mean to
partly expand the pattern, then replace the versions on alternatives.
Unless our pkg pattern parser gets these hooks, cowardly step back.
'get pkg.tgz "| cd /var/tmp/inst ; gunzip | tar -x -f -"'), handle
two cases better:
1. Timing out ftp connections: Make sure the hanging pipeline gets a ^C
(SIGINT), and wait until the ftp prompt is available again. Else we
may nuke away tar's working dir, and it may be displeased.
2. One of the commands from the pipeline exiting: caught via SIGCHLD;
for this signal to be delivered, a empty handler is needed)
Adresses PR 10925 by Greg A. Woods <woods@planix.com>
which needed to be set at compile time but weren't (to handle the case where
TAR_CMD was set to something other than "tar", eg "gtar". In addition to
the constants being wrong, the wrong directory name was being examined for
its string length.
Add a few comments to hopefully avoid having this problem come back.
a bit, to make them more descriptive
* in findbestmatchingname_fn, fix a bug where a null pointer wasn't
caught (I wonder why we didn't actually hit that case...)
* Bugfix in findbestmatchingname_fn: when comparing, strip off any
trailing ".tgz", as this will give wrong results. "1.9.8.tgz" was
found to be greater than "1.9.8.1".
hubertf