Re: shell-expand-line drops quotation marks [FIXED]

[Chet Ramey]

On 11/2/16 6:03 PM, Dabrien 'Dabe' Murphy wrote:

> I know this thread
> <http://gnu-bash.2382.n7.nabble.com/shell-expand-line-drops-quotation-marks-td16419.html>
> is a year old, but I do have to say I agree with the OP that
> `shell-expand-line`'s decision to perform Quote Removal seems to violate
> the Principle of Least Astonishment...
> 
> To say `shell-expand-line` "Expand[s] the line as the shell does" seems,
> shall we say, "disingenuous" — if not an outright lie...  The shell
> preserves whitespace:

As does shell-expand-line, but that's not what this example shows.  The
real issue is whether or not shell-expand-line should perform quote
removal.

> Quote Removal makes sense during command EXECUTION (since you wouldn't want
> your quotes passed in with the arguments) but it doesn't make sense during
> (readline) EDITING, IMHO...

OK. So let's talk about a mechanism to provide alternate behavior.  The
conventional way to do that in the context of key bindings is to modify
behavior based on whether or not the user supplies a numeric argument
(e.g., M-1M-C-e).
> 
>  
> Consider the following variable expansion:
> 
>     prompt% foo="one two"
>     prompt% argDump $foo
>     ARG: 'one'
>     ARG: 'two'
> 
>     prompt% argDump "$foo"
>     ARG: 'one two'
> 
>     prompt% argDump $foo [<M-C-e>]
>     prompt% argDump one two    # So far, so good, actually...
> 
>     prompt% argDump "$foo" [<M-C-e>]
>     prompt% argDump one two    # FAIL FIXED

Sure, you're just restating your argument several times.

> At the very least, I would expect `shell-expand-line` to be more or less
> idempotent; expanding the line multiple times shouldn't change the behavior
> of the command that actually gets executed:

This is not a reasonable expection.  Think of it as running a command
through `eval' several times.


> I understand it's hard to do the Right Thing sometimes:  [Still unsolved]
> 
>     prompt% alias ls="ls -F"
>     prompt% ls [<M-C-e>]
>     prompt% ls -F [<M-C-e>]
>     prompt% ls -F -F [<M-C-e>]
>     prompt% ls -F -F -F

This is actually the correct behavior.  `ls' has an alias, and that alias
is expanded.

> 
> So what's the fix, you might ask?
> diff --git a/bashline.c b/bashline.c
> index 238a190..e17a49d 100644
> --- a/bashline.c
> +++ b/bashline.c
> @@ -2689,7 +2689,7 @@ shell_expand_line (count, ignore)
>        /* If there is variable expansion to perform, do that as a separate
>          operation to be undone. */
>        new_line = savestring (rl_line_buffer);
> -      expanded_string = expand_string (new_line, 0);
> +      expanded_string = expand_string (new_line, 1);
>        FREE (new_line);
>        if (expanded_string == 0)
>         {

Nice catch.  This is pretty close, and gets you most of the way you want
to go. You'd also like a way to inhibit process and command substitution
during shell-expand-line and allow those to be performed as part of
execution to avoid side effects.

> If you're really concerned that people are actually relying on the old
> behavior, I'm sure it would be easy to create some sort of
> "shell-expand-preserve-quotes" readline variable, or some such...  Show me
> where to submit a Pull Request and I'd be happy to whip one up!  :-D

The old behavior will remain the default for now -- it's been this way for
about 25 years, after all -- but the inhibiting-quote-removal behavior
(and probably command and process substitution as well) will be available
if the user supplies a numeric argument.

> PS — Another example where `shell-expand-line` decidedly does NOT "expand
> the line as the shell does" is with globs and tilde prefixes, but I'm aware
> this is a known limitation:
> 
>     prompt% echo ~/.bash* [<M-C-e>]

It's true: globbing is not one of the shell word expansions that this
function performs, or has ever performed.  There's a separate key binding
that does this.

Tilde expansion is a little trickier, since shell-expand-line does not run
the line buffer through the shell parser to break it into words and tilde
expansion only happens at the start of a word.  (If you were to start the
command with an unquoted tilde, you'd find tilde expansion is performed.)

That's one of the reasons there is a separate key binding to perform tilde
expansion on the current word.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/