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?
"The command line" is not pointless. The current popular implementation of a command line, is, however, pointlessly complicated and esoteric for no real gain. It could be improved massively.
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"
To be honest the criteria for a beginner and someone who's used a tool for a while are different.
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.
Standard unix shells. They contain a massive amount of complexity and obfuscation that only exists because that's how it was always done and nobody dares change it any longer.
Like what? Please be specific or we can't have a meaningful discussion.
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.
One aspect of standard command line experience is that the various standard unix tools have different, incompatible "interfaces" (different switches for the same things, requiring multiple different memorizations) - the experience could be "unified" to a common standard and it would be better and simpler, without removing any actual functionality, but they can't be because that would break backwards compatibility and what people remember.
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).
fair, there are commandline tools by third parties that dont conform. From reading your other comments, though, I can tell that you likely don't enjoy learning complicated systems in order to leverage them for your advantage. Just like the author of the article, you complain on and on, without displaying any sort of passion for the good things this complexity brings.
That's a deeply unfair way of characterizing that. I love UNIX shell, but it is unquestionably true that it has a lot of cruft and could be a lot better designed. It's possible to both appreciate and enjoy learning complicated systems while recognizing that complexity is in and of itself a bad thing that should be reduced to the greatest possible extent.
All command line tools are by third parties. There is no first party.
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.
To put that another way: not all command-line applications follow the POSIX/GNU command-line conventions. [0][1][2] I agree that all new command-line applications should do so. It's annoying that Java uses java -version rather than java --version, and I can't see why they couldn't just add support for --version, as they wouldn't have to remove the existing -version.
> 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.
True, but in my experience it's not a great concern in practice. If you have to administer various different Unices then I could see this being a real pain-point, but GNU/Linux has taken over most of the world.
I feel like a lot of these are beyond the scope of the terminal. Like, we don't need a way to cat images — we have `xdg-open`, which will open an image file in the system's default image-viewing application. It'll open any file in its default application. Integrating images into the terminal requires doing away with the text-only abstraction, and in exchange for what? Something `xdg-open` gets for us already?
PowerShell is very close to what I think we need, but even PS is not quite cutting deeply enough. We need to rethink the command line rather than apply band-aids to an idiosyncratic model. Terminology is great, but it cannot solve the fundamental problems at the layers below that.
> Terminals of 2020 and beyond need to have first-class support for audio, video, images, and peripheral interactivity/customization.
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.
"We have X11 for this" just means "we can't do this, use a different environment".
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.
> we should not HAVE to use a different environment
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.
Do you have a specific gripe against X11? Again, it would be very much against the Unix philosophy to roll that highly complex functionality into the core SSH protocol. The problem would still be just as complex and challenging. Implementing a network-transparent GUI always is. You'd lose the separation of concerns, and you'd end up running two GUI systems rather than one.
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]
Agreed. There are so many annoyances like how you can’t use the standard shortcuts to copy and paste or how pasting text can insert a newline and run the command.
If we rebuilt the command line today it would be massively better
What do you mean by "current popular implementation of a command line"? The shell, common tools (e.g ls, cat, grep), command line interfaces for other programs?
yes, that should have been obvious. if you ever used them, you know they do not scale beyond the basics.
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).
The command line is a layer of abstraction that could be made unnecessary for programming. You could program in Turbo Pascal without a command line in the 90s
It's definitely GUIs, which is much easier to use for beginners (we're talking about beginners here, not people who have been using command lines exclusively for the last 20 years)
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.
And so they do, and so there are plenty of programming tools and environments aimed at beginners. But, just like you can't expect to make a proper dinner with your kid's toy-utensils, if you want to build nontrivial software, you need to learn suitable tools for that. And the command line the most basic of serious tools.
(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.)
In one statement you just revealed your age and experience level.
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.
>In one statement you just revealed your age and experience level.
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.
I disagree completely, and I'm starting to see now that you do not see the command line as programming, which is a fundamental flaw in how you're approaching your argument.
The command line _IS_ a programming language. If you do not want to learn it then you do not want to learn programming.
If you do not want to learn it then you do not want to learn programming.
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.
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.
Developing iOS apps isn't the be-all, end-all of programming. iOS itself is a consumption platform. It's garbage if you want to actually do anything (and so is Android), because the input bandwidth is severely limited. You don't need a command line on your phone, because there's hardly much you can do with it anyway.
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.
None of that is relevant. iOS is a fully-fledged OS, with at least as much complexity as anything else you'd be programming for.
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.
iOS has one of the most pathetic development toolings in existence.
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.
> The command line is a layer of abstraction that could be made unnecessary for programming.
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.
Sure, but you're entirely missing the point. Question is, is it necessary for programming? I repeat, to be entirely clear, is it necessary? Not useful, but necessary for a beginner to touch the command line?
> 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?
