Wine-Staging 5.14 Release In 2020 Finally Implementing... Findstr

[ssokolow]

No the fun fact is majority of the programs that use that function wine has always returning 0 to say what ever was sent was a match is a perfectly functional answer.

FINDSTR is a CLI tool, not a function.</pedant>

(That's probably part of the reason it was OK to leave it as a stub for so long.)

[oiaohm]

FINDSTR is a CLI tool, not a function.</pedant>

(That's probably part of the reason it was OK to leave it as a stub for so long.)

https://github.com/wine-mirror/wine/blob/master/programs/findstr/main.c

Findstr was implemented to stub level because it is used by installer and few other things. Interesting enough majority are asking for a compare that should always be true.

Really being CLI tool does not change things much. There are a lot of other CLI tools that wine provides that are fleshed out a lot more than findstr has been because the majority of use cases in fact need processing to get answer.

Yes there are some other CLI tools that may never be properly fleshed out in wine as well.

So really being a CLI tool has nothing much to do with it. Its more how often something is used and how often stub is good enough.

There are two factors at play
1) More something CLI/Function is used the more users there are of it.
2) How often the stub does not work is a factor for how many effected people who might put in the effort to fix it.

There are a lot of functions and CLI parts that are stub that there is either not many users of that function/CLI bit at all or majority of users it works fine with the stub return 1 value. Really there are quite a few cases where its over 90%+ works as the stub value this comes kind of insane because you are looking at 99.999% more effort to get less than 10 percent gain(yes it was like 0.001% effort implementing the stub).

[ssokolow]

Really being CLI tool does not change things much. There are a lot of other CLI tools that wine provides that are fleshed out a lot more than findstr has been because the majority of use cases in fact need processing to get answer.

Yes there are some other CLI tools that may never be properly fleshed out in wine as well.

So really being a CLI tool has nothing much to do with it. Its more how often something is used and how often stub is good enough.

My point is that, from what I've seen, Windows applications are much less likely to invoke subprocesses to access functionality than POSIX ones are.

[oiaohm]

My point is that, from what I've seen, Windows applications are much less likely to invoke subprocesses to access functionality than POSIX ones are.

Yes and no. General applications what you said is true. Installers scripts on the other hand like NSIS scripts are likely to use a lot subprocesses to access command line for any feature installer script does not provide.

https://nsis.sourceforge.io/NsExec_plug-in

Thing is most installer script if the findstr compare fails the application is not going to be installed anyhow. So your most common usage of findstr is installer scripts with requirement that match is successful so in other words wine default sub is almost perfect for that. Findstr is basically used a lot more than one would expect ssokolow but the usage case 90%+ of the time does not require failure.

[ssokolow]

Yes and no. General applications what you said is true. Installers scripts on the other hand like NSIS scripts are likely to use a lot subprocesses to access command line for any feature installer script does not provide.

https://nsis.sourceforge.io/NsExec_plug-in

Thing is most installer script if the findstr compare fails the application is not going to be installed anyhow. So your most common usage of findstr is installer scripts with requirement that match is successful so in other words wine default sub is almost perfect for that. Findstr is basically used a lot more than one would expect ssokolow but the usage case 90%+ of the time does not require failure.

Ahh. Makes sense.