[mmt]

This strikes me a bit like a "doctor, it hurts when I go like that" problem.

What's the use case [1] for using a zero-length suffix argument (i.e. editing the file "in place" with no backup)?

It's not as if sed is operating on the file actually in place. It uses a temporary file anyway. Varying levels of reliability/portability can be achieved by controlling that temporary file (or subsequent artifacts) oneself, the first level being just to "rm" the backup.

[1] Assuming this is in scripting, since the interactive situation is easily enough adjusted on the fly

[mdaniel]

Heh, if I had a dollar for every time I have encountered "what are you doing" while dealing with shell, or (worse!) Makefile, tomfoolery in open source projects, I'd be retired. So, in some sense you're right, but ultimately in the "but it doesn't matter" way because I'm not the only one writing shell, nor the only machine upon which things have to build.

[mmt]

At some point, though, if you're the one complaining about a specific detail, in a way, you're the (only) one.

I've seen plenty of un-portable shell scripting, too, but my professional experience includes a time where, essentially, no software [1] could be assumed to be portable, and I did get some dollars for every time, since it was part of my job to ensure as consistent a build environment as possible.

In light of your clarification, my question becomes: isn't it actually good to have such assumption-breaking differences in that they call attention to something that is likely to have a broader pattern of non-portability, in which case a broadly effective [2] workaround can be applied?

[1] Even/especially GNU tools, where there was something of an assumption that the OS would provide at least fairly complete BSD-compatibility. The existence, and evolution, of libiberty and the autotools, among others, should be instructive.

[2] e.g. installing (all the) GNU tools and putting them first in the path on a system that otherwise uses "traditional" syntax