Ask Slashdot: Where Are the Modern Terminal Emulators? 286
Slashdot reader SoftwareArtist writes:
Terminal emulators have barely changed in 30 years. They're still just scrolling windows of unstructured text. Why is there so little innovation in an application we use every day?
There are so many ways they could be modernized to help us be more productive. For example:
- If I type ls to show a directory listing, I should be able to right-click on a filename and get a list of operations to perform on that file, just like a file browser.
- If I start to type a filename and press tab twice, it shouldn't just print a list of possible completions. It should provide a popup to select the one I want.
- Why can't I cat an image file and see the image right in the terminal window?
Are there any modern terminals that update this important tool for the 21st century? And if not, what prevents them?
There are so many ways they could be modernized to help us be more productive. For example:
- If I type ls to show a directory listing, I should be able to right-click on a filename and get a list of operations to perform on that file, just like a file browser.
- If I start to type a filename and press tab twice, it shouldn't just print a list of possible completions. It should provide a popup to select the one I want.
- Why can't I cat an image file and see the image right in the terminal window?
Are there any modern terminals that update this important tool for the 21st century? And if not, what prevents them?
foot (Score:5, Interesting)
Just like a file browser (Score:5, Insightful)
So why not just use a file browser? They will filter out files based on partial name, show you a list of options when you right-click on them, do the default option when you left-click on them, and you can even see the images all laid out when you open a directory.
Plus of course drag-and-drop into another program.
So why not just use a file browser?
Re: (Score:3)
Because you're probably doing other operations at the same time that file browsers don't support, and you don't want to have to switch applications in the middle of your workflow.
As a KDE user, I can give you another reason: because Dolphin will take an hour to copy or delete files that process in milliseconds in the terminal.
Re: (Score:2)
So don't use dolphin. and be very careful using shell expansion in a command that might end up being recursive ... bad things tend to happen.
I gave answers for the complaints in the original post.
As for "switching applications in the middle of your workflow" - stop working with a shitty tiny laptop screen with overlapping windows. There's no reason you can't have multiple screens, with only 1 or 2 applications open in each one, and easily switch between them.
Re:Just like a file browser (Score:4, Informative)
One common file browser extension is to open a CLI here, I've had something to do it on many platforms. This solves the question of where to send the user's output. I see in Dolphin it's Actions > Open Terminal (or Shift-F4).
Re: (Score:2)
One common file browser extension is to open a CLI here, I've had something to do it on many platforms. This solves the question of where to send the user's output. I see in Dolphin it's Actions > Open Terminal (or Shift-F4).
Heck, even Kate does that ...
Edit ... invoke a command ... edit ...
Re: (Score:2)
I seem to recall that an open source terminal for Amiga OS had at least one of the features this guy wants. Would be surprising if 25 years later there wasn't anything like that anymore.
Re:foot (Score:5, Informative)
Re: (Score:3)
I use MobaXTerm for X windows stuff but it seems to be a bit heavy. And I think the last time I checked I had trouble finding how to modify keybaord shortcuts for tab switching to match my browser, CTRL-PgUp etc.
I found Console and I am pretty happy with it for most basic console stuff on windows.
https://sourceforge.net/projec... [sourceforge.net]
Re: (Score:3)
If I want a GUI, I'll click on one.
Complain about the file managers out there, but not the terminal emulators. The only feature I really want is auto-complete and I don't know of any terminal which has not offered that for years.
question answered in title (Score:5, Insightful)
Sounds like you're looking for an entirely different application.
Re: (Score:3, Insightful)
Terminal Emulator. They are emulating an old terminal. Did the original terminals have those features? Sounds like you're looking for an entirely different application.
He does not seem to understand the difference between text mode and graphics mode.
Re: question answered in title (Score:2)
Re: question answered in title (Score:4, Funny)
(sorry, I couldn't help myself)
Re: question answered in title (Score:5, Funny)
Speaking of Emacs, Vi, notepad, notepad++, slickedit and whatnot, does nobody notice that text editors have barely changed in 30 years? They're still just boring windows of unstructured text. Why is there so little innovation in an application we use every day?
Re: (Score:3)
Text editors have changed a lot since the 90s.
Syntax highlighting is ubiquitous, and vertical/block select is common.
Re: (Score:2)
He does not seem to understand the difference between text mode and graphics mode.
Maybe not, but most terminal emulators operate in graphics mode. They emulate text mode.
And some if not all of what he's asking for is available.
I can "cat" an image to my terminal using my normal terminal, kitty, and viu. It wouldn't be difficult to write a script or an alias where the command cat would automatically select either the legacy cat or viu depending on file type.
fzf does fuzzy completion in a pop-up window. It wouldn't be difficult to link it to tab completion in zsh or some of the other more
Re:question answered in title (Score:5, Informative)
fzf does fuzzy completion in a pop-up window. It wouldn't be difficult to link it to tab completion in zsh or some of the other more modern shells.
In fact, it's as easy as installing a plugin with zsh: https://github.com/Aloxaf/fzf-... [github.com]
Re:question answered in title (Score:5, Informative)
Re: (Score:3)
dolphin .
and
Thunar .
do the same in Linux (I'm guessing nautilus works this way too, dunno, don't use it). And, of course, the reverse also works, with both managers having a convenient "Open terminal here..." commands in the right click menu.
Reading the title of this article, I was prepared to hate it, but I could see some people liking a tab drop down or right click file options in the terminal. Why not? More options the merrier, I guess that's why I use KDE!
Re:question answered in title (Score:5, Informative)
On Mac how ever "open [something]" opens [something] in the appropriated app. And as `.' is a directory, obviously Finder is the correct app.
open "myTextFile.txt" would most likely open Textedit.app - or GVim if you have that one set as default text editor.
"start", as in "start ." or "start filename.ext" in Windows cmd or powershell gives similar behaviour to MacOS's open, in that it uses the windows file association database to decide the best app to open the specified object in (explorer for a directory, say notepad for a .txt file, etc)
Re: (Score:3)
On linux the command is (and long has been) xdg-open, which I see in current Ubuntu is also linked to /usr/bin/open.
Re:question answered in title (Score:5, Informative)
Cat is not for "displaying text" or intelligently deciding "oh, it is an image, lets pop up an image viewer" (or display it as "background" in the terminal window ...
Cat means concatanate: concatenate files. That you can use it to output a simple single text file: is basically just a side effect. A more sane person would use "less" for that.
Re: question answered in title (Score:3)
Re: question answered in title (Score:5, Funny)
Re: question answered in title (Score:4, Informative)
less works much better than most text editors, especially for large files.
Re: (Score:2)
I think the question is more about why are there two modes (text/graphics) now? Why aren't we doing both? I've wondered the same thing. To me a modern system would let you begin typing; if you didn't have a terminal window already open then it should just show up at the bottom/top of the gui in a text box with maybe a couple of lines and if you 'ls' then maybe it opens a terminal showing the results. The user can then do the things mentioned. Let the user set a preference that when 'ls' is received it, agai
Re:question answered in title (Score:5, Insightful)
And in particular, the terminal emulator is separate from the shell that you having running inside it. To add any of the suggested features you need to add support to the terminal emulator and to bash, tcsh, and zsh. And you're not going to get those changes into upstream, so you're using incompatible forks.
Re: (Score:3)
so you're using incompatible forks.
Which isn't really a big deal, considering how stable these programs are.
If this guy wants to build it, I'm definitely not going to stop him. Maybe he'll create something great and in 5 years we'll all be using it. I doubt it, but I'll keep an open mind.
Re:question answered in title (Score:4, Informative)
You say that but some of the suggested features already *are* implemented in some terminal emulators. No you don't need to modify bash to do it. e.g.
Integrated image previewing https://www.enlightenment.org/... [enlightenment.org]
Drop down selection of files https://github.com/railsware/u... [github.com]
Re:question answered in title (Score:5, Insightful)
The "SoftwareArtist" does not even seem to understand the distinction between a shell and a terminal emulator.
It would take a long time just to help him understand what he really could be asking sensibly.
There are plenty of terminals, and emulators, that can do graphics and mouse support.
And there are terminal-based interactive file browsers, staring with the good ole GNU Midnight Commander.
Does OP want to add pop-ups to BASH?
Re: (Score:2)
The "SoftwareArtist" does not even seem to understand the distinction between a shell and a terminal emulator. It would take a long time just to help him understand what he really could be asking sensibly.
There are plenty of terminals, and emulators, that can do graphics and mouse support. And there are terminal-based interactive file browsers, staring with the good ole GNU Midnight Commander.
Does OP want to add pop-ups to BASH?
This. There are graphical terminals (X-windows, RDP, Citrix), and text based terminals (VT100, Telnet, etc). Original submitter should choose the one that works for him.
If he simply wants menus in his text based shell, there is always Curses/Ncurses. If he wants to use a mouse, might as well go full graphical. A CLI with mouse support sounds like something approximately nobody but them wants.
Re: (Score:3)
Actually I understand the difference very well. I took it for granted this would involve changes to the shell as well. Perhaps I should have walked through the whole implementation stack as part of the question, but I didn't think that was necessary.
I don't just want menus in a text based shell, and I don't want to go full graphical. There are reasons I use the terminal much more than the file browser! And I definitely don't want the mouse to ever be required. But that doesn't mean terminals are perfec
Re: (Score:2)
Re: (Score:2)
Lisp machines had many of those features. Also Plan 9 had some.
Re:question answered in title (Score:5, Insightful)
Agreed. The asker isn't really asking the question he wanted to ask, it seems he's throwing words together that doesn't quite mean what he thinks it means. Terminal emulators emulate terminals. That's their job. Additional features could be nice, but a lot of what he's asking for is not doable with information available to the terminal, which presumably only gets a stream of readable and control characters.
What he really wanted to ask, is more along the lines of, "why don't we have better cross integration between a GUI and a CLI on modern computers." And that, I think, is meaningful. A modern shell running inside a graphical window with better integration with the graphical environment could offer those features, and I can see it can be useful in some ways.
I can imagine a command line attached to GUI windows so that you can also see the GUI view of the current directory. You don't have to 'ls' to see the current directory, and you get all the icon cues of file types in the directory. The hypothetical 'display ' command could show the preview in the graphical pane. Folders/files can be dragged to the command line to complete commands. Starting to type file name arguments can dynamically filter the GUI view to show what applies. Click or tab to applicable choice to complete. Wildcarded arguments could show the filtered results to which the currently typed command would apply before you hit enter.
There are multiple ones (Score:5, Informative)
Essentially what you want is not a terminal emulator, but a GUI that has a command line. Those exist in many areas for specialist uses. For example I think AutoCAD comes with one and software like Maxima comes with it in its graphical version.
Probably the best generic one can be found on Lisp machines as part of their Geneva operating system. I think Symbolics will still sell them to you as a plug-in board for certain Macintosh computers. As far as I know, it can do all the things you mentioned.
Probably the biggest problem with that is that the concept of a terminal emulator is to display characters. This is something completely different to a browser which deals with complex document structures where a text can also be a link. This is one reason why browsers are so complex and terminal emulators are a lot simpler.
So you want a file manager then with a GUI? (Score:4, Informative)
Re: So you want a file manager then with a GUI? (Score:3)
File manager on text: Norton Commander.
But I think that the question raised is bad. We do have modern terminal emulators too, like remote desktop.
But in some cases a text only terminal is all that's needed to do the job. It's a performance v.s. bandwidth of the communication channel and endpoints. A text terminal is sufficient to manage some embedded devices.
Xterm is able to manage colored text too, even though it isn't 16 million it's sufficient.
Re: (Score:2)
Re: (Score:2)
X11. You must be young, despite your 5-digit id.
Re: (Score:2)
Terminology is pretty good (Score:5, Informative)
Re: (Score:2)
I was going to post about this, but you beat me to the punch.
I use Terminology as my standard terminal program. It's great. Definitely has a few novel features that other terminal programs aren't capable of.
Please Meet and Understand the KISS Principle (Score:5, Insightful)
"Terminal emulators have barely changed in 30 years. They're still just scrolling windows of unstructured text. Why is there so little innovation in an application we use every day?"
Because the emulator JUST WORKS. And it per it's nomenclature, it is an emulator that replicates the what the Terminal does. It is not supposed to ad to it. So the Emulator applying the KISS (Keep It Simple Silly) principle. So the emulator is doing exactly what it was designed to do and doing it well.
Because I want a small frontprint (Score:2)
You probably want Xming or Cygwin/X (Score:3)
When you want a remote GUI, you do not use a terminal emulator. Most often, you want an X Windows emulator.
Re: You probably want Xming or Cygwin/X (Score:2)
Or remote desktop.
Don't get me wrong, I use cygwin too. Xeyes ftw.
Why are terminals still so useful? (Score:2)
Re: (Score:2)
Re: (Score:3)
I fully agree! (Score:2)
In some ways, the interface I had on my C64 is better than the command line interface we have now. It was a full screen interface, instead of a single line.
On OSX, iTerm2+tmux already gives some benefits. vscode+tmux is also quite good. Or just vscode.
Another option is various notebooks. For example, in TeXmacs you can get a shell to work, and then you have a notebook interface to shell, which means you can go up to previous lines, save the whole session, add comments, and so on. It would be easy to write a
Terminal Emulator, not Shell Window (Score:3)
The terminal emulator is one level too low to be very smart about what the user is doing. It's providing a text window. Interacting with that, you typically run some sort of shell program (e.g., Bash), and then from there you run other programs. In theory, a terminal emulator could be told what shell you're using, and then watch the command stream to sometimes figure out what you're doing, but not always, as if you use some alias for 'ls' instead of typing it directly, it won't know what you did.
Now I suppose a terminal could determine what process is writing to it, and from that determine what command is outputting, allowing it to do something special with the text. So in the terminal configuration, you would specify filter scripts for various output programs (perhaps with examples for 'find' and 'ls'). These scripts would add special escape codes that would make things clickable to run other scripts.
There are some simple things that would be nice to do, like make URLs clickable (triggering a script that would open a new browser tab, perhaps), which could be done with regexp matching. I wouldn't be surprised to see comments with names of terminals that can do just that.
What an stupid question (Score:2)
A terminal EMULATOR does precisely that: it emulates the behavior of a text-only interface. This is because we have an ecosystem of command-line tools designed to work on a text-only interface, often interacting with each other forming pipelines. Any system administrator or DevOps engineer, and most software developers, need to work on a daily basis with command line tools that are intended to run without human interaction: when we write workflows for GitHub Actions, run commands on a remote host via SSH, a
Re: (Score:2)
Terminals (well. VT on Linux) and terminal emulators already understand mouse stuff and can do graphical stuff too. The links2 browser is a great example, with the right compile options you have text based web browsing with mouse click support for links and the ability to display inline images. Running from a xterm or a vt on a *nix box.
Lack of need (Score:3)
Nearly all administrative work that needed a prompt previously has front ends. People who still use a terminal (including me) don't want those things enough to build them.
EMACS (Score:3)
There's probably tons of elisp to do all the little things you want. Not everything has to be named what you think it should be named.
Re: (Score:2)
Re: (Score:2)
Bricks (Score:2)
Brick technology has not changed in 7000 years. If anything, todays bricks are cheaper made, and it shows.
Re: (Score:2)
I'm pretty sure that modern building bricks are not sun-dried, so that's one technological change. The frog also probably doesn't go back 7000 years, although I haven't found an unambiguous source dating it precisely.
Re: (Score:2)
Fired bricks have been a thing since Mesopotamia (5000 BC, aka 7000 years ago). Reference: https://iopscience.iop.org/art... [iop.org] Sun-dried bricks are a lot older. As for frogs, I just googled it .. seems to date back to ancient Egypt .. but that is a marketing thing .. serves no tech function anyway.
Emacs + dired (Score:2)
And if not, what prevents them?
The same thing that prevents hammers from being useful as a screwdriver?
I know it's old and not for everyone but Emacs' dired mode does all this, is completely programmable, and can be driven from the keyboard (in addition to providing mouse support if you're into that). Obviously it's not a terminal emulator (although dired integrates nicely with terms that are available inside Emacs) but it gets the job done. Of course it's not new and flashy and has an actual learning curve, so it's easy to dismiss out
fig + imgcat + omz (Score:2)
Look into Zsh, OMZ, Fig and imgcat, should give you most of what you've asked for.
It's a different philosophy (Score:3, Interesting)
The short answer, I suspect, is that it doesn't exist because nobody wants it bad enough to write one, and nobody sees a market big enough to pay someone to write one.
I'm looking at this from a linux user perspective, so I can't speak to Windows or Mac, but probably one of the biggest reasons is philosophical. I use a terminal in order to *avoid* all those gui-based things. If I have a task and want to click on things with my mouse, I'll use an app that does that. I wouldn't double click on the output of an "ls" command because I don't want to reach for a mouse.
Second, a fair amount of terminal typing involves playing stupid regex tricks or more complex commands or writing simple code. I don't know how you would make that work in a gui without turning it into an IDE, and there are those around..
So, you tend to find terminal emulators that extra actions and capabilities, but they mostly are pointed at improving readability (e.g. color text and auto-indent) and the ergonomics of typing. There is one emulator in linux that will provide previews of images and such, called Terminology I think, but I've never bothered to use it. Finally, if one is used to a terminal, then the ergonomics of doing what you suggest would take *more* keystrokes than just typing the command. Double-clicking on output and then choosing something from a drop-down would slow me down. Similarly, I almost never type a full filename, since combinations of wildcards and such make it unnecessary. Most of the time, it's just a couple of characters.
So, I probably wouldn't bother working through the learning curve to use a terminal with gui addons.
Re: (Score:2)
OK. I'm also a Linux user. And I use GUIs all the time. I use a terminal for stuff which is more easily done with a terminal, and I don't *want* a fancy interface full of stuff. The bash shell can already to a lot more than I've ever bothered to learn how to do. Fancier interfaces mean either a steeper or a longer learning curve, and I don't want that. What I would like was if it were easier to copy things from the terminal and paste them elsewhere and the converse. It would be nice if ctrl-c worked
Use Konsole (KDE) (Score:5, Insightful)
Konsole (and the integrated terminal thingy in dolphin shortcut F4) does two of the three suggestions:
- right click on any file, get the usual right-click menu like like in the file browser dolphin
- hover any file name, get the preview. The file also opens when clicked (this is actually annoying, too easy to click by mistake when trying to highlight the name to copy it elsewhere).
One can apparently install lsix, img2utf or viu to view images inside a terminal. According to https://ostechnix.com/how-to-d... [ostechnix.com]
Re: Use Konsole (KDE) (Score:3)
It was in the experimental branch this summer. It might be released by now, but only in the most recent releases
I Fancy a Real Terminal (Score:2)
Kitty (Score:3)
Kitty allows you to "icat" an image, it has configurable hyperlinks for files and URLs, as for the "popup menu", it is more of a shell thing. As expected for a modern terminal, it also supports things like ligatures and emoji.
But the main reason I use is simply that it is fast, with multi-threading and GPU acceleration.
https://sw.kovidgoyal.net/kitt... [kovidgoyal.net]
Another thing filed under (Score:3)
Why can't something X have something I want Y?
Example: "Why doesn't this jet-pack have a slushie dispenser?"
Re: (Score:3)
No, he's asking if X with Y exists. The answer is yes. And clueless idiots are mocking him for it.
https://www.enlightenment.org/... [enlightenment.org]
https://github.com/railsware/u... [github.com]
https://codeberg.org/dnkl/foot [codeberg.org]
Just some examples of terminals implementing some of the features he's asking for.
As for the jetpack, as soon as you build me a functioning one that can be operated with one hand I'm going to come back and ask you if we can add features for the other hand. A slushie dispenser sounds good. I'll probably need a refresh
A shame it's gone now, but Cathode for Mac (Score:2)
Not "new" ideas, per se, but a beautiful emulation of old glass-tube terminals.
The distortion, glitches, bulbousness aren't new ideas, but presenting them in your terminal was.
https://www.youtube.com/watch?... [youtube.com]
Re: (Score:2)
Speaking as someone who had a VT100-AA and coveted the VT220s at the public library because they had higher quality displays, piss on all that. I also had a Kaypro 4 but I don't want a tiny adm3a-emulating terminal on my desktop
LISP Machine (Score:2)
You really need to sit down in front of an original LISP machine.
Attempts (Score:2)
Eshell has done this for years (Score:2)
Eshell, part of Emacs for years (decades, really) has done all this and more. Because it integrates with tramp, you can pretty seamlessly do things like redirect to files on other boxes via ssh, etc. If you use it with an Emacs distribution like Doom, all sorts of things are integrated nicely.
Once in eshell:
To get a clickable listing of files, use "dired" instead of "ls". Dired supports all the file operations you're after.
Press Tab for completion and you're presented with a popup with possible completion
Confused about what he wants I think (Score:2)
I wonder if he is thinking of something like Midnight Commander (aka Norton Commander) with a few added features?
I never used it but I worked with a guy who did. This was back in the day where VGA was the highest resolution you could commonly get for the PC world. He could do all sorts of magic manipulating files and seamlessly going into and out of editors and working the CLG cycle. It really worked for him but I never got into it.
You're asking the wrong questions (Score:2)
- If I type ls to show a directory listing, I should be able to right-click on a filename and get a list of operations to perform on that file, just like a file browser.
Just use a TUI file manager, I like nnn but there are dozens. Why are you using your mouse?
- If I start to type a filename and press tab twice, it shouldn't just print a list of possible completions. It should provide a popup to select the one I want.
Why shouldn't it provide a list? Why should I have to move from keyboard to mouse to select from a list? Why do you think that switching from keyboard and mouse over and over is the most efficient method?
- Why can't I cat an image file and see the image right in the terminal window?
There's probably a dozen ways to do [github.com] this [kovidgoyal.net].
Re: (Score:2)
Why shouldn't it provide a list?
The list covers 99.99% of the cases, but there are rare cases where a list is not practical, e.g. name are meaningless series of characters with small differences, say a number changes in the middle of a file. In some cases the list is difficult to read, one has to read all the characters one by one to find which are the options to get one or the other file. I would love if it would highlight the first differing character in a different color. I use bash, maybe some more advanced shell does this.
Aren't those GUI features? (Score:3)
On the opposite side, try working with our hands on the keyboard and then having to move your hand away just to click on something instead of just typing a simple command for every command you do. It gets annoying very quickly and gains you very little.
Who is SoftwareArtist and why is that person trying to reinvent the GUI?
The last thing I want (Score:3)
The last thing I want is to take my hands from the home row to click on a mouse button.
Termini needs to be vendor / OS agnostic (Score:2)
Warp, have you tried it? (Score:2)
Not sure it does everything you want but have you seen Warp? [warp.dev]
I've only used it a little so far but it seems like a very advanced terminal compared to (as you note) the very limited apps we have had to date.
The future is here (Score:2)
Konsole supports emoji, what more could you want?
Re: (Score:2)
Konsole supports emoji, what more could you want?
For stuff NOT to support emojishit? Or other non-ascii-standard characters that LOOK like standard ascii characters. Certainly don't want that crap embedded into a filename.
Re: (Score:2)
For stuff NOT to support emojishit? Or other non-ascii-standard characters that LOOK like standard ascii characters. Certainly don't want that crap embedded into a filename.
I noticed because youtube-dl now produces filenames with such characters by default, and vlc won't load them.
It doesnt because I use them over SSH (Score:3)
When youâ(TM)re using the terminal through remote SSH connections you donâ(TM)t have the option of a gui. Iâ(TM)m bouncing through more than 15 computers to remote into work. Using Vim is usable but not anything graphical. Multiple different layers are adding and removing encryption. Many of these computers are extremely busy. If I try to run a graphical app, everything slows to a halt.
Sometimes I will type and not see anything for up to 10 seconds, so I just have to type what I know is correct and wait.
I donâ(TM)t want to have this ruined by some hipster who needs a graphical interface popup.
I have real work to do.
what? (Score:2)
Re: (Score:2)
Re: (Score:2)
Who stopped you from developing it? (Score:2)
Terminals are museum pieces (Score:4)
This is not a disparagement of terminals, because they're either good at certain tasks, or allow simpler development.
On a highly technical level, modern graphic terminals are meant to emulate the ascii plain text of older devices, which in turn emulate the 80x25 character display, which in turn emulate the 80-column punch card system [ibm.com], and early ASCII tables. Even though terminals are useful, they're still anchored by significant historical design.
There's been a few attempts to at least break out of the raw text stream - mostly the Curses library in order to give colored text, or to at least allow presentation beyond a simple text stream, but it was still designed for terminals rather than interactive GUIs. Additionally, something like Telnet (a primitive remote console) didn't autodetect the client's display size.
Now, there's room to make adjustments if the official standard is willing to shed the last remnants of the oldest terminals; perhaps shedding the various ascii control characters that don't seem to be used even in special cases (anyone seen Shift Out or Shift In?), and replace it with new control characters that can help. However, this requires changing a standard and that's extremely slow.
So, that would be a rich-text or hypertext terminal. After fiddling with the standard, let's pretend this works, and implementing it isn't too complex.
The question is how it will work. Let's say I'm on Windows, and using a telnet to a Linux system - how will right-clicking to get the filename help when going across computers? There's no guaranteed file sharing, or it might be blocked for some reason. Maybe the file isn't in a shared folder, such as something in /etc/ or /usr/home/root/
Your example works fine on local terminals, but not for an SSH into a remote computer.
At that point, it's full hypertext. I'd want to be very cautious with that, considering the many ways some webpages can attempt to trick the user into doing something that shouldn't. And since terminals are designed for dealing with admin-type stuff, it can become rather dangerous.
Sometimes simple is good (Score:4, Insightful)
There may be use cases where complex terminals are useful for things that can't be scripted, but I don't run into them.
Modern terminal emulators are alrready here (Score:3)
> If I type ls to show a directory listing, I should be able to right-click on a filename and get a list of operations to perform on that file, just like a file browser.
No. If I wanted a file browser, I would have used a file browser. Terminal emulators are used by people who can read and write, not just point and grunt.
Cat a cat pic (Score:3)
A few years back, I created a set of libs [slides.com] to provide this in Gnome Terminal. Not the most elegant solution but it allowed SVG to be rendered into the terminal and so, once the custom libvte was installed then gnome-terminal would support overlays like a miniview for vim (only requiring a vim plugin), ability to print image files to the terminal, matplotlib graphs for system monitoring, etc. I even had partial tmux multiplexing support and passthrough for SSH.
Naturally, there was a lot of work to do going forward to make a stable production tool - for example, if a program can write arbitrary images to your terminal it can mislead you in ways a normal console program couldn't, but equally usage/security issues like that were not necessarily _that_ far from what you could already do, and these were not unsolvable problems. Compatibility-wise, anything that could output SVG as text could manage the simple protocol, and I'd client libs for Python so it was a little like ncurses usage (in fact, one example uses ncurses and gasket).
After a while I realised that the general response was "Nice novelty - shrug" so rather than keeping maintaining or improving a fork of libvte, I stopped. That was 8 years ago - now I still miss my miniview in vim :/
That's the beauty of terminals. (Score:3)
The beauty of terminals is that they're just scrolling lines of plain text. Plain text is a kind of universal language.
if you want a GUI app with a command line, that is a totally different thing. For example Python has Jupiter.
There's a lot of scope for a 'graphical command line'. Indeed a lot of scope of a text-based interface that isn't a terminal
(rather a m×n array of character cells that you can address directly). But then, while you're at it, why stick with
monospace fonts for everything? What about dockable tabs that give you dynamic help on what you're typing in?
If you dispense with the *nix way entirely, and have a pile of built-in commands, and a powerful modern scripting
language for writing more, and which wrap the standard *nix commands (together with information for completion
and help), that would be nice. But again you're talking about a command-line driven GUI app. I'd love to see that,
but it isn't a replacement for the command line per se. It could, if such an app existed, be readily adapted to make
a powerful learning environment for the actual text command line. But it's kind of like replacing the 1-liner 'printf("Hello world");'
with a React app and an Electron runtime to load it.
The thing with command lines is that, despite their simplicity, you can do a lot with them. And if you're connecting to a
server in another country via SSH, you get essentially the same Linux environment you have at home.
Because it has to work over a serial tty interface (Score:3)
1. Because they have to work over a TTY interface, people who can't hear still use serial based TTY terminals to this very day. In infrastructure management we still use literal serial terminals to manage and access pre-boot environments. Servers boot up using serial console redirection.
2. They are very well established standards that just works, i.g. POSIX, DEC's VT220 with Sixel support[1].
3. It's extremely scriptable and programmable because the domain and range of the functions are very well defined, i.g. ASCII and UTF text and escape codes.
4. Once you've mastered the POSIX userland there just no need to rely on anything else, I can write the equivalent of 100 lines of C code with just a single line of POSIX code in a bash shell.
5. iTerm2 already has most of these bells and whistles, you just have to know the macros and keyboard shortcuts.
6. KISS
POSIX honestly is its own programming language once you have master all of the essential verbs and how to correctly setup your tasks for stream processing using shell scripting. I can tell the machine explicitly what I want it to do for me on my behalf autonomously, so for me personally if I had to go back to pointing and clicking that would be a major regressive step backwards, and at that point I would just use Finder in the GUI. There is AppleScript and Automator as well, all four of these things have their place.
[1]: https://manpages.ubuntu.com/ma... [ubuntu.com]
Re: (Score:2)
OK. But my thought was that what he wanted was geany, with the terminal emulation open and no file open. That should be easy enough to do, but I don't think the current version supports it. He was talking about using the mouse, so the basic idea seems appropriate.
Or perhaps what he wanted was Konsole with a bunch of custom menu mods. That should also be fairly easily doable. Various IDEs do that kind of thing all the time, though they aren't terminal centric.
Probably the real answer is that he wants a
Re: For real? (Score:2)
When searching for a file 'dir /s' with a wildcard pattern works best for me.