Научить консольный софт автокомплитить

Умеет, наверняка, судя по докам (правда написано всё недоходчиво).

Пока читал, встретил

The function readline() prints a prompt prompt and then reads and returns a single line of text from the user. If prompt is NULL or the empty string, no prompt is displayed. The line readline returns is allocated with malloc(); the caller should free() the line when it has finished with it.

Разве это правильно (вызов malloc и free из возможно разных модулей)? Я ведь могу слинковать std статически, -lreadline динамически. Readline должен давать свою rl_free(). Вроде серьёзная либа с историей, а какие-то детские ошибки. Или какой-то секрет есть?

Ты описал свои фантазии на тему решения некой задачи, но не описал саму задачу?

да вроде все описал: вводим в консоли - p, пробел, таб; получаем список файлов из /usr/share/app/mode_p. Вводим в консоли - r, пробел, таб; получаем список файлов из /usr/share/app/mode_r.

readline умеет и автодополнение, и историю, и редактирование.

returns is allocated with malloc(); the caller should free()

ничего страшного в этом нет.

readline умеет и автодополнение

бесспорно, но надо учесть код команды (p или r) для выбора префикса, по которому лежат файлы (без нажатия Enter).

ничего страшного в этом нет.

Похоже что так и есть, попытался слинковать:

# mv /usr/lib/libreadline.a /usr/lib/libreadline.a~
# g++ m.cc -lreadline -static
/usr/bin/ld: cannot find -lreadline
collect2: error: ld returned 1 exit status
# mv /usr/lib/libreadline.a~ /usr/lib/libreadline.a
# g++ m.cc -lreadline -static

в общем-то не знал, что нельзя сделать статико-динамический винегрет.

Сделать можно, но не так. -static делает статический бинарь. Убери его и укажи явно путь к libreadline.a вместо -lreadline.

Убери его и укажи явно путь к libreadline.a вместо -lreadline

При таком раскладе, libreadline.a будет линковаться с malloc() из libc.so, а не libc.a

Щито?

может bash-completion подойдёт?

не, у меня же софтина своя.

просто разработчики софта обычно сопровождают и устанавливают со своей программой файл для bash-completion, наверняка это способ менее трудозатратный

ls /usr/share/bash-completion/completions|wc -l
894

Это прикольно, но я ввожу команды в цикле софтины (когда она запущена), там баш комплишен бесполезен ведь.

извини, не понял сразу что нужно

без проблем

Я тут подумал, наверное действительно так и сделаю - уберу внутренний цикл с ридлайн и вынесу всё наружу с баш комплишн. Спасибо, направили.

ну и славненько, ато я уже возмущаться хотел, нахрена тебе интерактивное поведение как, например, у питон-консоли или мускуль-сессии прямо во время работы, но ты и сам догадался.

При таком раскладе, libreadline.a будет линковаться с malloc() из libc.so, а не libc.a

Нет. С чего бы? Но даже если гипотетически это каким-то чудесным образом произойдёт, что в этом плохого?

На случай, если кто-то придёт сюда за ответом на ОП: можно задать rl_attempted_completion_function, в которой смотреть на значение rl_line_buffer, а дальше rl_filename_completion_function после chdir(), наверное, сработает.

Нет. С чего бы?

Не пойму, что в этом удивительного?

#include <iostream>
#include <readline/readline.h>
int main()
{
    readline("enter val: "); // не заходим в первый, пропустим стадию переразмещений
    readline("enter val: ");
    readline("enter val: ");
}

$ g++ -g m.cc /usr/lib/libreadline.a /usr/lib/libncursesw.a

(gdb) b main
# пропускаем первый вызов readline
(gdb) b malloc
(gdb) c
(gdb) disassemble
Dump of assembler code for function __GI___libc_malloc:
=> 0x00007ffff7ab2770 <+0>:     mov    0x132769(%rip),%rax        # 0x7ffff7be4ee0
...
(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
...
0x00007ffff7a4e340  0x00007ffff7b95fab  Yes         /usr/lib/libc.so.6

Не сложно заметить, что попали в динамическую libc.so

Но даже если гипотетически это каким-то чудесным образом произойдёт, что в этом плохого?

Нет в этом ничего плохого, это наоборот - хорошо. Не должно быть в одной программе несколько версий libc, нельзя в одной делать malloc, а в другой free. Когда я в посте выше попытался заставить сделать это, gcc отказался стрелять мне в ноги, что стало для меня открытием.

спасибо, для общего развития тоже гляну.

а, это я неправильно прочитал сообщение и судя по коменту «Щито?» не я один :)