lftp has a different user interface than lukemftp, we cannot change this.

What are the advantages of lftp? What about support for UTF-8? Why is the 
user interface of lukemftp that important? Is it used as backend by other 
programs? 

Both lftp and lukemftp seem to be utf-8 aware (or at least agnostic)
See ftp.suse.com/pub/people/hai/ for an example file "ü"

Features that might not be in lukemftp:
# lftp supports SSH as a transport which is much more handy than scp or sftp.
# FTP (e.g. TIS FWTK) proxy support.
# HTTP proxy support.
# HTTPS and FTPS protocols support using OpenSSL library.
# Automatic OPIE/SKEY support in FTP protocol.
# SOCKS support
# IPv6 support in both FTP and HTTP.
# Transfer rate throttling for each connection and for all connections in sum.
# Job queueing.
# Job execution at specified time.
# `zcat' and `zmore' support.

Sure, that lukemftp works in an UTF-8 environment? I was not able to type 'ü' 
to download the UTF-8 testfile, which worked fine with lftp. Still waiting for 
an answer of Andreas, why a different user interface is a problem. I really 
like the user interface of lftp. 

Andreas, see please the comments above and comment. Thanks. 

Stefan: you're right. lukemftp doesn't support utf-8, only lftp does

It's too late to change our default ftp client for 9.1.

