Addendum to Martin Bøgelund's answer:
The why-question (which I assume is "why did the original attempt do what it did") is interesting, and simple when you think about it the right way: it's the same dir [remote-directory] [local-file]
syntax, where the remote directory happens to be >
. The ftp client is not a shell. Commands typed into it are not shell commands. It doesn't have redirection operators, and >
is not a special character.
Yes, you can have a directory named >
on your FTP server, as long as you aren't running it on Windows.
The ftp.exe
found in Windows is a copy of an early BSD ftp. It doesn't know about Windows filename restrictions. If you tell it to get remotefile >
it will try to save a copy of the remote file as a local file called >
, and fail because of the local filesystem limitations.
A major contributor to the confusion here is that the FTP server, receiving a LIST
command with >
as the argument, responded with a success code and an empty reply body instead of saying "No such file".