bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-inetutils] Readlib and FTP client again.


From: Mats Erik Andersson
Subject: Re: [bug-inetutils] Readlib and FTP client again.
Date: Thu, 8 Mar 2012 13:56:03 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

torsdag den  8 mars 2012 klockan 10:10 skrev Simon Josefsson detta:
> Mats Erik Andersson <address@hidden> writes:
> 
> > Dear all,
> >
> > söndag den 19 februari 2012 klockan 21:42 skrev Mats Erik Andersson detta:
> >> söndag den 19 februari 2012 klockan 19:24 skrev Simon Josefsson detta:
> >> > Mats Erik Andersson <address@hidden> writes:
> >> > 
> >> > > What I would like to see is an FTP client that compiles against
> >> > > "libreadline/libedit", should either be available, and otherwise
> >> > > the client should fall back to the rudimental editing capabilities
> >> > > provided by said Gnulib module. What circumstances are speaking
> >> > > against this remedy?
> >> > 
> >> > I don't know -- I think that approach seems like the right one.
> >
> > The patch set reproduced below, is able to use the update to
> > "gnulib/m4/readline.m4" which I proposed on "address@hidden"
> > two days ago. The outcome is GNU Inetutils source that is able
> > to build our FTP client with native readline support, or Gnulib
> > fall-back readline support, on
> >
> >     Debian 6.0 Squeeze,  OpenBSD 4.6, and NetBSD 5.1.
> 
> Great!  Sorry for not finding the time to work on this, I tried to start
> on it a few times, but other things intervened...
> 
> > Without update to the Gnulib module, NetBSD can never be targeted.

I.e., if we use the Gnulib module at all. Without the module, we would
need to duplicate the fall-back code, which would be unfortunate.

> > Due to the fact that "bootstrap" is not able to have any local
> > m4 macro file overriding "gnulib/m4/readline.m4", no action on
> > our part can rescue the situation if the module "readline" is
> > to be activated at all. Until "bootstrap" changes, our "am/readline.m4"
> > is dead weight while the module is being invoked.
> 
> Aren't there several ways to solve this?  1) Change the file and
> function names, 2) Change the aclocal -I ordering so our local
> readline.m4 is preferred, 3) add a gnulib override directory to patch
> upstream gnulib readline.m4 into what we want.  I'm sure there are other
> ways as well.

1) Yes, but GNUlib would be better off supporting NetBSD itself,
   which it present does not. Implementing fall-back code ourselves
   only produces superfluous duplication.

2) The upstream file "bootstrap" is misconceived, since it does not
   allow this a priori. I made an effort along this line, but it failed.
   The fact that GNU m4 allows redefining macros did not help me to
   insert out own "am/readline.m4" any later than "gnulib/m4/readline.m4".
   This would otherwise have presented a manageable route.

3) I have never heard of this possibility.

The fall-back to the Gnulib module worked well, except that I had believed
it to allow line editing, which ut turned out not to do. The history
function is expendable, but basic navigation in the command to be would
be good to offer.

Regards,
  Mats



reply via email to

[Prev in Thread] Current Thread [Next in Thread]