fetch -c /somedir -f somefile -h server is _quetly_ translated into fetch -c somedir -f somefile -h server which, of course, breaks if the user's home directory on the server is not / Fix: Use some other tool. Providing extra slashes does not help How-To-Repeat: setenv FTP_LOGIN your_login setenv FTP_PASSWORD yourPassword fetch -v -v -v -v -c /tmp -f fixit.flp.bz -h www ... User your_login logged in. Sending: TYPE I Type set to I. Sending: CWD tmp tmp: No such file or directory. fetch: www: tmp: File unavailable (e.g., file not found, no access) Same problem occurs when using the URL mode as in fetch -v -v -v -v -o - ftp://www//tmp/fixit.flp.bz Same result as above.
State Changed From-To: open->closed Fetch takes a URL. This is how ftp: URL's work. Use ftp://some.host/%2Cdirectory/ if you want a real slash. (Technically, ftp://some.host//directory/ means to perform a sequence of commands which violates the FTP protocol, which is why fetch silently drops the extra slash). I addressed this issue in the man page but forgot to commit it; mea culpa.
State Changed From-To: closed->open The bug is about "-c", not the URL syntax. I didn't read it carefully enough. There's an XXX comment in main.c describing the fix to this bug; the solution to this PR is to implement the fix described in the comment. Sorry for jumping the gun on closing the PR.
In message <199805090731.AAA15743@freefall.freebsd.org> you write: >ftp://some.host/%2Cdirectory/ if you want a real slash. Of course, I meant %2F. And I skipped over the part where the original complaint was about the "-c" flag. Checking the code, this problem was thought of but not addressed: /* * XXX - we should %-map a leading `/' into `%2f', but for * anonymous FTP it is unlikely to matter. Still, it would * be better to follow the spec. */ So, for now, use the ftp://some.host/%2Fdirectory/ URL form, and someone should fix fetch to do what the comment says to do. Bill
State Changed From-To: open->closed Fixed in -current and -stable.