(18-03-2019, 01:56 AM)venam Wrote: Welcome to nixers Igrom.

(17-03-2019, 07:53 PM)Igrom Wrote: Much has been said about the virtual terminal and the shell. Personally, I find it indispensable and a cornerstone of successful and creative work on a computer.

This may be a thread on its own because we haven't discussed this yet on the forums but:
What are, in your opinion, the advantages or learning the terminal interface when it comes to computing.

For me it's about tackling the ingrained mysticism about interfaces and what should be. In sum, erasing expectations and opening the world of possibilities.

Hi venam.

Modularity and composability have been named as desirable traits in mechanical, hardware and software engineering. In software, patterns satisfying these principles can be observed in the OSI model, in my bootstrapping procedure (thanks, podcast*) and in userspace code --- hopefully, the one I write, too...

Why have them? It cuts down on cost. For a company, that's time and money. For me, it is my time, potentially my money (salary/second * time if it's during working hours) and, for the me with finite curiousness and attention span, the likelihood of following through with the side project and not quitting in a fatigued humour. It is real cost with real consequences.

I don't know of any mechanism for composing GUI applications with little expended effort. In many cases, Quite often I was interested in an intermediate state of my data that I could not output.

Before switching to Linux, I tried to conceive a shared standard for composing GUI applications. In its design, an application would typically resemble the back of a rack of audio hardware: with jack sockets next to each logical, visually grouped block of functionality. By clicking and dragging the left mouse button from a jack to another --- even to a different application --- I would be able to tee the output elsewhere. I would also be able to click the jack to e.g., set a breakpoint to inspect and manipulate the data in an editor.

The bulk of what I described are pipelines (and it's difficult to find a more graphic synonym than 'tee').

Another point against GUI is that the design of a particular task's execution --- such as trimming a video --- is an iterative process that they not always faciliate. Just yesterday I was writing a README.md file for the `plymouth-theme-sega` repository and opted to include in it an animated preview of the theme.

To generate the .gif, I ran the following commands in the terminal:


At this point, I refreshed the project's GitHub page to see that I had misspelled the project's name when configuring the Plymouth theme and have thus recorded a video of 'plymouth-theme*s*-sega' instead of 'plymouth-theme-sega'. I corrected the Makefile but would have to recreate the .gif.

Individually, each task could have been served by a graphical application, but then I would not have been able to repeat my input. In the terminal, I pressed the Up arrow to highlight the previous commands and run them. That Up arrow is that killer feature that graphical applications do not replicate --- and another reason for working in the terminal.

Lastly, both screen recording and subsequent video trimming, as well as amending and force pushing the top commit landed as aliases in my .rc file. That, too, I cannot readily get in a graphical application.

Sometimes I don't care for repeatability or the graphical application supports it. And sometimes, tabbing over fields and buttons is quicker than typing out a complicated command. For example, I would not use `curl` over Postman for anything complex.

*I enjoy your podcast and recommended it to a relative --- a newcomer who has just started work as helpdesk for CentOS users.