[Top][All Lists]
[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: |
Sun, 19 Feb 2012 21:42:29 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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