Opinion Poll: CLI Database Filters and Future

[Midas]

My experience leads me to believe that 1) is the surest (and the easiest...) way to get to 3) -- as detailed in Andrew's post above.

So sayeth Linus' Law, brought forth by the great Raymond: given enough eyeballs, all bugs shall be crushed... here's hoping it isn't the reverse.

[vevy]

My experience leads me to believe that 1) is the surest (and the easiest...) way to get to 3) -- as detailed in Andrew's post above.

So sayeth Linus' Law, brought forth by the great Raymond: given enough eyeballs, all bugs shall be crushed... here's hoping it isn't the reverse.

I don't want to add many more tools until the database is at least basically usable. Since there is no other comprehensive database out there, I say it is worth trying. Considering the scale of the effort, I give myself months/years to do it, but it should appear with the current size if it is gonna be doable or not.

Despite what may appear, I don't like deluding myself!

[Andrew Lee]

Windows's echo adds a line break if you pass it to clip: echo string|clip. yecho has an option to strip line breaks from the end.

Both sfk echo and yecho strip quotes from the echoed string (echo "string"), Windows's doesn't.

Plus many other options, but I just wanted to mention easily missable differences.

Let's just take this ridiculously simple example that you have given before, and work on this.

I am writing a batch file, and I find that Window's "echo" adds link breaks, which is breaking my script. Tell me how all the tons of filters and badges and use cases will help me find an "echo" that doesn't do that.

Now I have found and embraced yecho. I am writing another batch file, but its behaviour of stripping quotes from echoed string is keeping my new script form working. Tell me again how all the tons of filters and badges and use cases will help me now.

[vevy]

I am writing a batch file, and I find that Window's "echo" adds link breaks, which is breaking my script. Tell me how all the tons of filters and badges and use cases will help me find an "echo" that doesn't do that.

First, I want to say that I used "echo" as an example for why you'd want to include all the different tools; i.e. example of comprehensiveness not for filters directly.

But OK, I'll bite!

Clicking on the "echo string" use case will give you, say, 10 tools*. That's not a big number and you can scan them manually without much trouble, I agree on that.

If you search for "echo", which I personally start with most of the time, you'll probably get more results, you may want to exclude (filter out), say, collections, etc and focus on tools.
---------------
(*) Windows's echo, yecho, sfk echo, Coreutils's echo, NYAGOS's echo,TCC LE's echo, printf, BusyBox's echo and printf, uutils's echo and printf, etc.




But let's try situations with more results. For example "hash" will probably have dozens of results.

• I'd start by excluding old/discontinued tools, because I want good coverage of algorithms.
• Also, maybe I know of a recent vulnerability affecting many tools, so I'd also filter by a certain date.
• I may want to share my solution/batch file with others, so I'd prefer Windows-included tools.
• I may want to use Windows-only tools but prefer a ready-made batch file.
• I may want to easily create hash check files (.md5 etc), so I'd filter by the use case "uses coreutils hash format" (which some tools don't advertise) in addition to my search terms.
• I may be a fan of developer John Smith, so I'd quickly want to filter by him to see if he has a hash tool.
• I may want to quickly see if one of the "multi-tools" I have already supports that function so I filter by "Subcommand".

• Other than search, when you want to browse a listing or a category here, you should be able to start with the tools that satisfy your criteria by filtering out others.

• If I want a network-facing tool, I would really want an actively-developed one. Same with PNG and MP3 tools, etc because of new format variations.

• I may think that the separation between archiver and compressor is not for me and I want search results that support both in the same tool.

• etc, etc.

All these are not essential. They can be done manually and some of them can be done by other means or by splitting your steps. Filters just make life much easier!

Now I have found and embraced yecho. I am writing another batch file, but its behaviour of stripping quotes from echoed string is keeping my new script form working. Tell me again how all the tons of filters and badges and use cases will help me now.

