Egregoros

@WandererUber i mean, that's a fine idea as far as it goes, but linux cli tools historically are loathe to fiddle with things because some bit of perl script that is currently keeping the world financial markets from imploding depends on the options being stable
IIRC homebrew does a lot of these things and tosses them in /etc/bash_completions.d or something like that
(i don't use homebrew anymore because in the past it made such a goddamn mess of things i had to exorcise my mac and now i'm gunshy)
in any event any wish that this glorious future will come to pass is for naught because people will just ask an LLM to spit out whatever command is needed and that'll be the Done Thing until the sun burns out

@WandererUber interestingly (well, interesting to me anyway), i've been teaching teenagers how to navigate the command line
i understand the frustration as well as anybody could
but as i told the kids who more or less ask the same questions you're asking, developer time is a zero sum game
have you ever looked into how a man page is made? there are tools to make it simpler, but even so, groff is like it's own DSL
for pretty much all commandline tools, the man page is the single source of truth outside of reading the source
if you're going to ask the developers to also generate something on top of that, man, that's not going to happen
spend some of your own precious time and come up with an interactive shell script wrapper for yt-dlp and see how easy (or not) it is to do so, maybe you'll get an idea of the complexity of this
for that matter, bone up on some tcl/tk and make a gui version, that's kind of tcl/tk's raison d'etre, and tcl is pretty simple

@WWIII_ENJOYER @JoshuaSlocum it's really water upon my mill that writing a man page is also its own huge thing, because basically all I'm proposing is an interactive man page, or at least have some pages of the manual be interactive and walk you through the common options.
You're not discussing the utility, you're not discussing if it is "the way" to do it, you're not even explaining why what I am talking about would be comparatively hard. In the end you just want to signal that you are an expert. Which is especially stupid because I never even said it was easy or was naive about it. But apparently is/ought goes over your head. very silly. Let's just have an actual discussion about it, like Joshua and I did.

