Please explain how the command-line is pointless. If investing time into learning the ins and outs of a complicated system does not make you clever then please explain to me what does make someone clever?
Dismissing other people’s work as awful, pointless on the Internet. Well, at least it makes you look clever, in certain eyes.
I use Bash a fair amount and I don't consider it overly complicated as a shell. There are some rough edges in Unix, like handling spaces in directories, and I'm no fan of Bash as a scripting language, but I wouldn't say the basic model of the Unix command-line interface is overly complicated.
-o for outfile / output
-f for file / infile
-q for quiet
there are already many of these, and for the others that arent so common between tools. Compilers will, inevitably, need switches that, say, a code editor doesnt need.
You're right that, for example, `watch` has -n for "delay", and `htop` has -d, but then again those accept different types (seconds vs some other sub-second measurement).
And it brings no good things. This is entirely superfluous complexity. You could have all the benefits with far less complexity if you just put in the effort to build and design things.
But we don't. We've decided that it is impossible to do so. And many people have decided that knowing all of these obscurities makes them smart, and they will look down on anyone who doesn't.
> many people have decided that knowing all of these obscurities makes them smart, and they will look down on anyone who doesn't.
I don't think it's sysadmins who are pushing for this messy state of affairs, it's that various specific projects refuse to follow the POSIX conventions, presumably for reasons of backward compatibility/general resistance to change.
[0] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
[1] https://www.gnu.org/software/libc/manual/html_node/Argument-...
[2] https://www.gnu.org/prep/standards/html_node/Command_002dLin...
https://news.ycombinator.com/item?id=25305575
I admit that I'm kind of conflating the concept of a terminal emulator, a shell and a shell language, but the shell model has plenty to improve upon.
This shouldn't be supported in a first-class way, it should be supported as an extension where applicable, in keeping with Unix principles. We already have this with X11.
> It should be possible to `cat` an image, or a video, or even previews of Word and Photoshop documents
Again this can be done with X11 if you want it.
> Programs should be able to raise notifications without relying on third-party/OS-provided utils that have a drastically different API and availability across platforms.
Interesting idea, perhaps this could be done with a metacharacter, akin to the 'bell' character, or perhaps even overloading the bell character. There could be a convention along the lines of BELL BELL your message here BELL BELL.
> Rich read-only visualisations of progress should be possible to call up with a few lines of code. I want to see a `dd`, `mv` or `cp` with a graphical progress bar at the bottom of my window.
wget and curl indicate progress in this way. I'm sure there are programs out there that would give you this.
> We should be able to render a piece of output in 3D, if we so desire. I don't want Crysis, but I do want a Matlab logo that I can rotate by dragging my mouse and graphs that zoom when I Ctrl+scroll at them.
Again we have X11 for this. It's not easily done, which is why we have drama like Wayland which lacks network transparency. [0]
> Support for file pickers and rich selection/filtering of file/directory lists. Not for sandboxing, but for convenience.
A file-picker could be implemented as a TUI, which is roughly what Midnight Commander gives you. Perhaps a Unix shell could support mouse-clicks for selection from its auto-completion listings. I think that would be possible, perhaps it's already been done.
> A command line builder (like one of the classic Apple OSes had, cannot find a reference now, or something like the one in Fish but more advanced). Only valid combinations of parameters will be supported, mutually exclusive commands are impossible to select.
I agree it would be great to have a system like this, akin to type safety. Perhaps applications could distribute something akin to a regex to describe their syntax. I imagine something like this is already implemented for auto-completion purposes (e.g. how Bash can auto-complete git's verbs).
> Terminals should be able to intake gigabytes of input per second, up to the limit of the hardware, without choking up.
I don't know quite what you have in mind here but you can already do this in the way that matters. You can easily run a Unix command to tarball a local directory, then compress it, send it over SSH to a remote server, and have that remote server decompress the stream and then unpack the tarball, all 'on the fly' without ever saving the intermediate streams into persistent files. This all works very well in Unix, giving you a lot of flexibility/power and good performance too. (Doubtless the flow I described would be slightly faster if a dedicated application were used instead, but Unix pipes are pretty fast).
> We should be seeing 60FPS and beyond as a normal feature.
Which command-line applications would benefit from 60fps? Better TUIs would be nice but I don't think the frame-rates are the issue there.
> We should finally get unlimited scrollback enabled by default
You can probably enable that if you want it.
> We have the space for it, either in RAM or persistent storage
Not if you accidentally stream /dev/random.
> If not, it should be adaptable and drop the scrollback buffer that is lower priority than other applications on the system if they need more resources.
This approach would have the downside of being less predictable than the current one.
> Unicode should come as standard. Emoji should come as standard.
Sure. I think Unicode support is pretty good though, I believe it's used in many TUIs.
> End termcap. We should be able to hash out ONE standard to rule them all.
I imagine this is one of those things where there will always be a few legacy systems that still need to be supported.
> end Bash
I agree that Bash has many unfortunate quirks that are annoying at best and are outright dangerous footguns at worst, especially when it's used for scripting. The only advantage of writing a traditional Unix script, as opposed to say a Python script, is portability. configure scripts, for example, run on just about any Unix, with no dependencies.
> consider adding hypertext support. It's here to stay, and not just in the form of HTML
Not a bad idea, perhaps this too could be done with metacharacters.
[0] https://wayland.freedesktop.org/faq.html#heading_toc_j_8
The point is, we should not HAVE to use a different environment. Images and media should be first-class citizens in a CLI just as much as they are in a GUI. There is nothing about a CLI that says it has to only handle text.
Breaking things down into meaningfully separated subsystems is part of why Unix has been successful. What you're suggesting would mean hugely increasing the amount of complexity in SSH. It makes far more sense to use SSH as the transport solution, using a separate system to handle drawing/windows/graphics acceleration/user input into the GUI.
Not all servers support a graphical environment, and neither do all clients. This allows for lightweight servers and lightweight clients.
> There is nothing about a CLI that says it has to only handle text.
The command-line itself should be a relatively simple canvas, not a complex rendering subsystem. It's already rich enough to support TUIs, including mouse-click support. If you want more than that, use a proper GUI.
If you want a very basic GUI over SSH without a full-blown GUI like with X11, you already have the option of using a TUI like Midnight Commander. You can preview images on the command-line, with a tool like imcat. [0]
PowerShell streams Objects instead of characters/bytes. But that is more compatible with cmd than sh.
Many other points are more about the terminal emulator. terminiology has some of those features AFAIK.
If we rebuilt the command line today it would be massively better
Ctrl+C sends SIGINT, while CMD+C copies text, and running commands when a newline is pasted can be disabled.
Shell (just like language) is a medium. We use it to communicate our ideas, not because it is great or flawless.
But let's be honest, the design is pretty esoteric.
You want to find a file containing a particular string? For some reason the tool is called 'grep'. The name is followed by '-r' then the search term, then the directory to start the search in.
And it won't be long before you start encountering tools with such intuitive names as 'sed' and 'awk' and 'crontab'
The tool for finding a file by name is better - that's called 'find' - except compared to grep the arguments are swapped: The directory to search is now the first parameter, not the last.
Oh, to find the *.desktop files on your system you did a find on / ? Yes, the messages like "find: ‘/proc/19917/fd’: Permission denied" are normal, you should ignore them. It's easy, simply add 2>/dev/null to the command.
Before you know it, the command line infects your brain and you start saying things like "sudo and nohup are perfectly good names"
You bet that `ls`/`cd` is a great name for me - it takes 2 characters and I don't have anything similar conflicting on the PATH.
For a beginner? Not so much - `change-directory` and `list-directory` would probably be better. It's the same with regular expressions `^[A-Z0-9]{0, 3}$` is perfectly readable once you're reasonably familiar with the syntax.
It's also true in other fields such as mathematics or music - the notation is quite good once you're proficient in it.
g - global re - regex p - print
https://en.wikipedia.org/wiki/Grep#:~:text=Its%20name%20come....
just try to imagine the language as the OS. if it were good enough, there would be no need to have different languages, and one would not have the horrible level of fragmentation and harmful shared state that characterizes today's dev environment. most people have become blind to this fact.
then there is the problem of selection bias: the majority of developers in this business have tolerated an insane level of abuse. most are proud of their abilities, even if they can be characterized as "they know how to wade through layers upon layers of shit". it is often hard to have a discussion about this, because they take this as personal criticism.
the situation we live can be described as a paradox: the Unix culture is at the same time both a pinnacle of OS design (from days gone by) and a steaming pile of shit with so many bad practices abound it is no use highlighting one (with the command-line just being a visible part).
just pointing out the obvious.
The general trend in programming has been moving TOWARDS command line interfaces, not away from it. Mac OS didn't even have a built in command line until 2001. Microsoft Windows in the last few years has had its command line functionality enhanced, to the point that the GUI only Server versions of Windows have been stripped back, and now there are CLI only versions of Windows Server.
You can do more now in a command line than ever before, you can do more now in a command line than you could in 2001.
"Everything should have a GUI alternative" has been tried and it has failed. Almost all computer efforts through the 1990s were focused on making everything GUI only.
What are you assuming about my experience level?
I thought it was perfectly clear that the argument isn't "there should be no command line" but that knowledge of the command like should't be necessary for beginners. Just like e.g. knowing assebler shouldn't be (and isn't) neccessary for programming. That's why I put the parenthesized statement above, specifically so you understand what the argument is. Or you could just read what I responded to.
The command line _IS_ a programming language. If you do not want to learn it then you do not want to learn programming.
You can create and distribute a world-class iOS app without having to touch a command line even once. It is just not necessary. Nothing gets easier if you do.
Because iOS has actual well-designed modern tooling.
But sit in front of a device with a keyboard - one that's meant for creative use - and suddenly, the command line shines as a force multiplier.
Yet, to program for it, you don't need to use the command line. You just never need to touch it. It is possible to make a fully productive programming environment where the command line is not necessary, if you just put the effort in to do it like Apple has.
Your statement truly shows how unaware you are of actually good toolings and solutions for software development, and, frankly, you should not say a single word more about software development experience, if only not to embarrass yourself even further.
At least pro-console users had some sort of argument for their setups.
You cannot comprehend a simple idea that there are much better ways to develop software, than crippling, mind-bogglingly bad Xcode and friends.
I still find Xcode very productive, pleasant to use, and far better than almost any alternative I have seen.
It has some annoying bugs, some annoying limitations, but none that would make it any worse than the absolute shitshows you get elsewhere.
I do know what I am talking about, here. I have done a lot of this.
That is simply not true. I have plenty of colleagues that do everything in Visual Studio and never touch the command line and they produce solution to hard problems that are absolutely useful and well written.
Would you want your kitchen to be limited to plastic spoons and silicone bowls, because that's easy for a 2 year old to grasp? Pots and stoves and knives, after all, are too complicated, and God forbid the knife is metal and the stove is powered.
You can't do useful things and cater for beginners at the same time, because that implies nothing can ever improve beyond what a beginner can grasp. The job of a beginner is to become proficient. They can achieve that through learning, not through expecting rewards just for showing up.
(Hell, situation in programming is actually quite good for beginners. You can go very far with toys. For instance, people make and sell complex video games in clicker tools. The experience of pushing such tools to the limit tends to shine a light on why programming is complex in general: you're pushing at irreducible complexity. Serious tools like command line exist to help you manage that complexity better.)
Wow, if I ever saw a comment on HN that was fundamentally wrong on many levels, this was it.
No, a command line interface is not "a layer of abstraction". A command line interface is an interface. That's it. Instead of pressing a button, you run a command. If you want to pass settings to an app when you launch it, you use the command line interface. If you want to script away a task, you call the command from your script.
That's it. It's not a layer of abstraction. It's an interface. They exist for many good reasons.
Why, yes?
> Not useful, but necessary for a beginner to touch the command line?
Do you understand that you're asking if a beginner needs to run or pass a setting or even automate any operation that's relevant to programming?
I repeat, a CLI is an interface. It's an interface to perform an action and/or pass a setting. That's it. What warrants this irrational opposition to an interface?
You must not visit political threads much.
But seriously, you could have said that in a constructive way.