Just be glad they haven't handed over maintenance to the gnome project.
Soon grep will be a systemd module.
Surely you mean systemd-grepd -z nuts
We are stuck with egrep and fgrep (unless you like beating people)
341–350 of 354 posts
Re: We are stuck with egrep and fgrep (unless you like beating people)
#342Earlier quoted context omitted.
What makes the reasoning unconvincing for me is that it's simply wrong: argv[0] is not the name of the program being invoked. If it were, I would agree, but it's not. Rather, it's simply another argument whose default value is the name of the program being invoked, but you can pass something else in place of it if you want. Moreover, what I find surprising is seeing a knob that I can adjust, but which doesn't do anyt…
> argv[0] is not the name of the program being invoked [...] it's simply another argument whose default value is the name of the program being invoked That's your opinion. Another opinion would be that it's an interface contract with the calling program to pass the path to the program being invoked in argv[0]. This contract has been established by common practice and a corresponding expectation by most programs, even…
That's not an opinion, that's a fact. The only thing that's an opinion in what I said is what the final decision should be, not the fact that it's a mutable argument. Whereas their stance is based on false premises to begin with. If their opinion was "we realize arg0 can be set explicitly but too many people wrongly assume it can't, so we will follow the crowd" that would make their argument more compelling.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#343Earlier quoted context omitted.
> argv[0] is not the name of the program being invoked [...] it's simply another argument whose default value is the name of the program being invoked That's your opinion. Another opinion would be that it's an interface contract with the calling program to pass the path to the program being invoked in argv[0]. This contract has been established by common practice and a corresponding expectation by most programs, even…
That's not an opinion, that's a fact. The only thing that's an opinion in what I said is what the final decision should be, not the fact that it's a mutable argument. Whereas their stance is based on false premises to begin with. If their opinion was "we realize arg0 can be set explicitly but too many people wrongly assume it can't, so we will follow the crowd" that would make their argument more compelling.
The fact that it can physically be set to anything doesn't mean there isn't an implicit contract.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#344Earlier quoted context omitted.
That's not an opinion, that's a fact. The only thing that's an opinion in what I said is what the final decision should be, not the fact that it's a mutable argument. Whereas their stance is based on false premises to begin with. If their opinion was "we realize arg0 can be set explicitly but too many people wrongly assume it can't, so we will follow the crowd" that would make their argument more compelling.
The fact that it can physically be set to anything doesn't mean there isn't an implicit contract.
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 contract as somehow sufficient for establishing that it's a contract, despite what I just mentioned indicating otherwise. What contract can you point to that mandates argv[0] be set to the program name?
Re: We are stuck with egrep and fgrep (unless you like beating people)
#345Earlier quoted context omitted.
the name of an executable is like a global variable the instant it is used as data; it can be changed at any time by someone else and then behavior changes. names are not data. don't make them data. names are names.
Using argv[0] for dispatch has worked for 4+ decades. There is zero non-contrived evidence that it ever fails to work. Further, there's 4+ decades of legacy here, and it's very rude to break backwards compatibility with something like this where there's no need, no security vulnerability that must be fixed by breaking backwards compatibility.
I'm not saying it doesn't work, I'm saying that relying on it being a certain value, or one of a set of values, is like relying on the value of a global variable.
we avoid that in software development-land whenever possible, and for good reason.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#346Earlier quoted context omitted.
You are overlooking something here: I never said anything about proof. I explicitly wrote 'convincing evidence' because proof is too demanding! It's rather amusing how you have flipped from saying "you can't prove a negative" to an argument for the certainty of observable effects and the probability of consequences! (you wrote might cause problems, but everyone can see that's an unrealistic understatement of the impl…
> everyone can see that's an unrealistic understatement of the implications of the argument you are using If nobody can show an actual existing problem, or even an example of reasonable code someone could have written which would be impacted by a the printed warning, then yes, I would think that I was charitable when I wrote “might cause problems”.
What does 'charitable' mean here? Generous towards what person or point of view? As you say you have conclusively proved that there is a non-zero probability of there being problems, the use of 'might' is already trying to persuade that this possibility is next to zero.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#347Earlier quoted context omitted.
> everyone can see that's an unrealistic understatement of the implications of the argument you are using If nobody can show an actual existing problem, or even an example of reasonable code someone could have written which would be impacted by a the printed warning, then yes, I would think that I was charitable when I wrote “might cause problems”.
What does 'charitable' mean here? Generous towards what person or point of view? As you say you have conclusively proved that there is a non-zero probability of there being problems, the use of 'might' is already trying to persuade that this possibility is next to zero.
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.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#348Earlier quoted context omitted.
What does 'charitable' mean here? Generous towards what person or point of view? As you say you have conclusively proved that there is a non-zero probability of there being problems, the use of 'might' is already trying to persuade that this possibility is next to zero.
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?
Re: We are stuck with egrep and fgrep (unless you like beating people)
#349Earlier quoted context omitted.
Using argv[0] for dispatch has worked for 4+ decades. There is zero non-contrived evidence that it ever fails to work. Further, there's 4+ decades of legacy here, and it's very rude to break backwards compatibility with something like this where there's no need, no security vulnerability that must be fixed by breaking backwards compatibility.
I'm not saying it doesn't work, I'm saying that relying on it being a certain value, or one of a set of values, is like relying on the value of a global variable. we avoid that in software development-land whenever possible, and for good reason.
Your point is moot given that this works and has for decades, and you concede that point.
> we avoid that in software development-land whenever possible, and for good reason.
We also avoid breaking backwards compatibility unless it's really necessary. In this case, granting your premise for the sake of argument, the harm caused by this change exceeds the actual non-harm of the thing you're objecting to regardless of the theoretical badness of that thing.
Re: We are stuck with egrep and fgrep (unless you like beating people)
#350Earlier quoted context omitted.
The fact that it can physically be set to anything doesn't mean there isn't an implicit contract.
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.