Opened 3 years ago

Closed 7 weeks ago

Last modified 7 weeks ago

#12665 closed enhancement (fixed)

Tab-completion of ftp missing "/" after directories (easy)

Reported by: humdinger Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Applications/Command Line Tools Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


This is hrev50113.

ssh and Terminal add a "/" when you tab-complete directories. ftp doesn't, which interrupts my flow...

Change History (25)

comment:1 Changed 2 years ago by yubinr

I would like to work on it. Seems trivial, right?

comment:2 Changed 2 years ago by axeld

Solving the actual issue should indeed be trivial. However, there are a number of additional tasks that one could pursue:

  • We use an ancient copy of FreeBSD's Luke FTP (from 2005). We could update it to a recent version; that might even fix the issue already.
  • If that update doesn't fix it, one could try to upstream the changes that do.
  • We could outsource the FTP application to haikuports. There is no real need to keep it in the tree.

So if you have a bit of time on your hands, and want to get in touch with some more parts of Haiku... :-)

comment:3 Changed 2 years ago by yubinr

Seems not so trivial, though. The FTP client receive file names from FTP servers with no extra info, which means that we can't not tell whether a name is a file or a directory. Worse, there are many symbolic links in many FTP servers, and that makes it more difficult for us to distinguish files and directory.

comment:4 Changed 2 years ago by axeld

Can't you just "stat" all results, and simply add a "/" when an entry is a directory, before adding it to the completion list? Another (faster, but possibly not trivial anymore) alternative would be to extend remglob() to return that information as well.

In any case, the upstream FTP version does not implement this yet either.

comment:5 Changed 2 years ago by pulkomandy

@axeld: not really, because FTP does not standardize the format of the reply to ls. Basically yhe idea is that the remote computer runs whatever "ls -l" they have and pipes that to the socket. It was not designed to be machine-parsed.

There is a (very long) piece of code in WebKit (inherited from khtml) for parsing many of the possible known formats, which we could reuse. But I think the best way to go about this is porting some better FTP client (maybe lftp?) as a recipe, and remove this old one from Haiku.

comment:6 Changed 2 years ago by tangobravo

Although remote tab-completion would indeed be nice, are we sure humdinger didn't mean tab-completion for local directories wasn't working?

I haven't tried it, but to me it seems weird for this to be tagged "easy" if it was about remote ones.

comment:7 Changed 2 years ago by yubinr

@axeld @tangobravo I agree with @pulkomandy. I have read the src and try to change the behavior of the `remglob()' function. But there are two difficulties: 1) the format between ftp clients and servers are not standardized 2) If we want this behavior we would possibly have to discard this implementation of ftp and port a new one into haiku, otherwise the code would be a mess.

comment:8 Changed 2 years ago by humdinger

Tab completion for local folders work, complete with "/". I just imagined it to be easy, as ssh does it. I may have been wrong there... :)

comment:9 Changed 2 years ago by axeld

I know FTP doesn't standardize the format of "ls"; however, I was under the impression that the ftp client already had a parser for that that could be utilized -- if that isn't the case, it's indeed a bit too complex to be worth it.

I agree that we might want to replace the ftp client with another one long term, although I wouldn't mind having this one around as an external package, either (as it's relatively tiny). Patches welcome :-)

comment:10 Changed 2 years ago by yubinr

@axeld Hmm...we can port the newest version of luke ftp(which belong to NetBSD, not freebsd) to the current implementation, which would be easier, but not helpful, as it still do not have auto-completion as bash. In another way, we can port `lftp', which have everything you want.

What do you think ?

comment:11 Changed 2 years ago by yubinr

well, seems that there is already a lftp haiku-port. So, we still need this on, right?

comment:12 Changed 2 years ago by pulkomandy

We should port a simple FTP client too (luke FTP or something similar) so that people can find the "ftp" command as expected (and we can include this small one in the default Haiku install). We should make it a package and remove it from Haiku sources, this way people will not ask us for feature improvements :).

Then we can suggest people to use "lftp" instead if they want advanced features.

comment:13 Changed 2 years ago by yubinr

@pulkomandy I still can not get your point. You mean we upgrade the luke ftp in haiku(keep it simple) and package a new one?

comment:14 Changed 2 years ago by pulkomandy

  • Remove the Luke FTP in Haiku sources
  • Write a recipe for Haikuports for Luke FTP (up to date version)
  • Include the Luke FTP package built from the recipe in Haiku images (like we do for openssh, etc)

comment:15 in reply to:  14 Changed 2 years ago by yubinr

  • Remove the Luke FTP in Haiku sources
  • Write a recipe for Haikuports for Luke FTP (up to date version)
  • Include the Luke FTP package built from the recipe in Haiku images (like we do for openssh, etc)

Ok, let's try.

comment:16 Changed 2 years ago by yubinr

@pulkmandy Is it ok to replace the ftp port with ntftp in haikuporst? It seems that there is no ftp in NetBSD's source anymore.

And we definitely have to upgrade the `lftp' program. It is so outdated.

So far,

1) removing the Luke FTP in Haiku sources is done 2) recipe for update-to-date Luke FTP is done (actually `tnftp' in the NetBSD source)

I am working moving the package to Haiku's image

comment:17 Changed 2 years ago by pulkomandy

Yes, tnftp (from seems to be the current version of LukeM FTP under a new name. It is actually a good thing that it comes in a separate archive so we don't have to extract it from the *BSD sources.

comment:18 Changed 2 years ago by yubinr

@pulkmandy Probably I should put the name of the generated .hkpg package in "build/jam/repositories/Haikuports/x86_64", but, who should I submit the package to? I notice that the repo is on So, to the administrator?

comment:19 Changed 2 years ago by pulkomandy

You should submit your recipe at haikuports. Someone from the Haiku project will then rebuild the package from that and upload it.

You don't send us the binary package, because you are relatively unknown to the team, and maybe you could be trying to send a tampered package that would spy on our users or something. So the binaries in the package repo are only from people we know and think they won't do things like that.

Once you have the recipe ready, I can handle building the package and adding it to the repository and the build/jam/repositories, at least for x86_gcc2 (which is what I use). I'm sure we can find someone to do it for the other architectures too. And only then we can remove the ftp code from Haiku.

comment:20 Changed 2 years ago by yubinr

@pulkmandy, I have submitted a patch:

I am sorry I cannot create a pull request because I didn't fork directly from the main repo, but clone and then push afterwards.

comment:21 Changed 2 years ago by pulkomandy

You can create a fork after doing that and add it to your remotes. The "hub" command line tool can be used to work with github forks and pull requests:

pkgman install hub # if it is not in the x86_64 repo yet, you will need to build it with haikuporter instead
hub fork
git push
hub pull-request
Last edited 2 years ago by pulkomandy (previous) (diff)

comment:22 Changed 2 years ago by yubinr

@pulkmandy, PR created but not merged yet:

comment:23 Changed 7 weeks ago by PtrNull

This issue seems to be fixed? I have test on beat1, It has been working normally. @pulkmandy

comment:24 Changed 7 weeks ago by pulkomandy

Resolution: fixed
Status: newclosed

Indeed, ftp was replaced by the more up to date tnftp, fixing this in the process. Thanks for checking!

comment:25 Changed 7 weeks ago by humdinger

I still see it exactly as described in the ticket with hrev52947, 32bit... Reopen?

Note: See TracTickets for help on using tickets.