From witekfl at poczta.onet.pl Fri Dec 1 16:35:27 2006 From: witekfl at poczta.onet.pl (Witold Filipczyk) Date: Sat, 2 Dec 2006 00:35:27 +0100 Subject: [elinks-dev] Reading out documents using festival Message-ID: <20061201233527.GA19822@pldmachine> Hi! If you apply this patch ELinks will read out documents. Simply press 'R' (r with SHIFT) and 'R' again to switch off. For speech the festival program is required. I hope it will be included in 0.12. Don't ask me to cleanup the code. Do it yourself! Witek -- Szukam pracy -------------- next part -------------- diff --git a/src/config/actions-main.inc b/src/config/actions-main.inc index 9626c9d..939943d 100644 --- a/src/config/actions-main.inc +++ b/src/config/actions-main.inc @@ -85,6 +85,7 @@ ACTION_(MAIN, "save-as", SAVE_AS, N__("S ACTION_(MAIN, "save-formatted", SAVE_FORMATTED, N__("Save the current document in formatted form"), ACTION_RESTRICT_ANONYMOUS | ACTION_REQUIRE_VIEW_STATE | ACTION_REQUIRE_LOCATION), ACTION_(MAIN, "save-options", SAVE_OPTIONS, N__("Save options"), ACTION_RESTRICT_ANONYMOUS), ACTION_(MAIN, "save-url-as", SAVE_URL_AS, N__("Save URL as"), ACTION_RESTRICT_ANONYMOUS), +ACTION_(MAIN, "say-text", SAY_TEXT, N__("Reads out the document"), ACTION_REQUIRE_VIEW_STATE), ACTION_(MAIN, "scroll-down", SCROLL_DOWN, N__("Scroll down"), ACTION_REQUIRE_VIEW_STATE), ACTION_(MAIN, "scroll-left", SCROLL_LEFT, N__("Scroll left"), ACTION_REQUIRE_VIEW_STATE), ACTION_(MAIN, "scroll-right", SCROLL_RIGHT, N__("Scroll right"), ACTION_REQUIRE_VIEW_STATE), diff --git a/src/config/kbdbind.c b/src/config/kbdbind.c index 378ba8f..1aafe61 100644 --- a/src/config/kbdbind.c +++ b/src/config/kbdbind.c @@ -662,6 +662,7 @@ static struct default_kb default_main_ke { { 'N', KBD_MOD_CTRL }, ACT_MAIN_SCROLL_DOWN }, { { 'P', KBD_MOD_CTRL }, ACT_MAIN_SCROLL_UP }, { { 'Q', KBD_MOD_NONE }, ACT_MAIN_REALLY_QUIT }, + { { 'R', KBD_MOD_NONE }, ACT_MAIN_SAY_TEXT }, { { 'R', KBD_MOD_CTRL }, ACT_MAIN_RELOAD }, { { 'T', KBD_MOD_NONE }, ACT_MAIN_OPEN_LINK_IN_NEW_TAB_IN_BACKGROUND }, { { 'W', KBD_MOD_NONE }, ACT_MAIN_TOGGLE_WRAP_TEXT }, diff --git a/src/main/main.c b/src/main/main.c index 5901665..d8f2029 100644 --- a/src/main/main.c +++ b/src/main/main.c @@ -52,6 +52,7 @@ #include "util/file.h" #include "util/memdebug.h" #include "util/memory.h" #include "viewer/dump/dump.h" +#include "viewer/text/festival.h" #include "viewer/text/marks.h" struct program program; @@ -109,6 +110,9 @@ init(void) int fd = -1; enum retval ret; + festival.in = -1; + festival.out = -1; + init_osdep(); check_cwd(); diff --git a/src/viewer/action.c b/src/viewer/action.c index 3089a19..7d3a3ab 100644 --- a/src/viewer/action.c +++ b/src/viewer/action.c @@ -39,6 +39,7 @@ #include "session/session.h" #include "session/task.h" #include "viewer/action.h" #include "viewer/text/draw.h" +#include "viewer/text/festival.h" #include "viewer/text/form.h" #include "viewer/text/link.h" #include "viewer/text/search.h" @@ -472,6 +473,10 @@ #endif save_url_as(ses); break; + case ACT_MAIN_SAY_TEXT: + run_festival(ses, doc_view); + break; + case ACT_MAIN_SCROLL_DOWN: status = scroll_down(ses, doc_view); break; diff --git a/src/viewer/text/Makefile b/src/viewer/text/Makefile index 06190f1..1a843a7 100644 --- a/src/viewer/text/Makefile +++ b/src/viewer/text/Makefile @@ -3,6 +3,6 @@ include $(top_builddir)/Makefile.config OBJS-$(CONFIG_MARKS) += marks.o -OBJS = draw.o form.o link.o search.o textarea.o view.o vs.o +OBJS = draw.o festival.o form.o link.o search.o textarea.o view.o vs.o include $(top_srcdir)/Makefile.lib --- /dev/null 2004-07-16 04:05:52.000000000 +0200 +++ b/src/viewer/text/festival.c 2006-12-02 00:15:05.000000000 +0100 @@ -0,0 +1,141 @@ +/* festival */ +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#ifdef HAVE_UNISTD_H +#include +#endif + +#include "elinks.h" + +#include "document/document.h" +#include "document/view.h" +#include "main/select.h" +#include "osdep/osdep.h" +#include "protocol/common.h" +#include "util/string.h" +#include "viewer/action.h" +#include "viewer/text/festival.h" +#include "viewer/text/vs.h" + +struct fest festival; + +static void read_from_festival(struct fest *); +static void write_to_festival(struct fest *); + +static void +read_from_festival(struct fest *fest) +{ + while (1) { + unsigned char input[512]; + int r = safe_read(fest->in, input, 512); + + if (r <= 0) break; + if (input[r - 1] == ' ') { + write_to_festival(fest); + break; + } + } + set_handlers(fest->in, (select_handler_T) read_from_festival, + NULL, NULL, fest); +} + +static void +write_to_festival(struct fest *fest) +{ + struct string buf; + int i, w; + int len; + struct document *doc = fest->doc_view->document; + struct screen_char *data; + + if (fest->line >= fest->doc_view->document->height) + fest->running = 0; + if (!fest->running) + return; + + len = doc->data[fest->line].length; + int_upper_bound(&len, 512); + + if (!init_string(&buf)) + return; + + data = doc->data[fest->line].chars; + add_to_string(&buf, "(SayText \""); + for (i = 0; i < len; i++) { + unsigned char ch = (data[i].data == '"' ? ' ' : (unsigned char)data[i].data); + + add_char_to_string(&buf, ch); + } + add_to_string(&buf, "\")\n"); + + w = safe_write(fest->out, buf.source, buf.length); + if (w >= 0) { + fest->line++; + } + done_string(&buf); +} + +static int +init_festival(void) +{ + int in_pipe[2] = {-1, -1}; + int out_pipe[2] = {-1, -1}; + pid_t cpid; + + if (access("/usr/bin/festival", X_OK)) + return 1; + + if (c_pipe(in_pipe) || c_pipe(out_pipe)) { + if (in_pipe[0] >= 0) close(in_pipe[0]); + if (in_pipe[1] >= 0) close(in_pipe[1]); + if (out_pipe[0] >= 0) close(out_pipe[0]); + if (out_pipe[1] >= 0) close(out_pipe[1]); + return 1; + } + + cpid = fork(); + if (cpid == -1) { + close(in_pipe[0]); + close(in_pipe[1]); + close(out_pipe[0]); + close(out_pipe[1]); + return 1; + } + if (!cpid) { + dup2(out_pipe[1], 1); + dup2(in_pipe[0], 0); + close(out_pipe[0]); + close(in_pipe[1]); + close(2); + close_all_non_term_fd(); + execl("/usr/bin/festival", "festival", "-i", NULL); + _exit(0); + } else { + close(out_pipe[1]); + close(in_pipe[0]); + festival.in = out_pipe[0]; + festival.out = in_pipe[1]; + set_handlers(festival.in, (select_handler_T) read_from_festival, + NULL, NULL, &festival); + return 0; + } +} + +void +run_festival(struct session *ses, struct document_view *doc_view) +{ + if (festival.in == -1 && init_festival()) + return; + + festival.doc_view = doc_view; + festival.line = doc_view->vs->y; + festival.running = !festival.running; + + if (festival.running) { + write_to_festival(&festival); + } +} --- /dev/null 2004-07-16 04:05:52.000000000 +0200 +++ b/src/viewer/text/festival.h 2006-12-02 00:15:50.000000000 +0100 @@ -0,0 +1,19 @@ + +#ifndef EL__VIEWER_TEXT_FESTIVAL_H +#define EL__VIEWER_TEXT_FESTIVAL_H + +struct session; +struct document_view; + +struct fest { + struct document_view *doc_view; + int line; + int in; + int out; + unsigned int running:1; +}; + +extern struct fest festival; +void run_festival(struct session *, struct document_view *); + +#endif From kon at iki.fi Sun Dec 3 10:47:42 2006 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sun, 03 Dec 2006 19:47:42 +0200 Subject: [elinks-dev] Re: Reading out documents using festival In-Reply-To: <20061201233527.GA19822@pldmachine> References: <20061201233527.GA19822@pldmachine> Message-ID: <87u00cswg1.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061203/7b17fd22/attachment.bin From witekfl at poczta.onet.pl Mon Dec 4 10:20:34 2006 From: witekfl at poczta.onet.pl (Witold Filipczyk) Date: Mon, 4 Dec 2006 18:20:34 +0100 Subject: [elinks-dev] Reading out documents using festival In-Reply-To: <87u00cswg1.fsf@Astalo.kon.iki.fi> References: <20061201233527.GA19822@pldmachine> <87u00cswg1.fsf@Astalo.kon.iki.fi> Message-ID: <20061204172034.GA18004@pldmachine> On Sun, Dec 03, 2006 at 07:47:42PM +0200, Kalle Olavi Niemitalo wrote: > Witold Filipczyk writes: > > > If you apply this patch ELinks will read out documents. > > Simply press 'R' (r with SHIFT) and 'R' again to switch off. > > For speech the festival program is required. > > I hope it will be included in 0.12. > > Don't ask me to cleanup the code. Do it yourself! > > I am happy to see that you've been hacking ELinks. Perhaps > someone will review, test, and apply this patch, but it won't be > me because I'm currently more interested in fixing the bugs that > block 0.12 than in adding new features. > > This code appears to be better than a screen reader, because it > reads complete lines regardless of how wide the window is; and > better than just piping the formatted document to an external > process, because the user can choose a starting position and > easily stop the previous output. Is that correct? > > Is there a risk that if the festival process is somehow blocked, > then ELinks will also be blocked trying to write to the pipe? Yes. It is possible, but set_nonblocking somewhere should fix it. > > The code uses dup2 and execl. Does this cause problems on > non-POSIX ports? I didn't think about it. The code should be enclosed by IF_HAVE_FORK or something like that. BTW, could you look at SMB prototocol, bug 844? From kon at iki.fi Mon Dec 4 14:36:08 2006 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Mon, 04 Dec 2006 23:36:08 +0200 Subject: [elinks-dev] Re: Reading out documents using festival In-Reply-To: <20061204172034.GA18004@pldmachine> References: <20061201233527.GA19822@pldmachine> <87u00cswg1.fsf@Astalo.kon.iki.fi> <20061204172034.GA18004@pldmachine> Message-ID: <87psazs5rr.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061204/80c3481a/attachment.bin From fonseca at diku.dk Tue Dec 5 06:29:24 2006 From: fonseca at diku.dk (Jonas Fonseca) Date: Tue, 5 Dec 2006 14:29:24 +0100 Subject: [elinks-dev] Re: Reading out documents using festival In-Reply-To: <87psazs5rr.fsf@Astalo.kon.iki.fi> References: <20061201233527.GA19822@pldmachine> <87u00cswg1.fsf@Astalo.kon.iki.fi> <20061204172034.GA18004@pldmachine> <87psazs5rr.fsf@Astalo.kon.iki.fi> Message-ID: <20061205132924.GA10698@diku.dk> Kalle Olavi Niemitalo wrote Mon, Dec 04, 2006: > Witold Filipczyk writes: > > > BTW, could you look at SMB prototocol, bug 844? > > Fonseca already accepted bug 844 before you posted attachment 298, > so I'll leave it to him. I started to look through the bugs starting from the newest and thought it was good practice to accept it. I do however not intend to try to fix it myself (at least not in the foreseeable future) as I currently do not have a good way to test and do not have much interest in SMB. It is nice to see that a patch have arrive in the meantime. Witold, did you build on the FSP code, or from scratch? -- Jonas Fonseca From reed at reedmedia.net Thu Dec 7 10:53:02 2006 From: reed at reedmedia.net (Jeremy C. Reed) Date: Thu, 7 Dec 2006 11:53:02 -0600 (CST) Subject: [elinks-dev] use native libintl/gettext? Message-ID: I am a long time elinks user. It is my browser of choice. Thank you for your great work! Is there any way to have it use the system's native gettext libraries instead of building and using the src/intl included with the source? I didn't see any configure options or way to bypass it. I understand that some systems may have an inadequate libintl. Any patches to check for adequate gettext and use it if available? If not, would you be interested if used commonly-used autoconf to check this? (I also found that the Makefile system used in buildling elinks is different than I am used to when using autoconf configure.) Jeremy C. Reed From fonseca at diku.dk Thu Dec 7 16:13:41 2006 From: fonseca at diku.dk (Jonas Fonseca) Date: Fri, 8 Dec 2006 00:13:41 +0100 Subject: [elinks-dev] use native libintl/gettext? In-Reply-To: References: Message-ID: <20061207231341.GB10634@diku.dk> Hello Jeremy, Jeremy C. Reed wrote Thu, Dec 07, 2006: > I am a long time elinks user. It is my browser of choice. Thank you for > your great work! Thanks for your feedback. Always encouraging! > Is there any way to have it use the system's native gettext libraries > instead of building and using the src/intl included with the source? Not at the moment, and it is certainly not planned. Gettext has been changed to integrate better with ELinks: it uses the ELinks memory functions, has some specific wrappers etc. There is a bugzilla entry which is currently marked WONTFIX. Pasky's last remarks are: Our instance of libgettext is *heavily* customized and it is expected to get even more customized by the time, so using system gettext routines is not really feasible. - http://bugzilla.elinks.or.cz/show_bug.cgi?id=537 > Any patches to check for adequate gettext and use it if available? I do not know of such patches. > If not, would you be interested if used commonly-used autoconf to check > this? Patches are always welcome, but I do not really see a reason. Is gettext really that big? > (I also found that the Makefile system used in buildling elinks is > different than I am used to when using autoconf configure.) Yes, we changed to using a GNU make based build system instead of automake, since ELinks has a lot of build-time options that caused automake to generate huge makefiles because conditional are badly implemented. Sad, but having a Makefile taking several megabytes of storage is crazy. -- Jonas Fonseca From reed at reedmedia.net Fri Dec 8 11:12:28 2006 From: reed at reedmedia.net (Jeremy C. Reed) Date: Fri, 8 Dec 2006 12:12:28 -0600 (CST) Subject: [elinks-dev] use native libintl/gettext? In-Reply-To: <20061207231341.GB10634@diku.dk> References: <20061207231341.GB10634@diku.dk> Message-ID: > > Is there any way to have it use the system's native gettext libraries > > instead of building and using the src/intl included with the source? > > Not at the moment, and it is certainly not planned. Gettext has been > changed to integrate better with ELinks: it uses the ELinks memory > functions, has some specific wrappers etc. > > There is a bugzilla entry which is currently marked WONTFIX. Pasky's > last remarks are: > > Our instance of libgettext is *heavily* customized and it is > expected to get even more customized by the time, so using > system gettext routines is not really feasible. > > - http://bugzilla.elinks.or.cz/show_bug.cgi?id=537 > > > Any patches to check for adequate gettext and use it if available? > > I do not know of such patches. > > > If not, would you be interested if used commonly-used autoconf to check > > this? > > Patches are always welcome, but I do not really see a reason. Is gettext > really that big? > > > (I also found that the Makefile system used in buildling elinks is > > different than I am used to when using autoconf configure.) > > Yes, we changed to using a GNU make based build system instead of > automake, since ELinks has a lot of build-time options that caused > automake to generate huge makefiles because conditional are badly > implemented. Sad, but having a Makefile taking several megabytes of > storage is crazy. Thank you for the information. I didn't realize that your gettext was heavily customized. I only thought it was provided just in case some platforms didn't have any adequate gettext/libintl. My problem is that it installs or modifies ${PREFIX}/share/locale/locale.alias. Does it really need this locale alias mapping file? Can't it just use what is provided by native system? As far as I can tell with building and installing hundreds of programs from source (and many that use gettext / libintl) nothing else on my system create or modify this ${PREFIX}/share/locale/locale.alias. Note I have a system /usr/share/locale/locale.alias that is used. So I now see the only difference is that elinks provides its own gettext. Since elinks provides its own maybe it can be have "elinks" as part of the name. Or maybe it can be coded to just use the systems' own version. Either way, this could be changed in read_alias_file() in src/intl/gettext/localealias.c. Probably not very important now that I understand some background on this. Thanks again, Jonas, for the info. From kon at iki.fi Fri Dec 8 16:22:04 2006 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sat, 09 Dec 2006 01:22:04 +0200 Subject: [elinks-dev] Replace Py_XDECREF with Py_CLEAR in cleanup_python? Message-ID: <87d56uq8gz.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061209/a5da3eaa/attachment.bin From witekfl at poczta.onet.pl Sat Dec 9 13:41:51 2006 From: witekfl at poczta.onet.pl (Witold Filipczyk) Date: Sat, 9 Dec 2006 21:41:51 +0100 Subject: [elinks-dev] FSP and passwords Message-ID: <20061209204151.GA32758@pldmachine> Hey, Password protected directories doesn't work with the FSP code. get_uri_string(uri, URI_PASSWORD) simply doesn't work. I don't know how to use branches, so I'm including the patch here: diff --git a/src/protocol/fsp/fsp.c b/src/protocol/fsp/fsp.c index c66848a..e8eac96 100644 --- a/src/protocol/fsp/fsp.c +++ b/src/protocol/fsp/fsp.c @@ -180,10 +180,19 @@ do_fsp(struct connection *conn) struct stat sb; struct uri *uri = conn->uri; unsigned char *host = get_uri_string(uri, URI_HOST); - unsigned char *password = get_uri_string(uri, URI_PASSWORD); unsigned char *data = get_uri_string(uri, URI_DATA); unsigned short port = (unsigned short)get_uri_port(uri); - FSP_SESSION *ses = fsp_open_session(host, port, password); + FSP_SESSION *ses; + + if (uri->password) { + unsigned char tmp = uri->password[uri->passwordlen]; + + uri->password[uri->passwordlen] = '\0'; + ses = fsp_open_session(host, port, uri->password); + uri->password[uri->passwordlen] = tmp; + } else { + ses = fsp_open_session(host, port, NULL); + } if (!ses) fsp_error("Session initialization failed."); Use it with fake user, eg: fsp://user:password at ... In directory listings, IMHO, this password should be added to base href, otherwise it must be added by hand for every followed link. The same case is for smb2(not applied yet). -- Witek From levinsm at users.sourceforge.net Sun Dec 10 11:02:34 2006 From: levinsm at users.sourceforge.net (M. Levinson) Date: Sun, 10 Dec 2006 13:02:34 -0500 Subject: [elinks-dev] Re: Replace Py_XDECREF with Py_CLEAR in cleanup_python? In-Reply-To: <87d56uq8gz.fsf@Astalo.kon.iki.fi> Message-ID: <8936.1165773754@poultrygeist.com> On Dec 09, 2006, at 1:22am, Kalle Olavi Niemitalo writes: >Now if the Python scripting module is initialized once and >cleaned up, and then initialized again but the second >initialization fails e.g. because of invalid syntax in hooks.py, >I believe python_hooks will retain the value from the first >successful initialization. And if the module is then again >cleaned up, Py_XDECREF gets called on an object that has already >been deleted. A similar problem seems possible in >python_done_keybinding_interface. You're right, I hadn't anticipated reinitialization after cleanup. >Should the Py_XDECREF calls be changed to Py_CLEAR, or did I >misunderstand something? Yes, Py_CLEAR is the clean solution for Python 2.4 and later; but relying on it would mean that the Python backend could no longer be compiled with Python 2.3 (which I believe happens to be the version you've been linking with?). Assuming compatibility with older Python versions is still desired, the safe approach would be to explicitly imitate what Py_CLEAR does: src/scripting/python/core.c | 10 +++++++++- src/scripting/python/keybinding.c | 8 +++++++- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/src/scripting/python/core.c b/src/scripting/python/core.c index 3ce2d43..33bb5c8 100644 --- a/src/scripting/python/core.c +++ b/src/scripting/python/core.c @@ -209,8 +209,16 @@ void cleanup_python(struct module *module) { if (Py_IsInitialized()) { + PyObject *temp; + python_done_keybinding_interface(); - Py_XDECREF(python_hooks); + + /* This is equivalent to Py_CLEAR(), but it works with older + * versions of Python predating that macro: */ + temp = python_hooks; + python_hooks = NULL; + Py_XDECREF(temp); + Py_Finalize(); } } diff --git a/src/scripting/python/keybinding.c b/src/scripting/python/keybinding.c index 2d6668c..983c184 100644 --- a/src/scripting/python/keybinding.c +++ b/src/scripting/python/keybinding.c @@ -194,5 +194,11 @@ python_init_keybinding_interface(PyObject *dict, PyObject *name) void python_done_keybinding_interface(void) { - Py_XDECREF(keybindings); + PyObject *temp; + + /* This is equivalent to Py_CLEAR(), but it works with older + * versions of Python predating that macro: */ + temp = keybindings; + keybindings = NULL; + Py_XDECREF(temp); } From fonseca at diku.dk Sun Dec 10 14:05:17 2006 From: fonseca at diku.dk (Jonas Fonseca) Date: Sun, 10 Dec 2006 22:05:17 +0100 Subject: [elinks-dev] FSP and passwords In-Reply-To: <20061209204151.GA32758@pldmachine> References: <20061209204151.GA32758@pldmachine> Message-ID: <20061210210517.GA29321@diku.dk> Witold Filipczyk wrote Sat, Dec 09, 2006: > Hey, Hello Witold, > Password protected directories doesn't work with the FSP code. > get_uri_string(uri, URI_PASSWORD) simply doesn't work. I have fixed this in add_uri_to_string() instead of the FSP protocol backend, which seemed a little simpler. Pushed as commit f90c07d54f6848025b82c0c2c9eab7663d240277. > I don't know how to use branches, so I'm including the patch here: Well, let me know if you want to know how to set up a branch in the repository to hack on. If you use cogito it should be as easy as: $ cg branch-add remote-my-branch git+ssh://[user+host]/srv/git/elinks.git#my-branch # Check that the new branch is correct $ cg branch-ls # Make a new local branch called my-branch that will be based on the # current origin branch $ cg switch -r origin my-branch $ edit / make / commit # When you want to publish your changes $ cg push remote-my-branch # If you want to go back to the master branch use $ cg switch master # If you want to merge stuff from master into the my-branch and current # have checked out the master branch (cg-status will tell you the # current branch), first checkout the my-branch branch and then merge # from master: $ cg switch my-branch $ cg merge master Note, most of the above I wrote in the buffer without testing, but passing --long-help to either cogito command should give you the details. > In directory listings, IMHO, this password should be added to base href, > otherwise it must be added by hand for every followed link. It would maybe make sense to use the protocol auth history for this. Do you know if the FSP server is able to notify the client about authentication being necessary? > The same case is for smb2(not applied yet). Sorry, I didn't really look at the code yet, and as I said I don't have a good way to test it right now. -- Jonas Fonseca From fonseca at diku.dk Sun Dec 10 14:09:35 2006 From: fonseca at diku.dk (Jonas Fonseca) Date: Sun, 10 Dec 2006 22:09:35 +0100 Subject: [elinks-dev] use native libintl/gettext? In-Reply-To: References: <20061207231341.GB10634@diku.dk> Message-ID: <20061210210935.GB29321@diku.dk> Jeremy C. Reed wrote Fri, Dec 08, 2006: > My problem is that it installs or modifies > ${PREFIX}/share/locale/locale.alias. > > Does it really need this locale alias mapping file? Can't it just use what > is provided by native system? Probably not. I don't know, but as far as I know it should it already tries to "patch" the locale.alias file of the local system. This might not work so good when installing packages. > As far as I can tell with building and installing hundreds of programs > from source (and many that use gettext / libintl) nothing else on my > system create or modify this ${PREFIX}/share/locale/locale.alias. Note I > have a system /usr/share/locale/locale.alias that is used. > > So I now see the only difference is that elinks provides its own gettext. > > Since elinks provides its own maybe it can be have "elinks" as part of the > name. Or maybe it can be coded to just use the systems' own version. > > Either way, this could be changed in read_alias_file() in > src/intl/gettext/localealias.c. > > Probably not very important now that I understand some background on this. I am not sure I understand. You want ELinks to install the alias file under /usr/share/elinks/. I agree that touching (especially) the alias file under /usr/share is a bad idea. It might be more acceptable for /usr/local/share. -- Jonas Fonseca From samuel.thibault at ens-lyon.org Sun Dec 10 17:59:01 2006 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Mon, 11 Dec 2006 01:59:01 +0100 Subject: [elinks-dev] BRF charset support Message-ID: <20061211005901.GA15369@implementation.residence.ens-lyon.fr> Hi, The following URL outputs a BRF-encoded text. http://brl.thefreecat.org/test.php I would expect links to output braille patterns when browsing it, but it doesn't recognize the BRF charset (though it is supported by my debian's glibc's iconv) and links considers the text to be latin1, hence the result is "A B C". When links doesn't know a charset, it should ask iconv in case the latter is able to convert into unicode, and then links could display it like any unicode text. Samuel From samuel.thibault at ens-lyon.org Mon Dec 11 02:36:31 2006 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Mon, 11 Dec 2006 10:36:31 +0100 Subject: [elinks-dev] Re: BRF charset support In-Reply-To: <20061211005901.GA15369@implementation.residence.ens-lyon.fr> References: <20061211005901.GA15369@implementation.residence.ens-lyon.fr> Message-ID: <20061211093631.GG3452@implementation.labri.fr> Hi, Samuel Thibault, le Mon 11 Dec 2006 01:59:01 +0100, a ?crit : > The following URL outputs a BRF-encoded text. > > http://brl.thefreecat.org/test.php > > I would expect links to output braille patterns when browsing it, Just to make sure you understand the problem: links is _already_ able to output braille: just look at http://brl.thefreecat.org/testbraille.txt What is needed is merely the conversion from BRF, which iconv can do for you. Samuel From samuel.thibault at ens-lyon.org Mon Dec 11 02:37:19 2006 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Mon, 11 Dec 2006 10:37:19 +0100 Subject: [elinks-dev] Re: BRF charset support In-Reply-To: <20061211093631.GG3452@implementation.labri.fr> References: <20061211005901.GA15369@implementation.residence.ens-lyon.fr> <20061211093631.GG3452@implementation.labri.fr> Message-ID: <20061211093719.GH3452@implementation.labri.fr> Samuel Thibault, le Mon 11 Dec 2006 10:36:31 +0100, a ?crit : > Hi, > > Samuel Thibault, le Mon 11 Dec 2006 01:59:01 +0100, a ?crit : > > The following URL outputs a BRF-encoded text. > > > > http://brl.thefreecat.org/test.php > > > > I would expect links to output braille patterns when browsing it, > > Just to make sure you understand the problem: links is _already_ able to > output braille: just look at http://brl.thefreecat.org/testbraille.txt (provided that your terminal has a braille font of course). Samuel From kon at iki.fi Mon Dec 11 14:16:40 2006 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Mon, 11 Dec 2006 23:16:40 +0200 Subject: [elinks-dev] Re: BRF charset support In-Reply-To: <20061211005901.GA15369@implementation.residence.ens-lyon.fr> References: <20061211005901.GA15369@implementation.residence.ens-lyon.fr> Message-ID: <87y7pexhdz.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061211/76034822/attachment.bin From kon at iki.fi Sat Dec 16 03:36:11 2006 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sat, 16 Dec 2006 12:36:11 +0200 Subject: [elinks-dev] Please rename gmane.comp.web.links to gmane.comp.web.elinks.devel. Message-ID: <874prwruuc.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061216/36f26aa9/attachment.bin From fonseca at diku.dk Fri Dec 15 09:05:17 2006 From: fonseca at diku.dk (Jonas Fonseca) Date: Fri, 15 Dec 2006 17:05:17 +0100 Subject: [elinks-dev] BRF charset support In-Reply-To: <20061212094526.GH3451@implementation.labri.fr> References: <20061211005901.GA15369@implementation.residence.ens-lyon.fr> <87y7pexhdz.fsf@Astalo.kon.iki.fi> <20061211230200.GK6716@bouh.residence.ens-lyon.fr> <87slfly2hd.fsf@Astalo.kon.iki.fi> <20061212094526.GH3451@implementation.labri.fr> Message-ID: <20061215160517.GB22407@diku.dk> Samuel Thibault wrote Tue, Dec 12, 2006: > Kalle Olavi Niemitalo, le Tue 12 Dec 2006 09:53:18 +0200, a ?crit : > > This elinks-dev mailing list is for the ELinks variant. I don't > > know whether the developers of the original Links read this list. > > Ah. So I don't know how to report bugs to Links people :) You can try to either send to one of the developers (see addresses at http://links.twibright.com/development.php) or to the the Links mailing which has the address listlinks-list at linuxfromscratch.org ... -- Jonas Fonseca From kon at iki.fi Sat Dec 16 16:02:26 2006 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sun, 17 Dec 2006 01:02:26 +0200 Subject: [elinks-dev] contrib/bzip2-pipe.patch (was: FSP and passwords) In-Reply-To: <20061214162208.GA8649@pldmachine> References: <20061209204151.GA32758@pldmachine> <20061210210517.GA29321@diku.dk> <20061214162208.GA8649@pldmachine> Message-ID: <87y7p7qwal.fsf_-_@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061217/2a8b0041/attachment.bin From kon at iki.fi Sun Dec 17 02:44:25 2006 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sun, 17 Dec 2006 11:44:25 +0200 Subject: [elinks-dev] contrib/bzip2-pipe.patch In-Reply-To: <87y7p7qwal.fsf_-_@Astalo.kon.iki.fi> References: <20061209204151.GA32758@pldmachine> <20061210210517.GA29321@diku.dk> <20061214162208.GA8649@pldmachine> <87y7p7qwal.fsf_-_@Astalo.kon.iki.fi> Message-ID: <87slferh52.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061217/5d82db04/attachment-0001.bin From larsi at gnus.org Sat Dec 16 08:04:30 2006 From: larsi at gnus.org (Lars Magne Ingebrigtsen) Date: Sat, 16 Dec 2006 16:04:30 +0100 Subject: [elinks-dev] Please rename gmane.comp.web.links to gmane.comp.web.elinks.devel. In-Reply-To: <874prwruuc.fsf@Astalo.kon.iki.fi> (Kalle Olavi Niemitalo's message of "Sat\, 16 Dec 2006 12\:36\:11 +0200") References: <874prwruuc.fsf@Astalo.kon.iki.fi> Message-ID: Kalle Olavi Niemitalo writes: > Can you rename the group to gmane.comp.web.elinks.devel and make > the other names gmane.comp.web.links and gmane.comp.web.elinks > redirect to that? Sorry; renaming groups in Gmane isn't currently possible. I've added the lists to the renaming queue, though, so if it becomes possible, they'll be renamed. -- (domestic pets only, the antidote for overdose, milk.) larsi at gnus.org * Lars Magne Ingebrigtsen From levinsm at users.sourceforge.net Wed Dec 20 05:44:59 2006 From: levinsm at users.sourceforge.net (M. Levinson) Date: Wed, 20 Dec 2006 07:44:59 -0500 Subject: [elinks-dev] [patch] Use document->cached in src/scripting/python/document.c Message-ID: <6964.1166618699@poultrygeist.com> For consistency, here's a patch for the Python backend to match last week's change to the Lua backend (in commit 7db8abf6e7ff43f059c4496e734c17337487db2c) that accompanied the fix for bug 756. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-patch Size: 1637 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061220/87504a2a/attachment.bin From navinp at gmail.com Sat Dec 23 10:24:39 2006 From: navinp at gmail.com (Navin P) Date: Sat, 23 Dec 2006 09:24:39 -0800 Subject: [elinks-dev] download tmpnam patch Message-ID: <146323d90612230924t2b5287d9r31dd520c6af13cfc@mail.gmail.com> Only in elinks: patchfile Only in elinks/src: linux-2.6.11.8.tar.bz2 diff -pr elinks_old/src/session/download.c elinks/src/session/download.c *** elinks_old/src/session/download.c 2006-12-23 18:10:38.000000000 -0800 --- elinks/src/session/download.c 2006-12-23 22:36:56.000000000 -0800 *************** create_download_file_do(struct terminal *** 664,669 **** --- 664,675 ---- /* O_APPEND means repositioning at the end of file before each write(), * thus ignoring seek()s and that can hide mysterious bugs. IMHO. * --pasky */ + + /* Can we unlink(file) here if case of if(!resume) unlink(file); + * Btw where is the seek or O_APPEND being done. In that case + * can't be remove unlink even in the resume case. + * --navin */ + h = open(file, O_CREAT | O_WRONLY | (resume ? 0 : O_TRUNC) | (sf && !resume ? O_EXCL : 0), sf ? 0600 : 0666); *************** get_temp_name(struct uri *uri) *** 748,768 **** { struct string name; unsigned char *extension; ! /* FIXME ! * We use tempnam() here, which is unsafe (race condition), for now. ! * This should be changed at some time, but it needs an in-depth work ! * of whole download code. --Zas */ ! unsigned char *nm = tempnam(NULL, ELINKS_TEMPNAME_PREFIX); ! if (!nm) return NULL; if (!init_string(&name)) { ! free(nm); return NULL; } add_to_string(&name, nm); ! free(nm); extension = get_extension_from_uri(uri); if (extension) { --- 754,783 ---- { struct string name; unsigned char *extension; ! unsigned char *nm,*tm; ! int fd=-1; ! nm=get_tempdir_filename(ELINKS_TEMPNAME_PREFIX"XXXXXX"); ! ! if(nm==NULL) { ! return NULL; ! } ! ! if((fd=mkstemp(nm)) < 0) { ! mem_free(nm); ! return NULL; ! } if (!init_string(&name)) { ! mem_free(nm); ! close(fd); return NULL; } add_to_string(&name, nm); ! ! unlink(nm); ! mem_free(nm); extension = get_extension_from_uri(uri); if (extension) { *************** get_temp_name(struct uri *uri) *** 770,775 **** --- 785,792 ---- mem_free(extension); } + close(fd); + return name.source; } *************** continue_download(void *data, unsigned c *** 925,931 **** } if (type_query->external_handler) { ! /* FIXME: get_temp_name() calls tempnam(). --Zas */ file = get_temp_name(type_query->uri); if (!file) { mem_free(codw_hop); --- 942,950 ---- } if (type_query->external_handler) { ! /* FIXME: Well this doesn't call tmpnam but calls mkstemp . ! * We cannot be sure that a user hasn't created symlink ! * at this time. So we have to be careful. --navin */ file = get_temp_name(type_query->uri); if (!file) { mem_free(codw_hop); From navinp at gmail.com Sat Dec 23 11:53:47 2006 From: navinp at gmail.com (Navin P) Date: Sat, 23 Dec 2006 10:53:47 -0800 Subject: [elinks-dev] download tmpnam patch In-Reply-To: <146323d90612230924t2b5287d9r31dd520c6af13cfc@mail.gmail.com> References: <146323d90612230924t2b5287d9r31dd520c6af13cfc@mail.gmail.com> Message-ID: <146323d90612231053w462ad309w5e051e51fff0cfd7@mail.gmail.com> Hi, Please review and apply. diff -pr elinks_old/src/session/download.c elinks/src/session/download.c *** elinks_old/src/session/download.c 2006-12-23 18:10:38.000000000 -0800 --- elinks/src/session/download.c 2006-12-23 23:59:16.000000000 -0800 *************** get_temp_name(struct uri *uri) *** 748,768 **** { struct string name; unsigned char *extension; ! /* FIXME ! * We use tempnam() here, which is unsafe (race condition), for now. ! * This should be changed at some time, but it needs an in-depth work ! * of whole download code. --Zas */ ! unsigned char *nm = tempnam(NULL, ELINKS_TEMPNAME_PREFIX); ! if (!nm) return NULL; if (!init_string(&name)) { ! free(nm); return NULL; } add_to_string(&name, nm); ! free(nm); extension = get_extension_from_uri(uri); if (extension) { --- 748,790 ---- { struct string name; unsigned char *extension; ! unsigned char *nm,tm[22],*km,*pm; ! unsigned long long t,k; ! km=get_tempdir_filename(ELINKS_TEMPNAME_PREFIX); ! ! srand(time(NULL)); ! t=rand()+ time(NULL) + 1LL; ! sprintf(tm,"%llu",t); ! ! pm=mem_realloc(km,strlen(km)+strlen(tm)+ 1+); ! ! if(pm==NULL) { ! mem_free(km); ! return NULL; ! } ! ! strcat(pm,tm); ! ! /* This function already exists.We are using ! * some rand() as prefix in get_tempdir_filename ! * .This should fix the race condition even if ! * the file exists.The rand() is not necessarily ! * required but helps. ! * --navin */ ! ! nm=get_unique_name(pm); if (!init_string(&name)) { ! mem_free(nm); ! mem_free(pm); return NULL; } add_to_string(&name, nm); ! ! mem_free(pm); ! mem_free(nm); extension = get_extension_from_uri(uri); if (extension) { *************** continue_download(void *data, unsigned c *** 925,931 **** } if (type_query->external_handler) { - /* FIXME: get_temp_name() calls tempnam(). --Zas */ file = get_temp_name(type_query->uri); if (!file) { mem_free(codw_hop); --- 947,952 ---- From navinp at gmail.com Sat Dec 23 12:08:43 2006 From: navinp at gmail.com (Navin P) Date: Sat, 23 Dec 2006 11:08:43 -0800 Subject: [elinks-dev] download tmpnam patch In-Reply-To: <146323d90612231053w462ad309w5e051e51fff0cfd7@mail.gmail.com> References: <146323d90612230924t2b5287d9r31dd520c6af13cfc@mail.gmail.com> <146323d90612231053w462ad309w5e051e51fff0cfd7@mail.gmail.com> Message-ID: <146323d90612231108r1849de44o651959bc015bdd8e@mail.gmail.com> diff -pr elinks_old/src/session/download.c elinks/src/session/download.c *** elinks_old/src/session/download.c 2006-12-23 18:10:38.000000000 -0800 --- elinks/src/session/download.c 2006-12-24 00:25:05.000000000 -0800 *************** get_temp_name(struct uri *uri) *** 748,768 **** { struct string name; unsigned char *extension; ! /* FIXME ! * We use tempnam() here, which is unsafe (race condition), for now. ! * This should be changed at some time, but it needs an in-depth work ! * of whole download code. --Zas */ ! unsigned char *nm = tempnam(NULL, ELINKS_TEMPNAME_PREFIX); ! if (!nm) return NULL; if (!init_string(&name)) { ! free(nm); return NULL; } add_to_string(&name, nm); ! free(nm); extension = get_extension_from_uri(uri); if (extension) { --- 748,790 ---- { struct string name; unsigned char *extension; ! unsigned char *nm,tm[22],*km,*pm; ! unsigned long long t,k; ! km=get_tempdir_filename(ELINKS_TEMPNAME_PREFIX); ! ! srand(time(NULL)); ! t=rand()+ time(NULL) + 1LL; ! sprintf(tm,"%llu",t); ! ! pm=mem_realloc(km,strlen(km)+strlen(tm)+ 1); ! ! if(pm==NULL) { ! mem_free(km); ! return NULL; ! } ! ! strcat(pm,tm); ! ! /* This function already exists.We are using ! * some rand() as prefix in get_tempdir_filename ! * .This should fix the race condition even if ! * the file exists.The rand() is not necessarily ! * required but helps. ! * --navin */ ! ! nm=get_unique_name(pm); if (!init_string(&name)) { ! mem_free(nm); ! mem_free(pm); return NULL; } add_to_string(&name, nm); ! ! mem_free(pm); ! mem_free(nm); extension = get_extension_from_uri(uri); if (extension) { *************** continue_download(void *data, unsigned c *** 925,931 **** } if (type_query->external_handler) { - /* FIXME: get_temp_name() calls tempnam(). --Zas */ file = get_temp_name(type_query->uri); if (!file) { mem_free(codw_hop); --- 947,952 ---- From kon at iki.fi Tue Dec 26 15:12:13 2006 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Wed, 27 Dec 2006 00:12:13 +0200 Subject: [elinks-dev] witekfl branch: quoting for FLITE_SYSTEM Message-ID: <87k60etigy.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061227/47cfa90a/attachment.bin From kon at iki.fi Tue Dec 26 22:38:22 2006 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Wed, 27 Dec 2006 07:38:22 +0200 Subject: [elinks-dev] download tmpnam patch In-Reply-To: <146323d90612231108r1849de44o651959bc015bdd8e@mail.gmail.com> References: <146323d90612230924t2b5287d9r31dd520c6af13cfc@mail.gmail.com> <146323d90612231053w462ad309w5e051e51fff0cfd7@mail.gmail.com> <146323d90612231108r1849de44o651959bc015bdd8e@mail.gmail.com> Message-ID: <87ejqlucdt.fsf@Astalo.kon.iki.fi> "Navin P" writes: > ! unsigned char *nm,tm[22],*km,*pm; How did you get this number 22? # define ULLONG_MAX 18446744073709551615ULL Here, ULLONG_MAX has 20 digits and '\0' is one more character, so unsigned char tm[21] would have sufficed. But long long might have more than 64 bits, and so might RAND_MAX or time_t. > ! unsigned long long t,k; For portability, ELinks does not use long long unconditionally. If you want to use long long, you should check whether HAVE_LONG_LONG is defined, and do something else if not. See the #define longlong in src/osdep/types.h. > ! srand(time(NULL)); > ! t=rand()+ time(NULL) + 1LL; > ! sprintf(tm,"%llu",t); I do not think calling srand repeatedly is appropriate. > ! /* This function already exists.We are using > ! * some rand() as prefix in get_tempdir_filename > ! * .This should fix the race condition even if > ! * the file exists.The rand() is not necessarily > ! * required but helps. > ! * --navin */ rand() cannot fix the race condition, it can only make it more difficult to reproduce. Anyway if it were good to have a random element in names of temporary files then I think that code should be in get_unique_name rather than here, so that all callers could benefit from it. > ! nm=get_unique_name(pm); > > if (!init_string(&name)) { > ! mem_free(nm); > ! mem_free(pm); get_unique_name apparently returns the original pointer if the name is already unique. Your code frees the same memory twice in that case. > extension = get_extension_from_uri(uri); > if (extension) { First get_unique_name (or tempnam) tries different names until it finds one for which there is no file yet, and then get_temp_name appends an extension, so the result of the check is no longer valid. Thus get_temp_name doesn't even notice clashes with files that exist before it is called. Is that why you needed rand()? If get_unique_name is to be used then I think it should take the extension as another parameter, so that it can append it before checking whether the file already exists. This might require changing lookup_unique_name, too. > - /* FIXME: get_temp_name() calls tempnam(). --Zas */ > file = get_temp_name(type_query->uri); If this FIXME is removed, I think there should be a comment for each variable and data member where the string is stored, warning that another user may have created a file or symlink with that name after the name was chosen. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061227/f1e076f6/attachment-0001.bin From witekfl at poczta.onet.pl Thu Dec 28 10:50:27 2006 From: witekfl at poczta.onet.pl (Witold Filipczyk) Date: Thu, 28 Dec 2006 18:50:27 +0100 Subject: [elinks-dev] witekfl branch: quoting for FLITE_SYSTEM In-Reply-To: <87k60etigy.fsf@Astalo.kon.iki.fi> References: <87k60etigy.fsf@Astalo.kon.iki.fi> Message-ID: <20061228175027.GA26180@pldmachine> On Wed, Dec 27, 2006 at 12:12:13AM +0200, Kalle Olavi Niemitalo wrote: > commit e965d07055f5dd3e046469232e4b3986fb60cbaf > speech: added flite - the alternative synthesis engine. > > write_to_festival inserts backslashes in front of double-quotes > and backslashes so that Festival can distinguish them from string > delimiters. Now if FLITE_SYSTEM is selected, the output instead > goes to a loop in init_festival that adds quotes around the > string and "flite -t " to the beginning and calls system(). > Unfortunately, the shell executed by system() recognizes more > metacharacters in double-quoted strings than just double-quotes > and backslashes. Specifically, if the string contains `foo` or > $(foo), then arbitrary programs can be executed. > > It may also be possible that flite treats the entire line as an > option if it begins with a dash. (The quotes don't help here > because the shell eats them.) The documentation at > does > not say whether that is possible; I suppose someone should check > the source code of flite. Thanks for the report. I'll use '' to quote. From kon at iki.fi Thu Dec 28 11:10:59 2006 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Thu, 28 Dec 2006 20:10:59 +0200 Subject: [elinks-dev] witekfl branch: quoting for FLITE_SYSTEM In-Reply-To: <20061228175027.GA26180@pldmachine> References: <87k60etigy.fsf@Astalo.kon.iki.fi> <20061228175027.GA26180@pldmachine> Message-ID: <87vejvx558.fsf@Astalo.kon.iki.fi> Witold Filipczyk writes: > Thanks for the report. > I'll use '' to quote. I think your commit 60fc3bd04fe3f85c66d1dadbc8ba4f56f576f611 doesn't really fix this, because \ is not special inside ''. For example: $ cat 'begin # \'$(date)\' # end' cat: begin # \Thu: No such file or directory cat: Dec: No such file or directory cat: 28: No such file or directory cat: 20:02:33: No such file or directory cat: EET: No such file or directory cat: 2006': No such file or directory $ To get ' inside '' you can use '\'' like this: $ cat 'begin # '\''$(date)'\'' # end' cat: begin # '$(date)' # end: No such file or directory $ Unfortunately it quadruples the length of the string, so ARG_MAX can be exceeded. And who knows what shells will do on non-POSIX systems... If you can use something like "flite -f /dev/stdin", perhaps via popen, I think it will be safer. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061228/0b55a246/attachment.bin From kon at iki.fi Sun Dec 31 02:30:48 2006 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sun, 31 Dec 2006 11:30:48 +0200 Subject: [elinks-dev] Remove current_url parameter of Python goto_url_hook? Message-ID: <87psa0v2d3.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061231/ffebc38a/attachment.bin From kon at iki.fi Sun Dec 31 04:17:31 2006 From: kon at iki.fi (Kalle Olavi Niemitalo) Date: Sun, 31 Dec 2006 13:17:31 +0200 Subject: [elinks-dev] experimental features (was: Remove current_url parameter of Python goto_url_hook?) In-Reply-To: <87psa0v2d3.fsf@Astalo.kon.iki.fi> References: <87psa0v2d3.fsf@Astalo.kon.iki.fi> Message-ID: <87lkkouxf8.fsf@Astalo.kon.iki.fi> A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061231/6b650d85/attachment.bin From levinsm at users.sourceforge.net Sun Dec 31 08:00:34 2006 From: levinsm at users.sourceforge.net (M. Levinson) Date: Sun, 31 Dec 2006 10:00:34 -0500 Subject: [elinks-dev] Remove current_url parameter of Python goto_url_hook? In-Reply-To: <87psa0v2d3.fsf@Astalo.kon.iki.fi> Message-ID: <9655.1167577234@poultrygeist.com> On Dec 31, 2006, at 11:30am, Kalle Olavi Niemitalo writes: >src/scripting/python/hooks.c (script_hook_url) calls hooks as >goto_url_hook(new-url, current-url) and follow_url_hook(new-url). >It has a comment saying that the current-url parameter exists >only for compatibility and that the script can instead use >elinks.current_url(). However, the current-url parameter was >added in commit 87e27b9b3e47671484c7eb77d61b75fffc89624f and is >not in ELinks 0.11.2, so any compatibility problems would only >hit people who have been using 0.12.GIT snapshots. Can we remove >the second parameter now before releasing ELinks 0.12pre1? The decision isn't up to me, but I think this is a good idea. Here's a patch that would update the documentation and hooks.py, as well as hooks.c. FYI, if this patch is applied then anyone who's still trying to use a goto_url_hook that expects a second argument will get a "Browser scripting error" dialog box that says: An error occurred while running a Python script: TypeError: goto_url_hook() takes exactly 2 arguments (1 given) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-patch Size: 3991 bytes Desc: not available Url : http://linuxfromscratch.org/pipermail/elinks-dev/attachments/20061231/c2a76d00/attachment.bin