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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
