6 ms·

>On the other hand, mice-based GUIs ARE a 100% replacement for CLIs. Really? I can automate a pipeline of GUIs? Please show me how I can automatically query a

>On the other hand, mice-based GUIs ARE a 100% replacement for CLIs. Really? I can automate a pipeline of GUIs? Please show me how I can automatically query a database, take that output, run complex data aggregation over those results combined with past results, send that to a remote server for storage, and email myself the result of the upload, using only a combination of GUIs. (Points deducted for anything that involves instructing the machine to "move mouse to position (x,y)", since screen sizes may vary and where an individual GUI chooses to pop open a dialog/modal may also vary)

adrianN 11y ago
AppleScript can do pretty complex GUI automation tasks.
- ultramancool 11y ago
  Yeah, so can AutoIT or python with pywinauto... you could do it. It just wouldn't be pleasant. Might do it if you had to extract data from some proprietary GUI tool you couldn't tear open.
- Zardoz84 11y ago
  Windows 3.1 had a macro recorder that allow to automate task over a GUI.
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.
coldtea 11y ago
>Really? I can automate a pipeline of GUIs? Please show me how I can automatically query a database, take that output, run complex data aggregation over those results combined with past results, send that to a remote server for storage, and email myself the result of the upload, using only a combination of GUIs. Yes, you can, and we have been doing it for decades, e.g. Automator on OS X. Especially stuff like this is quite easily achievable: "query a database, take that output, run complex data aggregation over those results combined with past results, send that to a remote server for storage, and email myself the result of the upload, using only a combination of GUIs". Not only that, but pipeline steps can trivially include "run a specific cli program with this as an input and pass the output to another program" (where the previous/after program can be GUI or CLI or a remote service, etc). Nothing precludes a program with a GUI from taking formal parameters (in whatever format) and being scriptable and pipelined to other such programs. Whether your question is if this is true for a particular program P, it might, or it might not. That's no different from command line programs which might or might not be pipeline-able between them without intermediaries doing custom scraping, parsing and massaging. Other scriptable solutions for GUI programs but without GUI-based visual mixing and matching of pipelines include Applescript (and it's Javascript incarnation), Microsoft PowerShell, etc. This are textual based, but not CLI -- you can run them from an IDE for all the extra power that gives. Also macro recording/playing (available in lots of GUI apps) means you don't have to write anything like "click window at pixel x,y". And of course in the trivial case, a mice GUI can run any terminal emulator too -- making it a superset of CLI, since the GUI terminal can also include buttons, menus, show images, etc -- which a command line interface cannot -- so it gets the best of both worlds.

adrianN 11y ago

AppleScript can do pretty complex GUI automation tasks.

ultramancool 11y ago
Yeah, so can AutoIT or python with pywinauto... you could do it. It just wouldn't be pleasant. Might do it if you had to extract data from some proprietary GUI tool you couldn't tear open.
Zardoz84 11y ago
Windows 3.1 had a macro recorder that allow to automate task over a GUI.

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.

coldtea 11y ago

>Really? I can automate a pipeline of GUIs? Please show me how I can automatically query a database, take that output, run complex data aggregation over those results combined with past results, send that to a remote server for storage, and email myself the result of the upload, using only a combination of GUIs. Yes, you can, and we have been doing it for decades, e.g. Automator on OS X. Especially stuff like this is quite easily achievable: "query a database, take that output, run complex data aggregation over those results combined with past results, send that to a remote server for storage, and email myself the result of the upload, using only a combination of GUIs". Not only that, but pipeline steps can trivially include "run a specific cli program with this as an input and pass the output to another program" (where the previous/after program can be GUI or CLI or a remote service, etc). Nothing precludes a program with a GUI from taking formal parameters (in whatever format) and being scriptable and pipelined to other such programs. Whether your question is if this is true for a particular program P, it might, or it might not. That's no different from command line programs which might or might not be pipeline-able between them without intermediaries doing custom scraping, parsing and massaging. Other scriptable solutions for GUI programs but without GUI-based visual mixing and matching of pipelines include Applescript (and it's Javascript incarnation), Microsoft PowerShell, etc. This are textual based, but not CLI -- you can run them from an IDE for all the extra power that gives. Also macro recording/playing (available in lots of GUI apps) means you don't have to write anything like "click window at pixel x,y". And of course in the trivial case, a mice GUI can run any terminal emulator too -- making it a superset of CLI, since the GUI terminal can also include buttons, menus, show images, etc -- which a command line interface cannot -- so it gets the best of both worlds.