Zsh and Fish’s simple but clever trick for highlighting missing linefeeds

It all depends on where the input cursor is when the command terminated. You need something that works with both cases (line break and no line break) because you can’t introspect the output.

tput el clears the output to the end of line so you still have to figure out if you’re on the same line as the output or if you’re on a new line. The goal of spaces is not to clear content but to invoke the wrapping behavior of the terminal which will either cause you to be on the same line only in the case that you started off at col 0 or else somewhere in the middle of the next line, but in both cases, you’re on the row you need to be on (after taking into account whether wrapping happens at max column or max column plus one).

Edit: It’s actually a lot like rounding by adding 0.5 and truncating. And the complexities are akin to trying to do it with non-standardized or different standards of doubles and dealing with epsilon and NaN :D

If you can, please add a note that if you want to add it to bash you _have_ to use an echo/printf from PROMPT_CMD, if you add it to PS1 bash's (or readline's?) own logic will get confused as to how long the prompt is and what column the cursor is at.

(If anyone wants to try it, personally the only caveat i noticed is that when you copy a command from the terminal window any spaces not overwritten by something else will appear in the output.)

Start up fish and run `echo -n foo` to see `foo⏎` in your terminal.

I think the missing clue is that the hack is followed by `^[[K` (clear line from the cursor to the right), before control is passed to `fish_prompt` to paint the prompt or whatever else.

Here's some sample output (stripped of the hack spaces and any ansii escapes):

     mqudsi@ZBOOK /m/c/U/mqudsi> echo -n hello
     hello¶
     mqudsi@ZBOOK /m/c/U/mqudsi>

You can see all this and more by piping the output of a `fish --interactive` session to `xxd -C` or `hexyl` or whatever (that'll disable tty feature detection and force ansii escapes to be emitted that you can then inspect).`

(You can also verify by simply using `sleep 1` as your fish_prompt - you'd expect to see the glyph appear at least while the `sleep` was running if fish were waiting on/expecting the prompt to overwrite the glyph.)

I guess you mean each command not affecting the very next command that follows?

    zle-line-init() if [[ $CONTEXT = start ]] LBUFFER=$zle_prefix$LBUFFER
    zle -N zle-line-init
    mkdir $HOME/dtaches
    zle_prefix='dtach -A $(mktemp -d $HOME/dtaches/XXXXX)/sock '

am: Flag whose presence means that writing a character in the last column causes the cursor to wrap to the beginning of the next line. If `am' is not present, writing in the last column leaves the cursor at the place where the character was written. Writing in the last column of the last line should be avoided on terminals with `am', as it may or may not cause scrolling to occur (see section Scrolling). Scrolling is surely not what you would intend. If your program needs to check the `am' flag, then it also needs to check the `xn' flag which indicates that wrapping happens in a strange way. Many common terminals have the `xn' flag.

I do have some recommendations however:

- first of all use a 3rd party readline implementation. This will allow you to write your language parser, any builtins you'd need (eg `cd`) and forking routines. These are the bigger / harder problems.

- then once you have a POC you're happy with, rewriting your readline implementation becomes a natural progression. By that point you know how you want your shell to look and feel.

Even taking into account ComputerGuru insights on all the bumps of the actual implementation, it's still seem far more cleaver and elegant, at least to my mind.

I've thought about switching back to Linux but I wouldn't want to live without iTerm2.

Edit: This prompted me to make a modest donation.

    cat foo <(printf "\\n") bar


?

Much cleaner to always put a newline after the $PWD

However, I still don't understand how does a program know it's connected to a terminal rather than some pipes.

I made up my mind some fifteen years ago that if a terminal isn't ANSI conforming, it can be casually disregarded as something unsupported.

It's like testing that web pages work with Mosaic from 1993.

- multiplexing: better to use ssh multiplexing, which is just nice in general

- persistence: Yes, you want to open a pty on a the host, but you should actually emulate the terminal on the guest: one should just forward all the pty messages between the guest and host (graphical emlator). In other words, a lot more like regular ssh

- sharing: graphical emulators should just understand that multiple can be hooked up, have some support for this, we can relay the input from one emulator to the others as needed.

For my terminal-inside-shell, I would use a customer server + protocol for managing all the ptys (remember because backgrounded commands there can be multiple).

The only programs that cause an issue are tools that send ANSI escape sequences (eg for ncurses) and check if STDOUT is a TTY before sending them. In those cases you'll just get a message written saying something along the lines of "STDOUT is not a TTY".

In theory you could write another workaround to fix that workaround but it was a horrible kludge that I didn't like in the first place so ended up finding another solution (which isn't as elegant as the zsh / fish fix and I'll soon be adapting that into my own shell too).

You can still have a program on a terminal without a shell.