3 ms·

I think he was saying that a mouse-based GUI can display a terminal window in which one can run a CLI; thus a GUI is a strict superset of a CLI. That's true en

by zeveb 11y ago

I think he was saying that a mouse-based GUI can display a terminal window in which one can run a CLI; thus a GUI is a strict superset of a CLI. That's true enough, although honestly I'm at a point in my computing where the G part of the GUI is pretty limited: my windows are all full-screen; the only clicking I regularly do is on links and tabs, and sometimes text (honestly, I'm trying to use the keyboard more for that though); almost all of my command execution is keyboard-driven (there's a reason man developed language rather than pointing and grunting).

laumars 11y ago
> I think he was saying that a mouse-based GUI can display a terminal window in which one can run a CLI; thus a GUI is a strict superset of a CLI. That's not strictly fair because running ncurses applications inside split tmux panes would give you a GUI-like UI inside a command line environment. Also some of the more esoteric WM's would provide that kind of functionality as well. The main reason it's more common to run CLI inside a GUI is really just a matter of convenience.
- coldtea 11y ago
  You also get access to the whole world of GUI applications. Watching video and editing pictures is not much fun with only ncurses... (ascii video hardly took the world by storm).
  - laumars 11y ago
    There's no reason you can't have a CLI interface with graphics support. Granted the vt100-style terminals can't easily do it, but it was possible with the old REPL machines of the 80s (eg most micro computers which booted into a BASIC interpreter). There are some also some terminal emulators in Linux that support inlined graphics, however I'm not sure how easy it would be to run them as a WM.
    - pjmlp 11y ago
      Hence why we GUI guys rather use a REPL than a plain UNIX CLI. Graphics, the expressiveness of a sane programming language and interaction with the complete OS stack.
      - laumars 11y ago
        Firstly, Bash et al is a REPL in it's own right. What you're discussing there is that UNIX shells make a rubbish programming environment, which is a completely different argument to anything that was being discussed here. For example, DOS can inline graphics as well (proper DOS, not Windows' cmd.exe). So to follow the linked tangent you've made: DOSbox is also a better REPL than UNIX shells. Obviously neither of us would agree with that - even with our criticism of Bash et al. So equally your implied correlation is false. Secondly, your point about "interaction with the complete OS stack", suggesting that CLI interfaces don't have access to the complete OS stack, is completely wrong. If that were the case then Linux and UNIX servers wouldn't typically run headless. A GUI is a shell. The CLI is a shell. Some platforms place more love to graphical shells than command line shells (eg Windows). Other platforms empower command line shells (eg UNIX). To argue that one is better than another is about as futile as saying the colour purple is better than the colour orange. In short, it's personal preference; not irrefutable fact.
        pjmlp 11y ago
        UNIX shells aren't a REPL because 99% of their features are implemented in external commands. The shell is reduced to orchestrate logic between those commands. None of the common ones, ash, sh, bash.... provide a rich programming environment that doesn't rely on external commands. Interaction with the whole OS goes back to Lisp Machines, Interlisp-D, Mesa/Cedar, Smalltalk, Oberon REPL experiences. Nothing to do with running headless, which means you didn't got the message. In those environments I can via the REPL directly interact with running applications from the REPL. For example, search for a specific text in all open windows and act upon it if found. The whole OS API is exposed in the REPL via library calls. No UNIX shell provides this expressiveness without relying on external commands and applications implementing specific APIs like dbus.

by zeveb 11y ago

laumars 11y ago

> I think he was saying that a mouse-based GUI can display a terminal window in which one can run a CLI; thus a GUI is a strict superset of a CLI. That's not strictly fair because running ncurses applications inside split tmux panes would give you a GUI-like UI inside a command line environment. Also some of the more esoteric WM's would provide that kind of functionality as well. The main reason it's more common to run CLI inside a GUI is really just a matter of convenience.

coldtea 11y ago
You also get access to the whole world of GUI applications. Watching video and editing pictures is not much fun with only ncurses... (ascii video hardly took the world by storm).
- laumars 11y ago
  There's no reason you can't have a CLI interface with graphics support. Granted the vt100-style terminals can't easily do it, but it was possible with the old REPL machines of the 80s (eg most micro computers which booted into a BASIC interpreter). There are some also some terminal emulators in Linux that support inlined graphics, however I'm not sure how easy it would be to run them as a WM.
  - pjmlp 11y ago
    Hence why we GUI guys rather use a REPL than a plain UNIX CLI. Graphics, the expressiveness of a sane programming language and interaction with the complete OS stack.
    - laumars 11y ago
      Firstly, Bash et al is a REPL in it's own right. What you're discussing there is that UNIX shells make a rubbish programming environment, which is a completely different argument to anything that was being discussed here. For example, DOS can inline graphics as well (proper DOS, not Windows' cmd.exe). So to follow the linked tangent you've made: DOSbox is also a better REPL than UNIX shells. Obviously neither of us would agree with that - even with our criticism of Bash et al. So equally your implied correlation is false. Secondly, your point about "interaction with the complete OS stack", suggesting that CLI interfaces don't have access to the complete OS stack, is completely wrong. If that were the case then Linux and UNIX servers wouldn't typically run headless. A GUI is a shell. The CLI is a shell. Some platforms place more love to graphical shells than command line shells (eg Windows). Other platforms empower command line shells (eg UNIX). To argue that one is better than another is about as futile as saying the colour purple is better than the colour orange. In short, it's personal preference; not irrefutable fact.
      - pjmlp 11y ago
        UNIX shells aren't a REPL because 99% of their features are implemented in external commands. The shell is reduced to orchestrate logic between those commands. None of the common ones, ash, sh, bash.... provide a rich programming environment that doesn't rely on external commands. Interaction with the whole OS goes back to Lisp Machines, Interlisp-D, Mesa/Cedar, Smalltalk, Oberon REPL experiences. Nothing to do with running headless, which means you didn't got the message. In those environments I can via the REPL directly interact with running applications from the REPL. For example, search for a specific text in all open windows and act upon it if found. The whole OS API is exposed in the REPL via library calls. No UNIX shell provides this expressiveness without relying on external commands and applications implementing specific APIs like dbus.