Snark aside, it's a valid point. Shouldn't CLI tools mimic GUI tools?
quake3cli --map anarki -e '(walk-forward) (rotate 0.2) (fire)'How do I pipe to it?
I doubt many would do it this way, but it would be consistent with the unix design ethos. One program would manage the Playing the Game and perhaps providing an API for interacting with the game, or even a pluggable section of games, and another would handle generating heuristics (or retrieving them).
Then you could, e.g.:
multibot -g quake3 --name "Rocket Llama" -h rockets.lua multibot -g quake3 --name "Ash" -h shotgun-only.lua cat /dev/urandom | multibot -g quake3 --name "Confused"
multibot -g civ3 --name "Dr. No" -h well-defended-island.lua multibot -g civ3 --name "Dr. Evil" -h meeeeelion.lua
That'd be a nightmare to implement, of course. :-)
What about changing the behavior of grep -r?
(Sorry, I just couldn't resist. When I first clicked the link, I actually thought this was a reference to the GNU grep changes at first).
If you want a CLI equivalent of "ubuntu-dash", then you have to make one. grep is not it.
And as far as I am concerned, anyone who honestly finds themselves wishing cli tools worked like gui tools should knock themselves out. I'm sure plenty of people would find it useful.
There is no elegant way to do this with a CLI interface since it is not a static interface, it is a stream of characters. Anything that's not content will have to be inline with user-generated input and output. It would be like a weather app with ads in the middle of the sun icon.
The analogy is just awesome!! Thanks a ton for bringing a smile on a gloomy day :)
Yes, amazon-enabled dash and grep/find/whatever have different functionality. But that's a recent change. Previously, dash had exactly the same functionality. That's the entire point. You add a feature here, you add the same feature there.
>Or create a new window that temporarily overlays the xterm running the command.
You have got to be kidding me. This is a joke.
>Previously, dash had exactly the same functionality
The exact same functionality of which? And I rather doubt that is true.
>You add a feature here, you add the same feature there.
No. No you do not. Not when there is standardized. And in this case the "here"/"there" relationship has not even been established for "ubuntu-dash"/grep, making this extra idiotic.
Uh, yeah?
Off the top of my head you would need to patch glibc, all the major shells, probably half of coreutils, anything that daemonizes similar to nohup (including screen and tmux, god knows how many CPAN modules), ...
This can be observed by running:
bash -c 'times whoami' > /dev/nullWhere applicable, a command line option can be a great supplement when something that can be achieved via the GUI . For example, encoding a video to a certain codec, having a visual wrapper on this is a nice to have if converting one video or a few videos. However if that same application allows the ability to encode thousands of videos using the CLI option, its an added ability that is appreciated.
These tools are only CLI/GUI equivalents of each other in a very superficial sense.
Dash and grep may have different interfaces, but if their core purpose is "search stuff", it is not wholly unreasonable to expect them to be able to search the same stuff.
[grep is probably the wrong tool. perhaps the output should be included in find instead.]
As I said, they are the same tool only in the most superficial of senses. Is the purpose of this ubuntu thing even to grep input streams or files? Or did the submitter of this 'bug' actually mean to file a bug for slocate, mlocate, or find? Does it do both? These tools have completely different purposes and uses.
How about this for another reason though: http://pubs.opengroup.org/onlinepubs/009695399/utilities/gre... GNU is bad enough, having Ubuntu tack on whatever shit they feel is "user friendly" would turn the situation into a usability nightmare.
PS. Is this thing seriously called dash? If so, that is terrible. The name 'dash' is already taken... in the FOSS world... by Ubuntu's daddy distro Debian. Hell, Googling "ubuntu dash" returns first results for the proper dash. What the hell were they thinking?
And that is rather the point is it not? If you want to add completion to curl, you don't. Because that is a task for another program. If you want to add amazon searching to grep, you don't. Because that is a task for another program.
Whether and how desirable this is is quite the different question. But it's very technically feasible.
I am saying it should not be done, and cannot be done well.
1. Why on earth wouldn't you want url suggestion/completion for cURL? If there's one place that benefits from a lack of typing it's command-line tools (which is why modern shells all have command and file tab completion).
2. Browsers like 'links' and 'w3m' go so far as to implement mouse support so you can emulate a GUI on the console. Why not for cURL? Just because it has a billion obscure command-line arguments doesn't mean it's a great idea to keep it that way. With a console ncurses UI for cURL I could pick all the options I wanted quickly instead of paging through dozens of man page options, then copying them down with the argument I wanted and re-typing them in line.
I don't think shells should suffer from a lack of innovation just because everyone's obsessed with JavaScript.