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

[Mats Erik Andersson]

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.
> 
> Btw, the reason for not using the readline module from gnulib was that
> InetUtils doesn't meet the requirements for that module -- the
> "readline" module in gnulib is intended for packages that only need the
> "readline" function.  InetUtils needs more than that, it uses
> add_history as well.  This is just an explanation, I'm not saying this
> is ideal, but to do something differently we need some patches.

That is in line with my desire:

   libreadline or libedit:   editing and history available

   otherwise:     only editing available (improvement on TFTP client)

How about this outline:

  * Use Gnulib module by default.

  * The presence of <readline/readline.h> takes prescedence,
    by the implementation of the module. Thus line editing
    is available at all times.

  * Should HAVE_READLINE_HISTORY_H be set, then activate inclusion
    of <readline/history.h> as well as issue the calls to add_history(3)
    in both of "ftp/main.c" and "ftp/cmds.c".

This takes care of libreadline for us. However, "gnulib/lib/readline.c"
is not per se conceived to detect libedit, like I implemented it in
our "inetutils/am/readline.m4", which is one clause richer than the
corresponding "gnulib/m4/readline.m4".

I suggest that Simon implements the above outline, and that I run the
result agains NetBSD (where editline wraps around readline), the checking
whether fine tuning would be needed, or whether the duplicate prototype
for readline(3) turns out to be harmless.

> > The benefit would be a an FTP client that at all times is capable
> > enough to use in scripts, although users might miss the history
> > support, should they have been unattentative at build time.
> >
> > In the present situation, the failure to build the FTP client
> > will lead to a system dependent failure when generating the
> > manpages using "help2man". I believe to recall at least two
> > machines aborting the first build step due to this mistake.
> 
> What is the error message?  Why doesn't the FTP client build?

When libreadline-dev is missing, the client is never built,
but any system, where help2man(1) is detected as available
during the configuration step, will unleash the action

   make -C man/
   ...
   make man TOOL=ftp SECTION=1

which will fail due to

   help2man: can't get `--help' info from ../ftp/ftp

It seems to me that "man/Makefile.am" must only activate
those manpages that correspond to actually enable executables,
i.e., must correlate better with ENABLE_*. The exact mechanisms
in that file are a mystery to me!

Since none of my BSD or Solaris system have help2man(1) install,
they never stumble into this trap, but most Debian sytems do!

Best regards,
  Mats