Hi.
In GNU SASL I use readline in the command line interface to prompt the
user for some data (e.g., username). But readline is not always
available, so I use an autoconf test:
AC_CHECK_HEADERS(readline/readline.h)
AC_CHECK_LIB(readline, readline)
AM_CONDITIONAL(READLINE, test "$ac_cv_lib_readline_readline" = "yes")
and a small replacement for readline, built as:
if !READLINE
libgl_la_SOURCES += readline.c
endif
and the code reads:
#include <stdio.h>
#include <strdup.h>
#define MAX_LINE_LENGTH BUFSIZ
char *
readline (const char *prompt)
{
char line[MAX_LINE_LENGTH];
printf ("%s", prompt);
line[0] = '\0';
fgets (line, MAX_LINE_LENGTH, stdin);
line[strlen (line) - 1] = '\0';
return strdup (line);
}
That code should obviously use getline, but before fixing that:
Do you think a "readline" module such as the above would be a
candidate for gnulib? It would make it possible for applications to
assume readline is available, and have gnulib provide a simple
fallback when it is not. Of course, it would not be a complete
implementation. And readline is not POSIX or anything. It might be
considered a GNU extension.
Alternatively, how about packaging the entire readline library as a
gnulib module? It is about 20kloc, but some of it appear to already
be part of gnulib, e.g., xmalloc. I haven't dared to look at the code
quality.
Finally, perhaps even both strategies could be implemented in gnulib?
Some applications might not want to ship the complete readline gnulib
module but would be satisfied with a small workaround.
As always, your thoughts are appreciated.
Thanks,
Simon
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
