GNU bug report logs - #7563
23.2; `split-string-and-unquote' mis-documented / purpose unclear

Previous Next

Full log

Message #21 received at 7563-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dave Abrahams <dave <at> boostpro.com>
Cc: 7563-done <at> debbugs.gnu.org, 1212-done <at> debbugs.gnu.org
Subject: Re: bug#7563: 23.2;
	`split-string-and-unquote' mis-documented / purpose unclear
Date: Sat, 11 Dec 2010 17:52:02 +0200

> Date: Sat, 11 Dec 2010 08:43:42 -0500
> From: Dave Abrahams <dave <at> boostpro.com>
> Cc: 7563-done <at> debbugs.gnu.org,
> 	1212-done <at> debbugs.gnu.org
> 
> > >        This function performs two types of quoting: enclosing a whole
> > >        string in double quotes `"..."', and quoting individual characters
> > >        with a backslash escape `\'.  The latter is also used in Lisp
> > >        strings, so this function can handle those as well.
> > > 
> > > 
> > > First problem: the last paragraph above is simply wrong.
> > > split-string-and-unquote doesn't perform any type of quoting; it
> > > un-quotes.
> > 
> > I changed "performs" to "supports".  Thanks for catching this.
> 
> But it's still wrong, I'm afraid.

It's not "wrong", in the sense that previously the text made it sound
as if split-string-and-unquote could actually _add_ quoting.  That is
the only thing I intended to fix there.

> As I mentioned in my original report,
> 
>     (split-string-and-unquote "foo\\ bar") 
> 
> yields a list of 2 elements (I wrote it wrong below: you get a
> trailing backslash on "foo\\")

That's by design; read the discussion I pointed to, where Stefan
explained his rationale.  You could agree or disagree with him, but
evidently these functions are useful in a certain class of situations;
see how they are used in a few Lisp packages that come with Emacs.

>   * I spent lots of time trying to suss out what was really going on
>     here and writing a clear bug report.  I did that in the hopes that
>     nobody else would waste time trying to figure this out again, and
>     I don't believe that change will prevent it.

Now that the manual explicitly mentions call-process and
start-process, which are the clients of this function, what else is
missing or unclear?  Please be specific.

>   * The functions' design still has nothing to do with shell quoting;
>     they are hard-coded to work with double-quotes and only
>     double-quotes, which is not guaranteed to work for an arbitrary
>     definition of "shell."

I believe the manual says precisely that.  If the problem is with
mentioning "shell", would removing that solve this difficulty?

> * Having now read the history of this issue, I am strongly convinced
>   that the proper thing to do is deprecate these functions.

They were introduced fairly recently, and I'm sure they were added for
good reasons.  I'll let Stefan respond in detail.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.