Created attachment 8105 Illustrative screengrab Even on my fast laptop, opening a terminal and starting to type can result in text appearing before the terminal prompt, in this sort of fashion (sic): textIhaveStartuser@domain $ This looks really bad and I imagine it would not be that hard to fix. I am surprised there is no existing open bug report about it. Has the problem been fixed already? By the way, I use the xfce terminal emulator because, among other things, it is fast; but this, in a way, a speed problem. Were my bash config files smaller, I would have the problem; but those files are not especially large, and what is needed is some sort of buffering. Linux Mint 19 Cinnamon. xfce-terminal 0.8.7.4
Hi, and thanks for the report! This is a good one, I will tlook into it. I can see that the same may happen when using gnome-terminal or even xterm; can you try other terminals on your end? > This looks really bad and I imagine it would not be that hard to fix. This is a bold statement, though, is it based on a particular experience with terminal apps development?
Thank you. It does happen with gnome-terminal and with xterm. So, here is a way you could outdo other terminal emulators! On my bold statement: perhaps I was too bold; I have no experience developing terminal applications. My thinking was that this was a cosmetic issue and as such would not be hard to fix. Yet, I suppose (guess) that it is not an entirely cosmetic issue! The laptop in question has an i7-8550U Intel processor, a very fast PCI-SSD, 16GM RAM, and is not under load when the problem happens. I would not mind having to wait for the prompt, or for the prompt to work, for a third of a second or so (though if the prompt appears but will not function for a moment, then the user would benefit from some sort of indication of what is happening, e.g. a 'busy' pointer).
The situation is exactly the same during the startup (the short time when the terminal is already up but the shell isn't ready yet) as during other commands such as "sleep 10". You can type ahead, but it appears on the screen. I'm not sure how much this was an intentional design 30-40-50 years ago, or a legacy that we still carry; however, changing this would probably require to change plenty of fundamentals in multiple components (terminal emulator, kernel, shell). Plus I'm not sure if it would be better; I, for one, like seeing the characters I type ahead, contrary to my old memories of DOS having a buffer of about 15 characters that I could blindly type ahead, but didn't appear on the screen. In the current setup it's not the terminal emulators that decide to show the keys you press. When you press the "s" key, it sends the "s" letter to the kernel via the terminal line (this is always what the terminal emulator does on a keypress). The kernel, according to the line settings (see "stty"), decides to echo it back, sends back an "s" letter which the terminal emulator displays. As far as the terminal emulator is concerned, the sent and received "s" letters are unrelated, there's no way to semantically connect them. A "fix" to this situation should begin by asking the kernel not to echo back the characters (like "stty -echo"), followed by adjusting bash to properly toggle this setting back and forth. (On a side note, there is a mode of terminal emulators where they locally echo any pressed key, this is called Send/receive mode e.g. here: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html. I haven't seen it used anywhere. Apart from this mode and apart from certain escape sequences modifying the keycodes, as far as the terminal emulator is concerned, the outgoing "which key is pressed" and the incoming "what appears on the screen" directions of the communication are unrelated. If pressing "s" causes an "s" to appear, this is because some other component, e.g. the kernel or the shell decides to echo it back, and not because of the terminal emulator.) One thing you can do is modify your prompt to begin with a carriage return and then clear the line. This will, however, wipe out the last line of an app's output if it didn't end in a newline character. Another typical pattern is to have a prompt which prints exactly as many spaces as the width of the terminal (or often the first character is an inverse % or something similar instead of space), followed by a carriage return and then erases the current line. If the line where the prompt is printed is empty, this effectively does nothing. If the line contains any character then this wraps the cursor to the beginning of the next line, that is, the output still remains visible (optionally an inverse % or so even notifies you that the output didn't end in a newline), and most importantly the prompt then appears own its own line. Yet another thing you can try is to place this as the last command of your ~/.bashrc, e.g. echo -ne '\r\e[K' which will significantly shorten the time frame when a character you type remains there before the first prompt. As opposed to modifying your prompt, this is a one-shot wipeout of the contents at the start of the shell.
OK, not a merely cosmetic issue then! The rather arcane echo -ne '\r\e[K' doesn't seem to work (in either ~/.bashrc or /etc/bash.bashrc). I do not fancy the modification of the prompt - for the reason you give.
It seems there's nothing I can do in xfce4-terminal... closing.
Created attachment 8351 Screenshot (new)
Might I try again to spur action on this? Please see the (new) screenshot that I have attached. What the user here sees looks amateurish and is somewhat throwing for the user. Is there really nothing xfce-terminal can do about? Perhaps not . .
I've already outlined the technical aspect, now here is my personal opinion. Quoting from bash's manual: "When executing interactively, bash displays the primary prompt PS1 when it is ready to read a command [...]". If you're typing to your shell before it's ready, it's your problem. It's like talking to a person before they listen to you. They will probably still hear your words, but depending on the situation, it might be considered disrespectful. You can try to type ahead letters or click at places in various graphical apps or websites, they might also work incorrectly if the app or page hasn't fully loaded yet. E.g. if the new webpage takes long time to load, your keyboard and mouse events still go to the old page, even after you clicked on a link or typed a new URL in the location bar. It's not much different from what's going on in the terminal. I tried to type ahead in gnome-terminal something that makes sense (I don't expect xfce4-terminal to differ that much), "ls" in particular as you demonstrated, and the most I could do is to type ahead 1 letter. I could type ahead more letters by hitting many keys at once, a use case I couldn't care less about. Your screenshot shows two. Unless you automatically ssh somewhere, I believe your shell is configured to be slow (or your fingers are damn fast). You could check its config and startup files to make it start up faster. > looks amateurish That's your personal opinion. Others might find it useful. Others might for example find the fixed width font amateurish. Or the line editing experience. Or whatever else. Terminals and terminal emulators are an ancient story, evolved to whatever they are now. We're making improvements over time, but there are things that just can't reasonably be changed; especially if they involve multiple components, not just the terminal emulator, as this one.