I'm not convinced that creating a new option is the solution.
I would prefer that if the first LIST -a returns an empty list, it
retries just with LIST to detect if it's a server without this
(which is likely, we don't even have . and ..)
Naturally, if there ever was a working LIST -a *or*
On Fri, 30 Aug 2013, Tim Ruehsen wrote:
Could you enlighten me about where '-a' comes from ? RFC 959 is very clear
that a param after LIST is either a filename or a directory name.
LIST -a basically works with the assumption that the server will detect that
it looks like an option and run ls
On Friday 30 August 2013 11:39:41 Daniel Stenberg wrote:
On Fri, 30 Aug 2013, Tim Ruehsen wrote:
Could you enlighten me about where '-a' comes from ? RFC 959 is very clear
that a param after LIST is either a filename or a directory name.
LIST -a basically works with the assumption that the
Hello Ángel,
I wrote some systems because in the sources is written:
/* 2008-01-29 SMS. For a VMS FTP server, where LIST -a may not
fail, but will never do what is desired here, skip directly to the
simple LIST command (assumed to be the last one in the list).
*/
so the problem with the
On 30/08/13 18:03, Andrea Urbani wrote:
Hello Ángel,
I wrote some systems because in the sources is written:
/* 2008-01-29 SMS. For a VMS FTP server, where LIST -a may not
fail, but will never do what is desired here, skip directly to the
simple LIST command (assumed to be the
