Re: GNU ed 1.20 released

[Andrew Moore]

On 2/6/24 11:29, Antonio Diaz Diaz wrote:
> > One suggestion: it might be helpful, in addition to setting dot,
> > to print dot. In the particular case of `systemctl edit`, the user 
> > doesn't manually invoke `ed +4 ...', so it's easy to assume that
> > dot is at the end of file. Even printing a blank line in this case
> > can be a helpful reminder.
>
> Do you mean executing at startup a '.n', '.l', or '.p' command when 
> setting the current line in the command line, or something else? I
> think I would need a more precise description of the desired behavior
> before implementing anything.

Yes, execute a `p' command (and only that) after setting dot when ed
is invoked with the command-line option `+N' or '+/RE/' or `+?RE?'.
And specifically, do not re-print the line number or search command:
that would be redundant, since it's already given on the command line.
Yes, in the case of `systemctl edit', the user doesn't see `+4', but I
would argue that that's a systemctl bug (i.e., `systemctl edit'
shouldn't invoke an external editor with command-line option `+4'
because not every editor should be expected to support that.)

Vim's ex (vex) does support `+CMD' syntax for an arbitrary command CMD. 
But vex does not appear to support multiple commands, e.g., `ex +CMD1 
+CMD2'.  I feel that ed would be better served by a sed-like `-e CMD' 
option instead.

> > Regarding filenames, Unix allows nearly any character in a
> > filename. I'm curious what prompted you to handle control
> > characters specially?
>
> This defect report: https://www.austingroupbugs.net/view.php?id=251 
> (Forbid newline, or even bytes 1 through 31 (inclusive), in
> filenames)

Oh, ha! Forbid unprintable characters in Unix filenames?  Good luck with 
that! It's like burying one's head in the sand rather than addressing a 
security issue head on.  Bad idea!
> > A minor issue with the f command is that the following works:
> >
> > ed -p '*' --unsafe-names $'filename\nwith\nnewlines' *f 
> > filename\012with\012newlines *
> >
> > But trying to set such a filename with the f command doesn't seem
> > to:
>
> How could it work without backslash-escape processing?

In my implementation, a backslash-escaped newline is preserved. This was 
done to facilitate shell commands.  For example, I am able to do:

$ ed -p \*
*! a='hello\
world'\
echo "$a"<RET>
hello
world
*

As a side-effect, I guess, the following works as well:

*f hello\
world<RET>
hello
world
*

By not preserving backslash-escaped newlines, GNU ed shell commands are 
limited:

$ gnu-ed -p \*
*! a='hello\
world'\
echo "$a"<RET>
sh: line 1: : command not found
*

The closest equivalent with GNU ed appears to be:

*! a='hello\
world';\
echo "$a"<RET>
helloworld
*