@WandererUber @WWIII_ENJOYER >it's really water upon my mill that writing a man page is also its own huge thing
well, not really
it is done that way for historical reasons, and changing it in a substantial way has not yet proved worth the trouble
(see: GNU's info pages not doing much of anything at all outside of GNU tools)
the basics of your idea isn't particularly new, OpenDoc, CORBA, OLE are at their core a version of this sort of thing, and none of them caught on
partially because "oh God, not another thing", but also because the complexity of this sort of thing grows exponentially and turns into a mess quite quickly
the history of computing is bad ideas getting baked in "because compatibility", but nobody complains too much so long as the unix "do one thing, use text streams for I/O, never bathe" way is followed

@JoshuaSlocum @WWIII_ENJOYER The point is that building man page is not "the easy thing" and what I said "the hard thing", that's what's water upon my mill. They're already investing a ton of time into it, just into something, that was my initial claim, is inferior.

please don't explain to me why it is the way it is. I know that.

>OpenDoc, CORBA, OLE
not at all what I am talking about
Bro thinks about some weird architecture changes when all I want is a literal wizard so I can learn the tar flags on the go. Why are the simplest things the hardest to explain?

@WandererUber @WWIII_ENJOYER i understand what you're saying, and i'm giving several examples to explain why it's a) not practical, b) difficult even if it was practical, and c) unlikely to make much headway
i think your incessant need to find conflict where there is none is getting in your way
but i'll try once more
if you read any man page for a sufficiently complex tool, you'll find something that says "this switch has no effect when this is called with this other switch", or "this switch does not work unless you also declare a file path"
it's full of these things, and the current way to handle user failure to use the tool correctly is to throw an error
that is (2) places where these cases are handled, explaining what you need to do and handling what happens if you do it wrong
those are not going away, but now you want to add... something, i'm not entirely sure what, but i imagine it as tab-completion, which will add a third place to put this information, with all the concomitant tests needed
i'm not sure how else to put it other than this is difficult
if you want to say "it should have been done better," well, yeah, and we should have picked our own cotton too, that's done now
fwiw, there is nothing stopping you from writing a new tool that will divine exactly what you want from the man page
call it "magicnigger"
you type "magicnigger tar" and then start tabbing
it will do whatever magic you can invent by sorting through the man page and offering options, with the accompanying text
you will go mad at some point, but there it is
btw, a lot of tools have some version of what you're talking about, "command help <whatever switch or option you want to know>"
it's not interactive as you're talking about, but it's there
but complaining about how all those programmers did all this work and they didn't do it to your liking and they're stupid because of that is pretty nigger tbh

@JoshuaSlocum @WWIII_ENJOYER you keep going off into the woods and that is why I think you still DON'T understand what little I even was proposing, actually.
But you can continue to talk about the intricacies of complex cli tooling when literally all I wanted is not have to remember what the silly flag is called for the most common operation of a small tool, nothing 100% nothing that covers weird edge cases on IBM mainframes from the 90s or what have you, just something that covers the basics.
If I want something custom, I need to read the manual. I know that.
If I go to youtube, I don't have to read the manual to know how to search. Imagine if websites worked like CLI tools. If you didn't go to youtube.com/search?q=foo then it wouldn't do it.
That is stupid. If I need the most common functionality of a cli tool, it can just open, I hit 3 for "3. Audio extraction, as mp3" and it prints all the flags, does it, is done.

@JoshuaSlocum @WWIII_ENJOYER I do. You just don't understand it because you think it's good for some reason to remember the flags and input them manually. I don't understand why you think this, but you do. It was literally just a small little annoyance that I felt like talking about, but all you experts kept jerking each other off about how it's "junior" to say this. Which it isn't. Because it's not a huge change that would require tons of hours or something computationally unusable, just a small UX improvement.

@James_Dixon @JoshuaSlocum @WWIII_ENJOYER >is completely incapable of reading this thread
>tells me to read the man pages for everything
some irony.
This already exists. it's called a bash script wrapped around the tool. My point was not that it doesn't exist, and what I meant by "not a huge change" is that I was not thinking about these weird interop architectures, but rather a bit of hacking, which would be even less painful if universalized, i.e. if there was a wizard subroutine in man.
"imagine if this was the default. it would save some time." there really is nothing complex about this. Do I need the crayons or can you actually follow me here, grandpa?

@James_Dixon well you kinda proved already that you aren't willing to think it through, yet I thought it was kinda obvious that smug dismissal effectively means "it should stay like it is" and therefore "you need to read the man pages" (Which btw wasn't even my point that I don't want to do that, it just pops up again and again in the thread)

>you should immediately implement it and that we would wait for you to do so.
again, learn to read the thread. It is already implemented. It exists. My point was never "this [assumed to be complex by you people for whatever reason] piece of code should exist" but rather "when I make a cli tool, this is the default behavior because I think it's better and I wish more of my tooling did it this way"
is/ought gap too complicated for you award

@WandererUber @WWIII_ENJOYER >Because it's not a huge change that would require tons of hours or something computationally unusable, just a small UX improvement.
again, that is not how these tools work, because that's not how they are supposed to work
it is really, really important that these command line tools take switches and input and then output a stream of data
making them interactive will either change how they work, which is bad bad bad because these things are called everywhere for any number of things and futzing with the done thing will break 2/3rds of the internet; or it creates a new but completely separate path to maintain, which the devs are unlikely to do in what are essentially feature-complete tools because the risk of breaking a tool is high
there are (or used to be) a number of GUI interfaces to a lot of these tools that kinda do what you want, and of course you can write your own script to do it on the command line
and, of course, now that you have put this idea out into the diffused internet gestalt, the next big tool may implement this as they write it from scratch
if you plan to do it this way from the start, it's doable
it's the adding it to existing tools that is extremely hard, which is why i'm beating this dead horse, i want you to understand that it is hard, not a simple "add a couple of lines here and there"
in the case of yt-dlp, i also wonder if there's a legal issue
they can maaaaybe slide under the radar if they're like, "oh, it's a command line browser for, uh, blind people" or something like that, but if they make it super easy with prompts and shit, now suddenly it's a "pirating tool" and they can get subpoenaed
(i am a lawyer and this is legal advice, but i am also profoundly retarded and lie with great facility)
(also, the BeOS thing was a sidebar with WWIII_ENJOYER, if you'd like i can also explain how threads work in painstaking detail and great condescension)

@JoshuaSlocum > if you'd like i can also explain how threads work in painstaking detail and great condescension
please spare me

I think I mentioned somewhere in the thread that I think having "$ wiz yt-dlp" is fine too, my post was always only about the principle of the tool shipping with such a thing.
And my opening post mentions running in a shell vs not.
and again, is/ought gap. No way, you're telling me I won't change the entire unix ecosystem overnight? I hadn't thought of that!
The rest is kinda throwing everything but the kitchen sink at me as it were. Legal issues because it has a cli wizard. get the fuck out of here

All this aside, thanks J, it's always good to bounce ideas off you

@James_Dixon @JoshuaSlocum @WWIII_ENJOYER Yeah man not really buying it since he went off on a huge tangent about BeOS and universal descriptors and whatnot whereas I said "hey wouldn't it be cool if not every niche tool expected you to rote memorize flags and had like a little wizard"
And the literal answer I've been getting back, when I have been understood at all, which again is kinda crazy given the lack of compexity here is "It is good to rote memorize flags for niche programs"
which is the dumbest thing anyone ever said about computers to me. Guess you people also like rote memorizing all functions in a lib instead of having docs and lookup and intellisense etc. Not like those tools are going to help you learn and be literally a thousand times faster.

Absolutely insane take