351–354 of 354 posts
Earlier quoted context omitted.
I thought I was being charitable when acknowledging that there might be a chance of a problem, when I in fact believe there not to be one.
If you were presented with an actual case, would you change your mind over whether introducing this warning is advisable?
Earlier quoted context omitted.
This isn't just "I can set it to something else if I go out of my way", this is "systems provide well-documented and standardized methods for setting this parameter to something else, and there are some widely used programs using precisely this feature." It's not common but that's exactly what default parameters are for: uncommon-yet-valid use cases. Yet you seem to treat your opinion that this is an implicit contrac…
Established common practice. The egrep use case, btw., wouldn't deviate from that. In fact, it would rely on argv[0] being truthfully set to the sym/hard link's name.
There are two practices here. One is passing the program name to arg0. The other is never making some use of arg0. Both of these are established because they're the most convenient things to do by default, and because people rarely have a reason to deviate from them. That's it. Heck, if there was some contract to ignore arg0 then people wouldn't feel any contractual obligation to pass the program name to begin with, since it should be getting ignored anyway - that argument is pretty self defeating. Moreover, I think your position is effectively equivalent to saying "if you don't want a common practice to become a contract, then you must go out of your way and inconvenience yourself to deviate from that practice for absolutely no other reason than to make this very statement true", which is a rather bizarre (and inefficient) expectation from everyone around you.
Earlier quoted context omitted.
If you were presented with an actual case, would you change your mind over whether introducing this warning is advisable?
Yes, of course. If the case is reasonably likely to occur in the real world and have real world impact, that is. And I would assume that the GNU grep developers would agree with me.
If we could prove there would be no downside, then plausible problems could be ignored as merely hypothetical, and there would be no need to posit offsetting benefits. The question the GNU grep developers might want to consider is whether the supposed upside will have sufficient material consequences for their purposes.
Earlier quoted context omitted.
The shell happens to be a programming tool and not just an interactive command interpreter. There are whole books on how to write shell scripts portably across various Unix-y platforms. Many of the examples in those books will now throw warnings on systems using the GNU tools.
If a book on writing portable shell scripts across *nix platforms depends on commands not specified by POSIX, I don't think those books are doing their job very well.