[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnulib] new modules for Java interoperability

From: Paul Eggert
Subject: Re: [bug-gnulib] new modules for Java interoperability
Date: Mon, 17 Jan 2005 13:48:19 -0800
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Bruno Haible <address@hidden> writes:

> /* Copies the quoted string to p and returns the incremented p.
>    There must be room for shell_quote_length (string) + 1 bytes at p.  */
> extern char * shell_quote_copy (char *p, const char *string);

GNU diffutils has a quotesys module which does something quite similar.
The interface isn't exactly the same:

  /* Place into QUOTED a quoted version of ARG suitable for `system'.
     Return the length of the resulting string (which is not null-terminated).
     If QUOTED is null, return the length without any side effects.  */
  size_t quote_system_arg (char *quoted, char const *arg);

but it's quite close.

Looking at the implementations, I notice that quotesys attempts to
generate a "pretty" string in cases where shell-quote doesn't bother.
E.g., for the string

--header=foo bar

quote_system_arg generates

--header='foo bar'

rather than

--header=foo\ bar

This is useful for GNU diffutils, since it often prints the results of
shell quoting back to the user.

We could just have two modules, but it'd be nicer to have one.  I
suppose one possibility would be to modify quotearg to quote shell
strings more prettily by using the same heuristics that quotesys uses.
This has been on my list-of-things-to-do for several years now, I'm
afraid; I mention it now only because of the proposed new sh-quote

> (I mean, for example, the simple purpose of downloading a file from
> a given URL with a timeout - this is a functionality needed by
> gettext - can be done by either a 65-line Java program or by a 200
> KB special-purpose C program called 'wget'.)

Yes, that's a real problem.  One other thought: is it convenient to
invoke Java code from C programs without the hassle of executing a new

reply via email to

[Prev in Thread] Current Thread [Next in Thread]