You try them yourself. I can't know every last use case that may arise. I can and want to help you filter by other criteria relevant to you, so that you focus on getting that tool. Again, that was an example of comprehensiveness not filtering, so you may wanna try them all if you have no other preference?

PS. There is another field I had in my notes for a while (other things had priority) which is "Ease of use" or "Noob-friendliness"! This also could be very helpful to filter by (easy, intermediate, hard), although it would be subjective. It can be democratized by averaging votes though!

[SYSTEM]

But let's try situations with more results. For example "hash" will probably have dozens of results.

Your example is pushing it...

I'd start by excluding old/discontinued tools, because I want good coverage of algorithms.

Do you? Chances are that you'll either want something that uses an already popular algorithm like MD5 (which is supported by almost every checksum calculator) or alternatively something as new as possible... like SHA-3, which was published in 2015. If you were to use a filter to search for checksum calculators which might be SHA-3 compatible, you'd want to manually set the earliest allowed "last updated" time to 2015 instead of ticking a "not discontinued" box which would use a threshold decided by someone else.

Also, maybe I know of a recent vulnerability affecting many tools, so I'd also filter by a certain date

As explained above, you'd want "filter by date" in case you want a "good coverage of algorithms", so you're repeating yourself here.

I may want to share my solution/batch file with others, so I'd prefer Windows-included tools.

Your only option in that case would be PowerShell Get-FileHash, which was introduced in PowerShell 4.0 which has shipped with Windows since Windows 8.1. (On older versions of Windows, as well as Linux and macOS, you can manually install its successor PowerShell Core.)

Also note that PowerShell scripts are not allowed to run by default, so you'll need to instruct other users of your script to enable scripts.

So, yeah... while calculating hashes is possible with Windows-included tools only, there are significant caveats.

I may want to use Windows-only tools but prefer a ready-made batch file.

Explain. How do filters help here?

I may want to easily create hash check files (.md5 etc), so I'd filter by the use case "uses coreutils hash format" (which some tools don't advertise) in addition to my search terms.

"Uses coreutils hash format" sounds like a poor use case to me. If you want a hash calculator that uses the coreutils format, the obvious choice is to use coreutils tools themselves...

I may be a fan of developer John Smith, so I'd quickly want to filter by him to see if he has a hash tool.

In general, it's unlikely your favorite developer would have the tool you want.

I may want to quickly see if one of the "multi-tools" I have already supports that function so I filter by "Subcommand".

This one I acknowledge as a potentially useful filter.

[vevy]

Your example is pushing it...

Why? You think the number is exaggerated?!

Do you? Chances are that you'll either want something that uses an already popular algorithm like MD5 (which is supported by almost every checksum calculator) or alternatively something as new as possible... like SHA-3, which was published in 2015.

This is my general attitude with tools. Don't get a discontinued one unless you have to (no updates, no support for latest standards, no chance for feedback, tools are often old, etc).
I do use SHA-3 among others. Also, there are a number of "up-and-coming" algorithms (so multiple dates). So both discontinued and filter/sort by date are at play here.

Even if I "mis-assigned" the appropriate filter for "algorithm coverage" (discontinued badge instead of date filter), the point still stands. I'd still use discontinued first thing to "thin the herd".

If you were to use a filter to search for checksum calculators which might be SHA-3 compatible, you'd want to manually set the earliest allowed "last updated" time to 2015 instead of ticking a "not discontinued" box which would use a threshold decided by someone else.

Yeah, me! But seriously, I want consensus, and even if it was decided by someone else, it says the duration in the FAQ.

As explained above, you'd want "filter by date" in case you want a "good coverage of algorithms", so you're repeating yourself here.

The suggestion to use date filter for "good coverage of algorithms" came in your post!!

Your only option in that case would be PowerShell

There is also Certutil since Vista. Also, hash is just one example. There are loads of tasks that can be done using Windows-included tools.

I may want to use Windows-only tools but prefer a ready-made batch file.

Explain. How do filters help here?

