Are command line interfaces for an OS obsolete?

All off topic discussions go here. Everything from the funny thing your cat did to your favorite tv shows. Non-programming computer questions are ok too.
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re: Are command line interfaces for an OS obsolete?

Post by Solar »

iansjack wrote:There is something of a difference between the subject heading of the OP (Are CLIs obsolete?) and the body of the post (could you manage with a non-GUI OS?) The answer to both questions, for the vast majority of people is "No".
That sums it up perfectly IMHO.

There was an undertone of "one or the other" to the discussion, which got us sidetracked. A good OS, IMHO (and I think I did make this point above), would integrate CLI and GUI. In a perfect world, there wouldn't be GIMP on the one hand and imagemagick on the other -- the two would be merely two different ways to use one and the same application. Same for elinks and firefox, mutt and thunderbird, and so on.

Obviously there are applications that just don't make sense in "the other" interface. 3D games are of course GUI only, shells are of course CLI only. But you get the idea.
Every good solution is obvious once you've found it.
LtG
Member
Member
Posts: 384
Joined: Thu Aug 13, 2015 4:57 pm

Re: Are command line interfaces for an OS obsolete?

Post by LtG »

Solar wrote: As for "obsolete"... I consider it a significant win that I can use text-only connections to remote machines this way. I can remote-access systems in my home network from my smartphone.
What about RDP or Teamviewer? Nothing CLI specific here.
Solar wrote: All I need is some "obsolete" tools -- a terminal app running a bash shell and a ssh client. And by accessing "obsolete" tools on the remote machine (like Vim, CMake and GCC), I can continue development / administrative work I left unfinished at home, while on travels.
Do you actually write code using a phone? I dislike writing with a phone, so no coding there for me.. although maybe due to that problem I would write less code, but better code?
Solar wrote: I know that a slick-looking GUI has much more appeal, visually.
I'm not sure how much this has to do with looks, but rather utility. TUI just doesn't make efficient use of the screen, with GUI you can have easily a lot more info visible at any given time.

Take grep for example, I've never met anyone who could write one of the more complex incantations in a short amount of time. If I have the data available on my Windows machine, I might just dump it in Excel and filter until I have the data set I want.
Solar wrote: I think both GUI and CLI have their place in computing, today and tomorrow. GUIs are something the casual user expects, especially with the prevalence of hand-held touchscreen devices. Command line and scripting is, and will remain to be, the tool of choice for the power user.
Nonsense, the only time I use CLI is when the OS designers failed to do their job. Interestingly, on Windows I can't remember when is the last time I touched cmd.exe, months ago. Almost always that's to change some settings that the devs didn't make available in the GUI, and even then it's rare.

On Linux I have to do it all the time, but of course on Linux there's no GUI, there's a dozen GUIs and thus the "OS" part can't reliably delegate stuff to the GUI, so it has to be CLI based.
Solar wrote: Making both talk to each other right from the beginning would make any OS stronger, and avoid the harsh disconnect felt when tossed from one "world" to the other.
I think it easily applies the other way around as well, a schizophrenic OS that can't decide which should be used. It usually ends up a mess, where only the GUI can be used for some rare things and the CLI for other rare things.

If Windows didn't have a CLI I'm guessing they would have found a way to make all those settings available on the GUI.
Solar wrote: Text interfaces depend on much less OS infrastructure.
Sure, less OS infra, but equal amount of infra nonetheless, mostly firmware.

And assuming you want nicer fonts, then you're doing graphics anyway (Linear Frame Buffer (LFB), etc).
Solar wrote: Text works in "recovery mode" when gfx drivers malfunctioned or the whole GUI infrastructure doesn't "click". Text interfaces are more flexible when doing remote access, can give log output not usually available from GUIs, and generally are more useful in "emergency" situations. This, of course, is coming from an old-school desktop poweruser who is "in the shell" 90% of the time anyway...
Maybe, but I'm skeptical. Are there really instances where the LFB would fail with generic drivers, but text would work?

And outputting the very earliest error messages (before LFB) and then halting as text, when something goes horribly wrong at first stages, doesn't count as CLI/TUI.


So, it goes without saying, I'm not planning on supporting a CLI, instead I'd rather improve the GUI so there's no need for one.. time will tell =)
User avatar
iansjack
Member
Member
Posts: 4703
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: Are command line interfaces for an OS obsolete?

