Those two other alias bugs - w/fix for one

Those two other alias bugs - w/fix for one

[Bart Schaefer]

workers/34668

torch% alias \{='print foo'

torch% {this is a test   
foothis is a test
torch% { foothis is a test

------------
workers/34682

% alias -g S='"'
% echo S abc def S
dquote> "
 abc def S

% echo S" abc def S
"

------------

Sadly these are not the same bug (though they must be related somewhere
in the re-parse-after-expansion pass).  Patch below fixes the first one
but not the second.  Maybe there's a better way that catches both.  No
promises that this doesn't do other weird things if you go too far down
the "alias -g" rabbit hole.

diff --git a/Src/lex.c b/Src/lex.c
index 1eb0bc7..42ccdfc 100644
--- a/Src/lex.c
+++ b/Src/lex.c
@@ -1747,6 +1747,16 @@ checkalias(void)
 	if (an && !an->inuse &&
 	    ((an->node.flags & ALIAS_GLOBAL) ||
 	     (incmdpos && tok == STRING) || inalmore)) {
+	    if (!lexstop) {
+		/*
+		 * Tokens that don't require a space after, get one, else
+		 * we can't be sure to correctly lex the expansion text
+		 */
+		int c = hgetc();
+		hungetc(c);
+		if (!iblank(c))
+		    inpush(" ", INP_CONT, 0);
+	    }
 	    inpush(an->text, INP_ALIAS, an);
 	    if (an->text[0] == ' ' && !(an->node.flags & ALIAS_GLOBAL))
 		aliasspaceflag = 1;

Re: Those two other alias bugs - w/fix for one

[Bart Schaefer]

On Mar 18, 10:50pm, Bart Schaefer wrote:
}
} Sadly these are not the same bug (though they must be related somewhere
} in the re-parse-after-expansion pass).  Patch below fixes the first one
} but not the second.  Maybe there's a better way that catches both.

Both bugs result from the alias expansion text merging with the following
text into a single longer token when the expanded input is re-parsed.

The patch I posted fixes this for the first bug by separating the expansion
into its own token, via an inserted space.

In the case of quote marks, this is not possible -- anything appended to
the quote (except a matching quote) becomes part of the quoted-string.

Therefore I think we really do need to figure out the deeper problem.  One
question is, why is the history reconstructed from the lexed token strings
instead of retaining the original input string?