mmt

No, I'm not mistaken about precision because I never brought it up. It's a strawman solely of your own construction. (I, instead, suggested a much less precise rule, prohibiting all replies/discussion.)

You're implying that the rule here is written like the guidelines, but it isn't.

The guidelines provide some kind of explanation, reasoning, or purpose adjacent to a rule.

The "try explain better, on a case by case basis" doesn't actually succeed, only the same reason, in, perhaps, a different word order.

Surely you don't need that kind of repetition of explanation of purpose for the guidelines, since it's already there to be read. Why such resistance to doing that here, too?

If you're going to prevent me from responding and having my response visible, then go ahead and just delete my original comment.

I have, of course, personally read all these justifications for the rule before, but they do nothing to address my question.

The problem here is there's no way to figure out the "spirit" without having followed a rather extensive history - and the fact that the same justifications are repeated every time the rule is questioned in any way is testament to your already realizing that.

Why not just have the rule say what's actually meant, instead? If the desire is "no replies that are or might spark a controversy", then it's clearer for the rule to say that, instead of the vague, terse prohibition on complaints.

Better yet, go all the way and forbid replies entirely. That achieves the same stifling of conversation, in this one context where it's deemed "terrible", without the enforcement that can seem capricious and arbitrary (as you say yourself, "it's often not easy to tell the difference") and can needlessly shame an otherwise well-intentioned commenter.

Keeping it terse and relying on "spirit" is an excuse to maintain that aribtariness.

The problem here is there's no way to know the "spirit" without knowledge of its history.

Why not just say what you mean, instead? If the desire is "no replies that are or might spark a controversy", then why doesn't the rule say that?

Better yet, go all the way and forbid replies entirely. That achieves the same stifling of conversation, in this one context where it's deemed "terrible", without the enforcement that can seem capricious and arbitrary (as you say yourself, "it's often not easy to tell the difference") and can needlessly shame an otherwise well-intentioned commenter.

How is this posting to complain?

It's a question about a potential existential threat in the form of recent regulatory scrutiny.

What about the ongoing cost of waste and eventual cost of decommissioning? Are those affected by quantity of fuel used (or, more specifically, by Transatomic's design)?

Indeed, appending an empty string to -i doesn't modify it in any way, AFAIK.

It's that the GNU version doesn't require an argument, but, if an argument is to be provided, it must be done as part of the flag, not as a separate element of argv. The MacOS version allows either way of providing an argument, so -i.orig tends to be portable (assuming the -i flag is supported in the first place).

Differences in how "traditional" (be they sysv or bsd) versus gnu utilities handle flags and arguments [1] is very well rooted in history, and is hardly unique to sed.

I suspect the main reason this has been forgotten is that Linux, which ships with gnu utilities, has been so dominant for so long, though, even before that, it was difficult to find a then-current unix on which gnu utilities couldn't be installed.

[1] As the sibling comment points out, the source of difference is getopt, of which there were more than just two versions.. including not even using a library

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

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

> the right sterile environment

This has echos of No True Scotsman. Computer storage media also have ideal conditions that can be used to extend their lifetimes (though, granted, not indefinitely, AFAIK).

What about in real conditions, subject to things like temperature variations (including "extreme" heat that non-operating computer hardware can do just fine in), exposure to light, humidity from the air (to put it back into aqueous solution occasionally), and common oxiders found floating around in the air?

Could one rely on an arbitrary single strand to last even 5 years in an office environment, or are numerous, RAID1-style, copies required to maintain fidelity?