Opened 3 years ago

Last modified 21 months ago

#12665 new enhancement

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

Description

This is hrev50113.

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

Change History (22)

comment:1 Changed 21 months ago by yubinr

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

comment:2 Changed 21 months 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 21 months 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 21 months 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 21 months 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 21 months 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 21 months 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 21 months 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 21 months 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 21 months 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 21 months ago by yubinr

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

comment:12 Changed 21 months 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 21 months 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 21 months 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 21 months 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 21 months 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 21 months ago by pulkomandy

Yes, tnftp (from ftp://ftp.netbsd.org/pub/NetBSD/misc/tnftp/) 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 21 months 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 http://packages.haiku-os.org/. So, to the administrator?

comment:19 Changed 21 months 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 21 months ago by yubinr

@pulkmandy, I have submitted a patch: https://github.com/haikuports/haikuports/issues/1239

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 21 months 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 21 months ago by pulkomandy (previous) (diff)

comment:22 Changed 21 months ago by yubinr

@pulkmandy, PR created but not merged yet: https://github.com/haikuports/haikuports/pull/1240

Note: See TracTickets for help on using tickets.