sed -i empty argument compatibility issue

[parv/freebsd]

On Fri, Mar 5, 2021 at 5:56 PM Gary Aitken wrote:

> On 3/5/21 2:43 PM, Bob Proulx wrote:
> > Gary Aitken wrote:
> >> I'm trying to come up with a fix for a script in a port which
> >> invokes sed. The port comes from a linux environment, and the
> >> offending line looks like this:

...

> In order to port this then _something_ must be changed.  As to what
> > must be changed that is up to you and judegement and the larger view
> > of everything in your environment.  But off the top of my head these
> > different possibilities come to mind.
> >
> > 1. Edit the script and change this to that.  This makes it run on
> > FreeBSD sed.  Of course then this does not work the other direction.
> >
> > -COMMAND sed -i "/^# /d" "${outfile}" +COMMAND sed -i "" "/^# /d"
> > "${outfile}"
> >
> > 2. Use perl.  Change that edit command to be this.  This should work
> > the same everywhere that has perl.  It does create a dependency upon
> > perl that might not have been present before.
> >
> > perl -i -lpe 'next if /^# /' "${outfile}"
>

I like it!


> > 3. Avoid -i and use a temporary file, just like in the old days.
> > However this introduces the need for temporary file handling.  But
> > maybe that isn't important here.
> >
> > sed "/^# /d" "${outfile}" > "$tmpfile" && mv "$tmpfile" "${outfile}"
>

This won't do, when ...

> 4. Introduce a "sed" wrapper in PATH that intercepts the call to the
> > real sed, detects this problematic usage case, and then DTRT does
> > the right thing with it.  This wrapper could have all of the correct
> > temporary file handling needed to make this work.
>
...

#!/bin/sh

# Set sed path & -i option based on "uname -a" output.
SED=
host_type=$( uname -a )
case "${host_type}" in
  *Linux* )
    SED="/usr/bin/sed -i''"
  ;;
  *FreeBSD* )
    SED="/usr/bin/sed -i ''"
  ;;
esac

# Set $@ to contain original arguments prefixed by sed with -i option.
set -- ${SED} $@
# Now run the sed with the arguments given.
$@


> 6. Compile GNU sed locally and install it in PATH earlier.  This
> > would probably be a generally good option globally.  However it's
> > possible you might run into portability problems in the reverse
> > case.
>

If GNU sed could be installed, this would be most agreeable.

I prefer to use the absolute path to remove ambiguity about the kind of
sed being used, especially in the above case.

- parv


Thanks for the list.  That's two more than I came up with.  I'm
> inclined to #2 (which I hadn't thought of) or #3.
>
--