Post by iansjack »

LtG wrote: What about RDP or Teamviewer? Nothing CLI specific here.
Both are far more intensive of resources, particularly network bandwidth, than a simple SSH session. For remote access to a server, nothing beats a CLI session over SSH. And to secure RDP adequately you are going to have to tunnel it through SSH anyway, so you are just adding another unnecessary layer.
Korona
Member
Member
Posts: 1000
Joined: Thu May 17, 2007 1:27 pm
Contact:

Re: Are command line interfaces for an OS obsolete?

Post by Korona »

OP neglects the fact that while CLIs are not important for 90-95% of end users, they are highly important to developers who build the global computing infrastructure and keep it running. Many of those jobs require heavy use of CLIs, e.g., because the machines in question just don't have GUIs (embedded world, cloud computing, HPC). CLIs won't be gone anytime soon. Disregarding browsers, I could certainly work only using the CLI, but I cannot imagine any DevOps job not using a CLI.
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re: Are command line interfaces for an OS obsolete?

Post by Solar »

LtG wrote:Do you actually write code using a phone?
On a regular basis.[1][2]

I use my desktop at home, an Acer One netbook for longer stretches of travel, and my smartphone for those "I have a couple of minutes..." moments when whipping out and booting up the netbook wouldn't be quite "right". (Doctor's waiting room, on the tram, at a friend's place when I "just want to show something" or sudden inspiration strikes and I don't want the idea go to waste.)
LtG wrote:TUI just doesn't make efficient use of the screen, with GUI you can have easily a lot more info visible at any given time.
Ah... depends, really. I agree that a graph can sometimes say more than a table of numbers, but a GUI can also take up lots of screen real estate with rather useless widgets distracting from what you're really looking for. There are use cases for both, is all that I'm sayin'.
LtG wrote:Take grep for example, I've never met anyone who could write one of the more complex incantations in a short amount of time...
Well that could be it, then -- your experience, or lack of experience, with people who actually "grok" the other side of the argument. Personally, I'll whip up quite complex RegEx's without hestiation, simply because I am using them in my prefered environment (Vim) all the time. Having to go through Excel (of all things...) would aggravate me to no end. Kind of a "speed bump".
LtG wrote:Interestingly, on Windows I can't remember when is the last time I touched cmd.exe, months ago.
cmd.exe is so braindead that it's effectively useless anyway.

But I've been at this point often enough to recognize the pattern: You've never really enjoyed the things a "strong" CLI can give you, or seen someone enjoy it, so you aren't even aware of the workflow that I'm talking about. That's a pity, but can't really be helped without having you look over my shoulder for an hour or so.

I've comfortably switched back and forth between GUI and CLI back on the Amiga Workbench, which arguably did have a very powerful and comprehensive GUI -- but, and that's my point, also a powerful and comprehensive CLI. I admit that current systems are biased -- Windows pro-GUI, Linux pro-CLI with not that much good CLI/GUI integration going on. That makes it difficult.