There is a suggested badge (#45) for "Batch" file. Also see the FAQ (under What Is Included).
A lot of tools can be replaced with batch files of Windows-native tools. That is part of the beauty of IPC and CLI pipes!

"Uses coreutils hash format" sounds like a poor use case to me. If you want a hash calculator that uses the coreutils format, the obvious choice is to use coreutils tools themselves...

The hash verification files used all over the web (example) use that format. It is the de facto standard regardless of one's preferred hashing tool. This is why many tools include supporting Coreutils format in their help or use it by default.

In general, it's unlikely your favorite developer would have the tool you want.

And they could! And it would be nice! Also, usually one has favorite developers. Also some devs are very prolific!

----------------

All in all, I feel that a lot of these stress how the filters wouldn't be perfect, but they don't have to, in order to be useful. They just help!

I may want to quickly see if one of the "multi-tools" I have already supports that function so I filter by "Subcommand".

This one I acknowledge as a potentially useful filter.

Thanks for that at least, I guess!

And thanks for the challenge, it made me research and clarify my position better!

[vevy]

By the way, if someone, by any chance, saw a good reason for filters, you can change your vote!

[SYSTEM]

There is also Certutil since Vista.

Okay. I wasn't aware of it. Still, the documentation suggests it's designed to be used when dealing with digital certificates, not for calculating hashes of random files you have laying around.

Also, hash is just one example. There are loads of tasks that can be done using Windows-included tools.

Fair.

I may want to use Windows-only tools but prefer a ready-made batch file.

Explain. How do filters help here?

There is a suggested badge (#45) for "Batch" file. Also see the FAQ (under What Is Included).
A lot of tools can be replaced with batch files of Windows-native tools. That is part of the beauty of IPC and CLI pipes!

I had missed the idea to include batch scripts in the database. The whole idea sounds like bloating the DB to me...

"Uses coreutils hash format" sounds like a poor use case to me. If you want a hash calculator that uses the coreutils format, the obvious choice is to use coreutils tools themselves...

The hash verification files used all over the web (example) use that format. It is the de facto standard regardless of one's preferred hashing tool. This is why many tools include supporting Coreutils format in their help or use it by default.

Alright, but even in that case, I suspect an average visitor in the CLI database may not be aware of the format (or especially that it's called a coreutils format), so they may not use the use case filter even if it would be useful.

All in all, I feel that a lot of these stress how the filters wouldn't be perfect, but they don't have to, in order to be useful. They just help!

Yeah, they obviously have nonzero utility... the question is more whether they're worth the effort.

[Andrew Lee]

This is my general attitude with tools. Don't get a discontinued one unless you have to (no updates, no support for latest standards, no chance for feedback, tools are often old, etc).

The default should be don't even list a discontinued app unless the consensus says make an exception. Don't do it for the sake of "comprehensiveness". This shouldn't be an encyclopedia.

By the way, if someone, by any chance, saw a good reason for filters, you can change your vote!

After all the recent arguments, my position on your idea of filters still stands. I don't see how they help to solve actual problems (like finding an echo that doesn't emit linefeeds, or finding a hash util that doesn't have a weird bug etc).

I had missed the idea to include batch scripts in the database. The whole idea sounds like bloating the DB to me...

I totally second that

All in all, I feel that a lot of these stress how the filters wouldn't be perfect, but they don't have to, in order to be useful. They just help!

Yeah, they obviously have nonzero utility... the question is more whether they're worth the effort.

I would say, NO?

[vevy]

Okay. I wasn't aware of it. Still, the documentation suggests it's designed to be used when dealing with digital certificates, not for calculating hashes of random files you have laying around.

True. But since it is probably the only CLI tool built into Windows, it is included in many "how to hash" lists and tutorials. You make do with what you have!

I had missed the idea to include batch scripts in the database. The whole idea sounds like bloating the DB to me...

See my answer to Andrew below.

Alright, but even in that case, I suspect an average visitor in the CLI database may not be aware of the format (or especially that it's called a coreutils format), so they may not use the use case filter even if it would be useful.

I see your point. It is about discussing where to draw the line. I think if most(?) tools support it but some don't, it is a good point of differentiation.
Also, we can add notes in the use case page (other names for the use case, examples, explanations/links, etc).

Yeah, they obviously have nonzero utility... the question is more whether they're worth the effort.

That's the question. I think it is worth it. See below.

[vevy]

The default should be don't even list a discontinued app unless the consensus says make an exception. Don't do it for the sake of "comprehensiveness". This shouldn't be an encyclopedia.

A lot of discontinued tools are still fully functional. Some are unique.
I wouldn't want comprehensiveness if there was a good comprehensive DB elsewhere. There isn't even a bad one!

After all the recent arguments, my position on your idea of filters still stands. I don't see how they help to solve actual problems (like finding an echo that doesn't emit linefeeds, or finding a hash util that doesn't have a weird bug etc).

You don't have to keep using that kind of example, because this is not what filters solve.
Comprehensiveness does. It shows you all the tools that could solve your problems. Filters make comprehensiveness manageable.

I totally second that

A cursory look into stackoverflow or many forums would show you people solving use cases with batch files. And people asking for batch file solutions.

Again, this comes back to the idea of gathering all CLI solutions to use cases so that the user can choose. A batch file behaves just as a CLI tool. Plus, it is editable!

Yeah, they obviously have nonzero utility... the question is more whether they're worth the effort.

I would say, NO?

Is it that filters are hard to make or are they doable but you don't find a comprehensive CLI DB worth it?

I think I typed "comprehensive" half a dozen times in this post! But it all comes down to that! I made my case for them earlier.


------------
Btw, by using things like promotion/demotion and hiding, you can get much of the benefit of a curated DB.

[Andrew Lee]

Is it that filters are hard to make or are they doable but you don't find a comprehensive CLI DB worth it?

Those are the wrong questions.

The right answers are:

- Filters are not worth it
- Comprehensiveness is an illusive and not necessarily useful goal

[vevy]

Is it that filters are hard to make or are they doable but you don't find a comprehensive CLI DB worth it?

Those are the wrong questions.

The right answers are:

- Filters are not worth it
- Comprehensiveness is an illusive and not necessarily useful goal

Do you want me to stop arguing?
If not, could you address the Pros and Cons of comprehensiveness I linked above?

And it is not elusive or illusory. Perfection is. Good enough isn't.
Comprehensive DBs already exist everywhere, just none for CLI.

[Andrew Lee]

If not, could you address the Pros and Cons of comprehensiveness I linked above?

My goodness, you just don't get it, do you? (or maybe it's us who don't get it )

An idea can theoretically be right and lofty and beautiful, yet not very workable in practice. The last time we tried utopia, we beget communism instead. I mean, how do you argue against the lofty ideal of "from each according to his ability, to each according to his needs"?

Can I provide an academic, point-by-point rebuttals against the benefits of comprehensiveness? I can't, and I won't. But if you are the only person in this community involved in making this a reality (whether it's coding, or maintaining the db's content), will it still work? Do you think you are motivating and rallying others to your call by continuing with this line of argument?

For the moment, what's important is the story, and your story is simply not selling to me at all (nor do I sense a lot of excitement from the rest), because I fail to see how it can be useful. The cost-benefit just doesn't make sense to me. Sorry.

[vevy]

But if you are the only person in this community involved in making this a reality (whether it's coding, or maintaining the db's content), will it still work?

I welcome any help but that was the idea.

Do you think you are motivating and rallying others to your call by continuing with this line of argument?

I may not be the best motivator or communicator. All I could do is try meet you "interest" requirement by arguing for what I believe on merit as I see it.

For the moment, what's important is the story, and your story is simply not selling to me at all (nor do I sense a lot of excitement from the rest), because I fail to see how it can be useful. The cost-benefit just doesn't make sense to me. Sorry.

There is not much I can do then. In any case, thanks for your past help.