Re: Rationalizing sed -i/-I (in-place editing) argument handling

On 2021-03-08 12:13, Ed Maste wrote:
> A relatively minor but longstanding incompatibility between FreeBSD
> and many other systems is the way sed handles backup files for
> in-place editing -- sed's -I and -i options. GNU sed and other BSDs
> accept an optional argument: -I.bak will save a backup file with a
> .bak extension, and -I with no argument will not create a backup file.
> FreeBSD currently accepts either -I.bak or -I .bak to save a backup
> with the given extension, and -I "" (an empty argument) to specify no
> backup.
> 
> I've been tripped up by this in the past and I know many others have.
> Most recently tobik_at_  filed PR 254091 for this. Now, I think a single
> change to make -i/-I to be compatible with other sed implementations
> in one step is too much of a POLA violation, but I think it can
> reasonably be done in stages:
> 
> 1. Update the man page to indicate that -i/-I should not have a space
> between the flag and the extension. This is compatible with current
> FreeBSD sed, other BSDs sed, GNU sed, and my proposed changes below.
> No backup is still a special case and remains as -I "".
> 
> I've opened https://reviews.freebsd.org/D29128 with proposed man page 
> changes.
> 
> 2. Continue accepting -I .bak, but emit a warning suggesting the use
> of -I.bak instead.
> 
> 3. Change -I/-i to getopt optional arguments, but keep a special case
> for -I/-i "". At this point -I .bak becomes invalid as with other
> seds, and specifying no backup can be done with either -I "" or -I
> with no argument. This relies on an empty argument having no other
> sensible interpretation.
> 
> 4. Continue accepting -I "" to specify no backup, but emit a warning
> suggesting the use of -I with no argument.
> 
> 5. Retire the special case for -I "".
> 
> These steps could be done over an extended period of time (such as one
> major release to another) - this is most important between steps 2 and
> 3.
> 
> Please let me know what you think, and if there's something I've missed.
+1
This seems more than a reasonable course of action. :-)
Thanks!