Antonio,
> POSIX says the same[1]
Yeah, we seem to be reading the same text from different sources, ahah.
> and I think it is pretty clear: '%' shall be
> replaced with the remembered pathname, not with a modified version of
> the remembered pathname.
I realize this is kind of Ship of Theseus argument happening here, but
let’s hypothesize here: say, the user opens a file called “*” with ed:
ed "*"
Then they try to open the same file in another instance of ed, kinda
recursively:
!ed %
And boom! the new instance opens something else and not the file called
“*”. The user is likely confused. And to me, this is in exact opposition
to what you set out as an aspiration here:
> Ed is not supposed to modify the remembered
> pathname [...]
ed is not supposed to modify the remembered pathname in any way,
including (in particular) expanding special characters in it. Because if
it’s interpreted by the shell, it’s no longer the same remembered
pathname that ed is supposed to preserve. And not the file the user
expected to edit and act on.
So, pursuing the exact same goal—preserving the remembered pathname—I
come to absolutely opposite conclusions: % should be escaped so that the
identity of the pathname is preserved. Interpreting it as some shell
glob is untruthful to the initial pathname.
% is supposed to be the same name of the same file, and not a genie lamp
that may or may not explode.
> I guess the only portable thing you can do is to only search for words
> that are valid file names.
Again, preserving the pathname as it is, regardless of what chars there
are in it, without additional interpretation, is perfectly consistent
with POSIX and kinda portable too (although OpenBSD ed 7.4 inherits the
same bug as GNU ed here.) It is a matter of how one reads this pretty
benign paragraph.
I implore you, please, preserve file names across calls by escaping the
special chars that might break the identity of the remembered pathname
we all care about so much.
Best of luck,
--
Artyom Bologov
https://aartaka.me
