Использование readl's rl_insert_text на OS X 10.5 - PullRequest
Новая
       13

Использование readl's rl_insert_text на OS X 10.5

2 голосов
/ 09 июня 2009

Итак, я пытаюсь вставить некоторый текст по умолчанию в пользовательский ввод, используя readline, и не могу заставить его работать на OSX 10.5: 

// rl_insert_text_ex.c
// gcc -o rl_insert_text_ex rl_insert_text_ex.c -lreadline
#include <stdio.h>
#include <readline/readline.h>

int my_startup_hook(void) {
  return rl_insert_text("ponycorns");
}
int main(int argc, char *argv[]) {
  char *line;
  rl_startup_hook = (Function*) my_startup_hook;
  line = readline("What's your favorite mythical animal? ");
  if (NULL == line || '\0' == *line) {
    printf("Nothing given... :(\n");
  }
  else {
    printf("That's funny, I love %s too!\n", line);
  }
  return 0;
}

Этот код даже не компилируется в 10.4 (нет определения для _rl_insert_text в 10.4, что немного обломало), но компилируется в 10.5. Однако текст rl_insert_text() 'никогда не отображается на экране и не возвращается как пользовательский ввод. Обратный вызов используется, и rl_insert_text() возвращает правильное значение (спасибо, printf), поэтому я не уверен, что здесь происходит.

Я проверил /usr/include/readline/readline.h, а rl_insert_text() ниже: 

/* supported functions */

, что вводит в заблуждение под: 

/*
 * The following is not implemented
 */

Так я СОЛ, или я просто делаю это неправильно?

1 Ответ

1 голос
/ 10 июля 2009

К сожалению, вам может не повезти, по крайней мере с библиотекой readline, включенной в OS X. Из-за проблем с совместимостью лицензий Apple использует libedit , который (по-видимому) обеспечивает неполную эмуляцию readline. (Эта библиотека задокументирована с именем «editline» в readline.h, включенном в OS X.)

GNU Readline Library («одна истинная» библиотека readline) находится под лицензией GPL, которая (будучи лицензией с авторским левом) не очень хорошо работает с кодом, который не является полностью открытым исходным кодом. Если это сводится к (A) открытому исходному коду всего Xcode, OS X и т. Д. Или (B) с использованием подделки того, что вы действительно хотите использовать, Apple (как и большинство компаний) всегда будет выбирать Б. Облом, но это жизнь.

Лично я думаю, что это одна из причин того, что код GPL является чем-то вроде гадости на земле, поскольку в процессе "привязывания его к человеку" он часто также удерживает код от массы, которая покупает программное обеспечение. , Лицензии в стиле {BSD, MIT, Apache} гораздо более удобны для использования в системах с закрытым исходным кодом и позволяют коммерческим организациям вносить исправления и т. Д. Я предполагаю, что libedit не было уделено достаточно внимания исправлено Патчи сообщества, безусловно, будут приветствоваться, хотя гораздо приятнее, если мы сможем использовать код, не взламывая его самостоятельно ...; -)

Кстати, то же самое относится и к другим проектам GPL - до тех пор, пока {git, mercurial, bazaar} остается под лицензией GPL, не откладывайте дыхание, чтобы Apple выпустила интеграцию для них в Xcode. : - (

ОБНОВЛЕНИЕ: Новый Xcode 4 предлагает поддержку git. Ура! Насколько я понимаю, это связано с новой архитектурой плагинов, которая изолирует код GPL от основной кодовой базы Xcode. Тем не менее, я подчеркиваю, что лицензии с авторским левом все еще являются неправильным решением для кода, который должен принести пользу всем. Очевидно, что некоторые люди не согласны (вы приятель, анонимный переводчик), но факт в том, что GPL тоже может ограничивать свободы - обычно это другие, чем обычно закрытое / проприетарное программное обеспечение, но GPL также весьма эффективно предотвращает незаконное использование исходного кода ... Разница заключается в чувстве морального превосходства.

...