GNU bug report logs - #54486
29.0.50; Eshell `escaped' string property can "leak" into output

Previous Next

Package: emacs;

Reported by: Jim Porter <jporterbugs <at> gmail.com>

Date: Mon, 21 Mar 2022 03:53:02 UTC

Severity: normal

Found in version 29.0.50

Done: Jim Porter <jporterbugs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 54486 <at> debbugs.gnu.org
Subject: bug#54486: 29.0.50; Eshell `escaped' string property can "leak" into output
Date: Mon, 21 Mar 2022 14:19:59 +0200
> From: Jim Porter <jporterbugs <at> gmail.com>
> Date: Sun, 20 Mar 2022 20:52:43 -0700
> 
> When using Eshell, it's possible to inadvertently add an `escaped' 
> string property to strings, resulting in some pretty surprising 
> behavior. Starting from "emacs -Q --eval '(eshell)'":
> 
>    ~ $ setq var (list "foo" "bar")
>    ("foo" "bar")
>    ~ $ echo $var
>    ("foo" "bar")
>    ~ $ echo $var[0]
>    foo
>    ~ $ echo $var
>    (#("foo" 0 3
>       (escaped t))
>     "bar")
> 
> This happens because when the `$var[0]' argument is parsed in the third 
> command, the function `eshell-interpolate-variable' wraps the 
> code-to-be-called with `eshell-escape-arg'. That function adds an 
> `escaped' property to any string passed into it.
> 
> The `escaped' property is used to indicate that the string should be 
> treated literally (i.e. any special characters like "$" will no longer 
> have any special meaning in Eshell). That's the right *behavior*, but 
> ideally, there'd be a way to do so that doesn't involve manipulating the 
> string like this. Eshell can't know the lifetime of the string, and it 
> seems like a bad idea in general to go around messing with string 
> properties just because you referenced that string somehow in Eshell.
> 
> I can't think of an obvious fix for this though. Any ideas?

Why exactly do you think this should be fixed?  I don't think I
understand that from your description.  We have many features that add
text properties to strings, so why is this one different?  About the
only thing I can think of is to add this property to the default value
of yank-excluded-properties, but that's all.




This bug report was last modified 175 days ago.

Previous Next


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