Let's look closer at this after 9.1 is out but for now the user interface
(lukemftp uses the well known ftp client interface that's available for years), 
is a showstopper.

Ok. You've been warned that lukemftp doesn't support UTF-8, our default 
locale. I propose to switch to lftp or maybe an other UTF-8 capable ftp client 
for 9.2. 

Just for the record: lftp has nearly the same user interface as lukemftp. If you
are speaking about a changed user interface, are you sure you don't confuse it
with ncftp?

But nearly means, that lftp does not understand such important 
commands like "bin". 

<!-- SBZ_reopen -->Reopened by sndirsch@suse.de at Tue Apr 13 18:20:41 2004, took initial reporter kernel01@hailfinger.org to cc

Let's reopen it for SuSE 9.2. :-) 

I would like to know first from Petr, if he sees any problems switching from 
lukemftp to lftp for 9.2. Of course we need to rename the binary lftp to ftp 
in lftp and the other way round in lukemftp then. Otherwise it doesn't make 
much sense. 

Petr is ill but he should come back to work tomorrow. Be patient, please.

Similar request I sended firstly on 4 Mar 2004 and drop request for lukemftp on
15 Mar 2004 with following reason:

"Doesn't develop a long time, has problem with utf8 [see #34832], but he is on
maintained products. I'd like to replace it by lftp which is extremely
developed and have a lot of features (see http://lftp.yar.ru/features.html) and
lftp is under GPL in contrast to ncftp."

Some people warning about differences (lukemftp http://.../file.zip doesn't work
with lftp, becouse lftpget is for).

Mads said: 'Changing the default ftp client to something not completely similar
is not a possibility IMO.'

And answer for Stefan: It isn't problem with renaming binary, but with some
differences in user interface, which discomfort some people. 

I forgot add mmj@ to cc:

From my comment #2: "Why is the user interface of lukemftp that important? Is 
it used as backend by other programs?" 
 
The question is still open ... 
 
Thorsten, "bin" is default in lftp. You'll need to start lftp with "-a" on  
the command line to use "ascii" mode. Is it really required to transfer ASCII 
files in "ascii" mode? I don't think so. 

The user interface is important because on Uni*x for the last 30 years, ftp
clients have behaved the same way.

Just try out lftp and tell me if it's as intuitive to you as lukemftp?

If I remeber I used lftp for 3 years and I break in very easy. I used it in
script too (for mirroring and so on). I understand that some incompatibility can
be problem, but we can try to discuss it with developer of lftp.

I use it myself, and I really like it. Especially because it can do all kinds of
protocols.

What would be great would be if it could behave like the classic ftp clients
when the binary is installed with ftp as the name.

Ok. Here are my experiences. 
 
I wanted to login as user with password. Need to call 'help' once to see that 
I need the command "user <user> [<pass>]" for this as it seems you aren't 
prompted for a username/password by lftp. I can't remember to use more than 
the commands "ls", "cd", "lcd", "bin", "hash", "get" and "mget". "bin" is no 
longer required (see comment #18 above), "hash" isn't available, most likely 
because the status is shown in a similar way as scp does. The other commands 
I mentioned are available. 
 
The question is. Do we really want to maintain a ftp client, which development 
is simply dead and will never gets fixed to support UTF-8, which is a 
requirement since 1999 according to Markus Kuhn (Bug 49832). 

No, we don't want to maintain a ftp client, which development is 
dead. But we also need to make sure, that we offer something, 
which is compareable with the current situation and with which 
everybody can work. If you say that you need to call "help" to 
login with username and password, this is already a ko criterium 
for me as replacement (maybe this is the reason, too, why no other 
distributor ships lftp as default ftp client?). 
 
We need to offer our customers something compareable with what he 
will get on most systems, not something which behaves completly  
different. We cannot change always all interfaces with every release. 
 
To make it clear: It doesn't matter for me which client we use in the future, 
as long as everybody is able to use it like he learned on other systems. 

I don't know for what reasons other distributors didn't switch to lftp yet 
(maybe because the other distros didn't switch?). But IMHO users, who use a 
command line ftp client are clever enough to type a 'help' command (which also 
exists when using lukemftp) and read the output. Some users are even willing 
to read a manual page.  
 
Nobody wants to change the ftp client (with a different interface) with every 
release. 
 
Anyway, I don't think we'll get to a consensus. As usual let the manager for 
SuSE LINUX 9.2 decide. 
 
I propose not to drop lukemftp now, but make lftp our default ftp client. And 
if there are really big problems with this decision during testing, we should 
still be able to switch back to lukemftp even during the beta period. So we 
hope to be able to drop lukemftp short after 9.2. 
 

If making lftp the default client is a problem because of a slightly different
user interface, we surely can ask the lftp developer for a "compat mode" when
lftp is called as "ftp".

Add #25: If we had such a compat mode, we would switch directly.  Can
the maintainer discuss this with the authors, please?

Ok I will contact him. If I understand it is task for 9.2 (not for sles9)?

Yes, we're talking about 9.2. :-) 

Yes, 9.2 item.

Petr, Carl-Daniel, did you already try to contact the author? 

I didn't time, bud I got following answer from author (Alexander V. Lukyanov
<lav@netis.ru>)

- think it could be done as a module, which registers its own commands.
- Then the compat mode would be initiated with `lftp -e "module compat"'.
-
- The module would contain function module_init:
- 
- extern "C"
- void module_init()
- {
-        CmdExec::RegisterCommand("get",&compat_get,"get source [dest]","get a
- file (compatible with ftp(1))");
-        ...
}

Sounds good. :-) Hopefully there will be someone who will/can write this 
module ... 

Any news on this one? Meanwhile lftp conflicts with lukemftp ... 

How come it conflicts?

/work/SRC/all/lftp/lftp.spec: 
[...] 
Conflicts:    ftp lukemftp 
 
The file "/usr/bin/ftp" conflicts. 

BTW, the conflict was removed meanwhile ... 
 
lftp.changes: 
------------------------------------------------------------------- 
Tue Aug 17 11:11:12 CEST 2004 - postadal@suse.cz 
 
- removed /usr/bin/ftp link to avoid conflict with other ftp clients [#43765] 

to comment #32, only project manager can allocate resources for this work
(author didn't start on "module compat").

Ok. I propose to ask aj to add this to the feature document, when he's back 
from vacation, so it might get a higher priority ... 

aj is back now. Andreas, would you please add this to the feature document? 

Ok, added to feature document - it's up to Vinil now to evaluate it. 

Fine. So let's reassign to Petr and take Vladimír in Cc. 

In progress: I start work on first version of compat mode.

That's definitely great news!

Thanks!

Any progress yet? 

Yes I worked on it before SL9.3 (I prepared first version of wrapper and compat
module), but then I have to work on others packages for SL9.3, because some
problem in compat mode needs more time, then I had it. Now I going continue on
this, but higher priority has now gcc 4.0 fixes. 

any progress? I still want lftp to become the default ftp client :)

Petr didn't have much time for this in the last months.
Recently Pavel Nemec has started to work on it under Petr's supervision. Estimated time to finish it is one month.

lftp_wrapper.c (/usr/bin/ftp) and CompatMode.cc (module compat-mode) packaged to STABLE. Wrapper can whole non-interactive download/upload support. Compat mode (enabled by default if wrapper is called) tried simulate most frequent commands, but the philosophy of connectig to server in lftp is differ from lukemftp, because lftp connect to server after command which really need it (ls, get ...).

Now lftp conflicts with ftp and lukemftp. Could we added lftp to default selection now? (the wrapper and compat-module needs deep testing now, to catch all bugs).

Thanks a lot for implementing all this stuff! I've always been in favor of adding lftp to default selection. So I'm afraid you'll need to ask kukuk about replacing lukemftp with lftp in our default selection. Once he agrees I'll do so in our selection.

You can change it for Beta2.

Thanks. Will do so.

done.

-------------------------------------------------------------------
Wed Jan 18 11:58:19 CET 2006 - sndirsch@suse.de

- BASIS: lukemftp --> lftp (Bug #52021)

Closing as fixed.