Utilizzando rl_insert_text di readline su OS X 10.5

Question

Quindi, sto cercando di riempire un po 'di testo predefinito in un input dell'utente utilizzando readline, e avendo riuscite a farla lavorare su 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;
}

Questo codice non ha nemmeno compilare il 10,4 (nessuna definizione per _rl_insert_text su 10.4, che è un po 'una delusione), ma si compila il 10.5. Tuttavia, il testo rl_insert_text()'d non viene mai mostrata a schermo, né restituito come input dell'utente. La richiamata viene utilizzato e rl_insert_text() restituisce il valore corretto, (grazie, printf), quindi non sono sicuro di quello che sta succedendo qui.

Ho controllato /usr/include/readline/readline.h e rl_insert_text() è sotto:

/* supported functions */

che è confusamente sotto:

/*
 * The following is not implemented
 */

Così sono io SOL, o sono semplicemente facendo male?

Answer 1

Purtroppo, si può essere fuori di fortuna, almeno con la libreria readline incluso in OS X. A causa di problemi di compatibilità licenza, uso di Apple libedit , quale emulazione readline "nofollow noreferrer" (apparentemente) fornisce incompleta. (Questa libreria è documentato con il nome "esiste EDITLINE" nel readline.h inclusa con OS X).

GNU Readline Biblioteca (l ' "unico vero" libreria readline) è sotto licenza GPL, che (essendo una licenza copyleft) non gioca bene con il codice che non è del tutto open-source. Se si tratta di (A) aperto-sourcing tutti Xcode, OS X, ecc o (B) utilizzando un knock-off di quello che stai piace davvero usare, Apple (come la maggior parte delle aziende) sta andando sempre di scegliere B. E 'una rottura, ma questa è la vita.

Personalmente, credo che questo è uno dei motivi che il codice GPL è un po 'di una sventura per il paese, in quanto nell'atto di "attaccare l'uomo", spesso trattiene anche il codice dalle masse che acquistano software . Il {BSD, MIT, Apache} licenze -style sono molto più favorevoli da utilizzare in sistemi closed-source, e ancora consentire alle imprese commerciali per contribuire indietro patch, ecc La mia ipotesi è che libedit non ha ricevuto sufficiente attenzione per essere risolto correttamente . patch comunitari sarebbe certamente il benvenuto, anche se è molto più bello se possiamo usare il codice, senza dover mettere mano su noi stessi ...; -)

A proposito, la stessa cosa vale per altri progetti GPL - finché {git, mercuriale, bazar} rimane sotto GPL, non trattenete il respiro per Apple di spedire l'integrazione per loro in Xcode. : - (

UPDATE: Il nuovo Xcode 4 offre supporto git. Huzzah! La mia comprensione è che questo è dovuto alla nuova architettura a plugin che isola il codice GPL dal codice base Xcode principale. Tuttavia, sottolineo che le licenze copyleft sono ancora la soluzione sbagliata per il codice che dovrebbero beneficiare tutti. Ovviamente alcune persone non sono d'accordo (sei un amico, downvoter anonimo), ma il fatto è che GPL può limitare le libertà troppo - di solito le sue quelli diversi rispetto closed-source software / proprietario fa in generale, ma GPL è anche molto efficace nel prevenire l'uso illegale del codice sorgente ... La differenza è una sensazione di superiorità morale.