(Kind of like trying to explain alternative drive access mechanisms. People know drive letters -- which suck -- and single root systems -- which also suck. And think the argument is about making a system more like Windows, or more like Linux, when in actual fact it's about making it better than either of them.)
LtG wrote:
Solar wrote: Making both talk to each other right from the beginning would make any OS stronger, and avoid the harsh disconnect felt when tossed from one "world" to the other.
I think it easily applies the other way around as well, a schizophrenic OS that can't decide which should be used. It usually ends up a mess, where only the GUI can be used for some rare things and the CLI for other rare things.
No, what I mean is something that you haven't yet experienced, which makes it so damn difficult to explain. We'll probably just have to agree that we disagree.
LfG wrote:And outputting the very earliest error messages (before LFB) and then halting as text, when something goes horribly wrong at first stages, doesn't count as CLI/TUI.
But the CLI / TUI is all what you have at that point to recover the system. If you've never seen text mode until that point (as in Windows Recovery Console, for example), and your system is geared so certain things basically require a GUI to operate on, you're stumped.
LfG wrote:So, it goes without saying, I'm not planning on supporting a CLI, instead I'd rather improve the GUI so there's no need for one.. time will tell =)
That is, of course, your decision. I won't use that OS then, because having a CLI available is one of my most elemental use cases. No kidding, Termux was the very first app I installed when I got my first smartphone, indeed it was the reason I got a smartphone, and I was elated to finally have a truly portable terminal. Tastes differ. 8)
Every good solution is obvious once you've found it.
LtG
Member
Member
Posts: 384
Joined: Thu Aug 13, 2015 4:57 pm

Re: Are command line interfaces for an OS obsolete?

Post by LtG »

Solar wrote:
LtG wrote:TUI just doesn't make efficient use of the screen, with GUI you can have easily a lot more info visible at any given time.
Ah... depends, really. I agree that a graph can sometimes say more than a table of numbers, but a GUI can also take up lots of screen real estate with rather useless widgets distracting from what you're really looking for. There are use cases for both, is all that I'm sayin'.
But you can also have a table of numbers in a GUI, I can't really think of anything you can do in TUI, but can't in GUI.

Of course if we cheat, then it's the same the other way round, I mean even DOS had EDIT, with some mouse support, and there were graphics programs, etc. But those are GUIs, even if started from a TUI.
Solar wrote:
LtG wrote:Take grep for example, I've never met anyone who could write one of the more complex incantations in a short amount of time...
Well that could be it, then -- your experience, or lack of experience, with people who actually "grok" the other side of the argument. Personally, I'll whip up quite complex RegEx's without hestiation, simply because I am using them in my prefered environment (Vim) all the time. Having to go through Excel (of all things...) would aggravate me to no end. Kind of a "speed bump".
I'm not a huge fan of Excel, I simply use it if it's faster and it's a one-off. If it's something I need to do often, then I put the time to create a working grep.

What would you consider a "quite complex RegEx", that you can write within seconds, a minute at most? I'm not saying regex's can't be written, I'm saying using Excel to filter is often faster (assuming proper hardware, which is cheaper than labor costs).
Solar wrote:
LtG wrote:Interestingly, on Windows I can't remember when is the last time I touched cmd.exe, months ago.
cmd.exe is so braindead that it's effectively useless anyway.

But I've been at this point often enough to recognize the pattern: You've never really enjoyed the things a "strong" CLI can give you, or seen someone enjoy it, so you aren't even aware of the workflow that I'm talking about. That's a pity, but can't really be helped without having you look over my shoulder for an hour or so.
I use Linux/BSDs daily, though I'm not sure what a "strong CLI" is. I may know the workflow you think about, and I don't think it's very good one. Essentially it's a ton of busy work to get something relatively simple done. With Linux (and TUIs) you usually have to do quite a bit to get something done.
Solar wrote:
LtG wrote:
Solar wrote: Making both talk to each other right from the beginning would make any OS stronger, and avoid the harsh disconnect felt when tossed from one "world" to the other.
I think it easily applies the other way around as well, a schizophrenic OS that can't decide which should be used. It usually ends up a mess, where only the GUI can be used for some rare things and the CLI for other rare things.
No, what I mean is something that you haven't yet experienced, which makes it so damn difficult to explain. We'll probably just have to agree that we disagree.
Can you try? I'm curious..

Solar wrote:
LfG wrote:And outputting the very earliest error messages (before LFB) and then halting as text, when something goes horribly wrong at first stages, doesn't count as CLI/TUI.
But the CLI / TUI is all what you have at that point to recover the system. If you've never seen text mode until that point (as in Windows Recovery Console, for example), and your system is geared so certain things basically require a GUI to operate on, you're stumped.
Why is the CLI/TUI all you have? Where did the GUI disappear? Just because MS did the wrong thing with Windows (Recovery Console), doesn't mean it's the right thing to do. There's no reason why GUI couldn't be made available.

What I said was, that at the point where LFB wouldn't be available the system is so horribly broken that you can't make any kind of "console" available, and that if you can make any kind of "console" available you can just as easily make it GUI.

Unless of course your graphics card/adapter is broken is such a way that text magically works, but graphics doesn't, even though the text gets translated to pixels/graphics anyway... So either both work, or neither work, or it's some extremely unlikely situation with hardware issues where a console won't help you anyway.
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re: Are command line interfaces for an OS obsolete?

Post by Solar »

Instead of following the Q&A, let me show usecases from my own Linux "toolbox":
  • A script that, given a fresh "default" Linux installation, adds a "standard" collection of applications, installs the drivers for our printer, adds automatic mounting of various network shares when a user logs in, and configures LDAP authentication. This allows me to set up a new machine / reset an existing one with minimal interaction.
  • A script that, given a directory with videos, generates thumbnails for each of the videos, generates a HTML page with a tabular display of those thumbnails (plus the filename sans extension as means of a title) sorted by date, and syncs the result with the intranet webserver.
By the very nature of the tasks -- which cross application boundaries -- doing these by GUI would require a very specialized custom application (which might not be available), or clicking through several applications (defeating the goal of having these jobs being automatic).

What I meant by "integrating CLI and GUI" is something that AmigaOS did quite beautifully: Since virtually all applications had a "scripting interface" (ARexx ports), it was possible to write scripts that used GUI apps (in a kind of "remote control"). So, yes, by all means have your GUI interfaces for configuring the operating system (mounting network shares on login, having user authentication handled by LDAP, installing a printer). But make these steps available for programs / scripts as well. I don't necessarily mean "make the configurations into files I could edit" (although that is preferrable over a mess like Windows Registry). But make the GUI preferencers scriptable, so I can do whatever I would do manually via a script / program as well.
LtG wrote:Why is the CLI/TUI all you have? Where did the GUI disappear?
It didn't "disappear", it failed to appear yet.

A Unix that fails to boot into X is CLI only. A Windows that fails to boot into the desktop is CLI only. Heck, even an AmigaOS, which had the gfx chip drivers in the ROM but failed to boot through Startup-Sequence is CLI only, even though that CLI is diplayed in a resizable GUI terminal...

(You could, with AmigaOS, also intentionally disable the loading of the Workbench GUI, to save on RAM usage. That's another point -- GUIs use up RAM. That doesn't matter much on a multi-GB desktop or modern smartphone, but there's plenty of cases where you'd rather not use what little RAM you have for a GUI, but for something else.)

You can, of course, eschew the CLI entirely (as you intend), and accept that there is no mode of operation possible prior to the full GUI environment being available. But that means that your chances of unrecoverable failure went up. Perhaps just a bit, but they went up, simply because GUI requires more infrastructure. A display, for one thing, or a way to remote-desktop. Two of the more important computers in my house don't have that, don't need that, and would use up resources better used elsewhere if they had such... (the development server and the file server).

----

A completely different perspective: A programmer's view.

Another way to look at it is from a programmer's view.

Code: Select all

#include <iostream>
#include <string>

int main( int argc, char * argv [] )
{
    std::string name = "Unknown";
    std::cout << "Please enter your name:\n";
    std::cin >> name;
    std::cout << "Hello, " << name;
}
In a system without CLI. What is in argc, argv? What is cin / cout referring to?
Every good solution is obvious once you've found it.
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re: Are command line interfaces for an OS obsolete?

Post by Solar »

Point in case regarding GUI / CLI integration:

Directory Opus File Manager -- Scripting Interface.
The Directory Opus scripting interface lets you write scripts using any installed ActiveX-scripting language. [...]

With the scripting interface you can, for example:
  • Query the state of Listers, tabs, paths and toolbars
  • Obtain lists of files and folders and discover information about them (basic information like name, size, date modified, etc, as well as metadata like EXIF information, MP3 tags, etc)
  • Write buttons and hotkeys functions purely from script code without resorting to "Rename" hacks
  • Test the state of certain system settings (similar to @ifset in a traditional function)
  • Build collections of files and run commands (Opus internal commands and external programs) on them
  • Display dialogs and popup menus
  • Access the clipboard, environment variables and folder aliases
  • Extend the list of Opus internal commands
  • Add additional file and folder information columns that can be displayed in file displays and infotips
  • Automatically trigger scripts based on certain events
  • Save and load configuration (Opus provides an editor that the user can use to edit your script config)
This is the point where Directory Opus shows its Amiga heritage. GUI and CLI are not polar opposites, they are partners.
Every good solution is obvious once you've found it.
User avatar
Schol-R-LEA
Member
Member
Posts: 1925
Joined: Fri Oct 27, 2006 9:42 am
Location: Athens, GA, USA

Re: Are command line interfaces for an OS obsolete?

Post by Schol-R-LEA »

Solar wrote:In a system without CLI. What is in argc, argv? What is cin / cout referring to?
TL;DR:

Code: Select all

argc == 0
argv == cin == cout == cerr = NULL
... and the program fails (possibly with a protection fault) at line 7. Assuming that the C++ compiler allows it at all when generating code for such a system (and perhaps just as relevant given several of the systems in question, that there is a C++ compiler available in the first place).

This does call for a more detailed discussion, I think.

As a rule, such a program won't run as intended (if at all) on a GUI-only system, any more than it would on an embedded one with no UI at all. They can't be used, since they don't exist. This was the case for Mac System prior to OS X, and IIRC, was also the case for Pilot OS and Genera. Historically, most text-based command shells didn't have them, either. The fact that you feel you can ask this question is mostly indicative of the influence of Unix and C on later operating systems.

To give the most immediate example of a graphical-only operating system user interface, the Mac System x.y OS had no CLI, and thus didn't support either CLI arguments nor any sort of standard input streams (or indeed, any sort of standard buffered stream input, period, at least not at first). Native Mac System x.y applications never used program arguments or 'standard' streams, both of which were explicitly rejected for use in Apple User Interface Guidelines compliant programs (as in, any program which did use them would have no upward-compatibility support, and would not be given Apple validation).

However, some Unix-like IDEs, such as MPW, faked it by having a menu item which popped up a textbox, which you could enter the command into. They usually would also have a window which the C/C++ style standard input and output streams would be directed to. They sometimes even had a mini-shell window. However, these were only to be used for testing and/or in code ported from Unix (or later, MS-DOS).

This approach is pretty much unchanged in most current graphical IDEs such as Visual Studio, Eclipse, Code::Blocks, or XCode, for those who haven't tried to use any of those.

That aside, though, the majority of Mac development tools simply didn't have a concept of such things, and didn't need them. It has to be remembered that Unix and C had no real impact on the design of the original Mac 128K, or most other systems of its era for that matter. The assumption on the early Macintosh was that most programming would be in assembly, and anything which wasn't would be written in Pascal (this was also true of early versions of Windows, which is why prior to Win95, Windows system calls all used the Pascal calling conventions). Later, the main development tool would be Hypercard, which was a truly GUI-based environment.

(As an aside, the original Mac Toolkit, which defined the widgets and other components of the GUI, was written in incredibly tight M68K assembly, mostly by one person, and squeezed into a 64KB ROM. Even for the time, this was quite an accomplishment.)

They were not alone in this - even among the various systems where a shell or TUI were the default interface, input streams were generally not supported (buffering generally was, at least on multiuser systems, but solely for the purpose of improving throughput - it generally wasn't exposed to the client-programmer in any meaningful way). The idea of always having a stdin, stdout, and stderr were assumptions of C mainly because they were part of the Thompson shell and its successors; most operating systems before the mid-1980s didn't have anything of the sort, including MS-DOS 1.x. The popularity of C was the main reason for the adoption of them later by the few CLIs developed after that time.

Note that the support for them is a shell feature, not a Unix feature per se. Unix did introduce buffered streams and piped IPC as kernel features to support them, some time around 1970 I think, but it was initially just a feature of the CLI. There is no real requirement for a Unix shell to support them, though one which didn't would be considered very poor indeed.

Similarly, while many operating systems had some form of program parameters (maybe most, but certainly not all), they generally worked very differently from the way C assumed it would. I don't know how it was done in, say, Tenex, ITS, or VMS, but I would hazard a guess that none of them resembled either the Unix shell's approach, or each other's. I don't know much about how they were used in CP/M or MS-DOS prior to 2.0, either.

I know that none of the IBM operating systems prior to AIX had anything of the sort - certainly the batch-processing ones didn't, while the less said about their timesharing systems prior to VM/CMS, the better. As far as I know, CMS still doesn't have those.

In many cases - as I know you are aware, being familiar with the Commodore 64 and other 8-bit micros - the default interface was just a prompt for the programming language interpreter, whether that be a BASIC dialect (as with the above-mentioned micros, the original Dartmouth Timesharing System, and various business oriented OSes such as Pick), Forth, APL, Smalltalk (in the case of Pilot OS), or some flavor of the Lisp family (in the case of the various LispMs).

For that matter, the Tripos kernel which AmigaDOS would be based on assumed that the systems language would be BCPL, and I am pretty sure its UI used an interpreted subset of BCPL prior to it being ported to the Lorraine hardware in 1985.

So the question really isn't as obvious of one as you seem to expect, or at least wouldn't have been prior to the late 1980s. How would a current-day OS developer handle this case? Well.... they could handle it however they choose, really, but they would probably want to consider the principle of least surprise when formulating their solution.
Last edited by Schol-R-LEA on Fri Aug 09, 2019 4:17 pm, edited 4 times in total.
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
simeonz
Member
Member
Posts: 360
Joined: Fri Aug 19, 2016 10:28 pm

Re: Are command line interfaces for an OS obsolete?

Post by simeonz »

I think that GUI and CLI is conflated terminology. Wouldn't command line be better contrasted with menu-driven or dialog driven. Whereas graphical terminal is better contrasted with text terminal. You can use CLI to display graphics, like matlab or octave or something like jupyter (although it is not exactly typical cli). I see no reason why a processes launched through cli interface cannot dump graphical output directly in the console window, similar to a sliding html document with embedded media elements.

To me, cli optimizes pre-planned work on typical data, for someone familiar with the tools available. Menu, dialog, and model-view-controller interfaces facilitate exploratory interactions - with respect to the tools, the data, or the results of its processing. They are better suited for more creative scenarios or casual use. At the same time, text terminals minimize the information on the screen per unit area, for faster transmission and reduced strain on the user when dealing with the content. Graphical terminals maximize the information on screen, which is better for application that require rich presentation. All of these can be combined in all sorts of ways, but indeed menu, dialog, or MVC applications are better suited for rich display, whereas CLI usually emphasizes simplicity.
LtG
Member
Member
Posts: 384
Joined: Thu Aug 13, 2015 4:57 pm

Re: Are command line interfaces for an OS obsolete?

Post by LtG »

I'm certainly not against automation, just against CLI's.

If you consider every GUI application to be split in two, the GUI part and the business logic, and the GUI sends commands to the business logic, then you can just as (probably more) easily automate any task by sending messages to the business logic/backend.

As such, all GUI preferences, in fact pretty much everything is scriptable.

I'm not planning on hardcoding the GUI into the OS, so technically nothing prevents a CLI to be implemented as well, I just don't see a need for one.

Servers might not have any keyboard/display, so the GUI wouldn't be running (no wasted RAM), and yes, there'd be no way to directly interact with the system, apart from the power button. If the "remote control protocol" is so borked that it doesn't work, then the CLI wouldn't work either. Apart from a single NIC system, but even then you should be able to swap the NIC.

I don't see how the unrecoverable failure goes up, either the graphics adapter and display work, or they don't. I suppose it's technically possible to have a broken graphics adapter that works in text mode but refuses to go into graphics mode. But doesn't UEFI already switch it to graphics mode?

As for the (C-)programmers view, I'm not planning on supporting the C-style main, but if I need to, then I'll just put something there, like:
1, programName

I haven't really thought about it, but it occurs to me, that the streams/c-main/etc shouldn't really be an OS level thing anyway. Anybody could create a program that creates a graphical window and renders it black with white text, plumbing cout/cin to it's keyboard input, etc.

I'd also like to point out, that by removing all that legacy cruft the OS becomes simpler and should therefore have less bugs.

Schol-R-LEA covered some nice history there as well =)
LtG
Member
Member
Posts: 384
Joined: Thu Aug 13, 2015 4:57 pm

Re: Are command line interfaces for an OS obsolete?

Post by LtG »

simeonz wrote:I think that GUI and CLI is conflated terminology.
I just use it to describe the difference between the two mainstream ways of handling user interaction.
User avatar
xenos
Member
Member
Posts: 1121
Joined: Thu Aug 11, 2005 11:00 pm
Libera.chat IRC: xenos1984
Location: Tartu, Estonia
Contact:

Re: Are command line interfaces for an OS obsolete?

Post by xenos »

LtG wrote:I suppose it's technically possible to have a broken graphics adapter that works in text mode but refuses to go into graphics mode.
I once had a broken laptop graphics adapter that did exactly that. Text mode worked fine (with some fancy weird colors though), but graphics mode was completely borked and unusable. I used that machine as a small CLI-only Linux server for years without any trouble.

There's many programs I use which come in GUI and CLI versions and where I prefer to use the CLI version. Typical reasons include:
  • The GUI uses significantly more resources (in particular more memory), requires graphics libraries etc., while on some computers I am low on resources. Some don't even have an X server or equivalent installed.
  • I work via SSH over a slow internet connection (wifi while traveling).
  • The CLI is more user friendly for my use case, with command history and auto completion.
  • I want the program output in a terminal, possibly pipe it into something else, grep / sed, save to file, in any case somewhere where I have full control over it and not in some GUI window.
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS
LtG
Member
Member
Posts: 384
Joined: Thu Aug 13, 2015 4:57 pm

Re: Are command line interfaces for an OS obsolete?

Post by LtG »

XenOS wrote: I once had a broken laptop graphics adapter that did exactly that. Text mode worked fine (with some fancy weird colors though), but graphics mode was completely borked and unusable. I used that machine as a small CLI-only Linux server for years without any trouble.
Does anyone know how the modes are implemented in the graphics adapters? Most straightforward would be to always be in graphics mode and implement the text mode as simple wrapper on top.

Did you use hardware specific drivers or generic? Just curious how that can happen. In any case, using it as a headless server would still work for my OS just fine.
XenOS wrote: There's many programs I use which come in GUI and CLI versions and where I prefer to use the CLI version. Typical reasons include:
  • The GUI uses significantly more resources (in particular more memory), requires graphics libraries etc., while on some computers I am low on resources. Some don't even have an X server or equivalent installed.
  • I work via SSH over a slow internet connection (wifi while traveling).
  • The CLI is more user friendly for my use case, with command history and auto completion.
  • I want the program output in a terminal, possibly pipe it into something else, grep / sed, save to file, in any case somewhere where I have full control over it and not in some GUI window.
I think all the reasons you listed are just treating the symptoms, instead of addressing any of the underlying issues.

Consider GUI + single full screen CLI window, the memory requirements are the same as for a single full screen CLI only system, you still need to buffer the 32bpp x resolution pixels.

RDP is pretty decent even over bad connections, and I'm not sure if there's been any significant improvements in the protocol for over a decade. I don't have any concrete plans on how to deal with RDP yet, I've been toying with the idea of trying to intelligently split the work between remote and local, so the windowing happens fully locally, instead of transmitting bitmaps. I think MS-RDP does something similar, but I would probably try to do it more thoroughly, but honestly can't say how much it can be improved. Long ways away for me.

The only case where you can really use grep is with text files, those files should be structured binary files with an API that you can query. As a consequence GUI becomes significantly better.
User avatar
xenos
Member
Member
Posts: 1121
Joined: Thu Aug 11, 2005 11:00 pm
Libera.chat IRC: xenos1984
Location: Tartu, Estonia
Contact:

Re: Are command line interfaces for an OS obsolete?

Post by xenos »

LtG wrote:Did you use hardware specific drivers or generic? Just curious how that can happen.
I tried both plain VGA and NVIDIA drivers.
LtG wrote:Consider GUI + single full screen CLI window, the memory requirements are the same as for a single full screen CLI only system, you still need to buffer the 32bpp x resolution pixels.
I'm not talking about pixels, but graphics libraries used by the GUI for rendering menus, widgets etc. such as Qt or GTK. Some also used Motif. And stuff like Cairo for font rendering. Compare this to a lightweight plain X terminal with fixed-width font. Also I use tmux for terminal multiplexing, so I can have several CLI applications running in one terminal.
LtG wrote:The only case where you can really use grep is with text files, those files should be structured binary files with an API that you can query. As a consequence GUI becomes significantly better.
I have many use cases for grep: searching stuff in some project's source code (as in C, C++); piping curl / wget output into grep for finding some specific information in a web resource; piping some command output to filter for something specific etc. And then half of the time I pipe the output into something else for further processing. Using one tool - grep - with a common syntax for all these different jobs is really convenient. It would be horrible if I had to use a GUI and some binary format with a specific API for this.

Simple example: I found someone put a list of songs on Youtube on a web page and I want to listen to them in random order. Sure, I could copy the links in the browser into some playlist on Youtube. Or I can just run curl on that page, pipe the output into grep to filter out the video links, pipe the output into xargs and run VLC player with that, telling it on the the command line arguments that I want infinite looping, random order and no video to keep it from switching the screensaver off. I can even save the command line into a shell script and next time I find such a nice list, just run that script on the URL.
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS
Post Reply