Dumb ZSH n00b question - make the Grinch look like an idiot. :-)

[jgreco]

So a year or two ago, the default shell for root was changed to ZSH.

For those of us who are lifelong sh/csh/tcsh users, this is a bit disconcerting. It places my preference to avoid making changes to a system baseline dead in conflict with my not understanding an apparently idiotic behaviour.

I prefer to avoid the use of ZFS replication in cases where dealing with file archives. I would rather use rsync and keep independent snapshots on each side. This makes it virtually impossible to end up with a catastrophe on one side being replicated to the remote.

However, a file tree reorganization becomes an expensive operation, because if you do

mv /mnt/pool/iso/freebsd /mnt/pool/iso/unix/freebsd

on the source side, then rsync will merrily re-copy all the files over the network. The solution to this is to execute the same command on the target host, keeping the trees in sync and not requiring the retransmission of the files.

Therefore, it is not uncommon for me to execute the command I want on one filer, and then cut and paste it to a command prompt on the other. This often happens using PuTTY on Windows.

What I am trying to understand is what is the "feature" in ZSH that captures and highlights the pasted text, rather than interpreting it as something, I really do mean Yes I Really Want You To Do This.

I found the obvious Google fu at

How to stop pasted text being highlighted in terminals in Ubuntu 16.10?

Since upgrading to Ubuntu 16.10 from 16.04, every time I paste text into a terminal running zsh, that text is highlighted until I type another character. It doesn't seem to matter which terminal em...

askubuntu.com

etc. but the "fix" only stops it from highlighting. The underlying behaviour still requires you to hit ENTER after pasting, and this is very jarring. I've had no luck finding what the correct incantation is to have it just execute the pasted text as though it had been typed.

Since this seems to be broken by design, and since there's a dozen other really annoying and/or really stupid things ZSH does that collide with decades of familiar tcsh actions, I may not actually do anything with an answer to my inquiry here, but I at least like to make an informed choice and understand what's going on. Why is a paste to ZSH being "held for edit"?

 

[dak180]

What I am trying to understand is what is the "feature" in ZSH that captures and highlights the pasted text, rather than interpreting it as something, I really do mean Yes I Really Want You To Do This.

I think (not having read the whole thing yet as I avoid zsh myself) that bracketed-paste-magic may be the info you are looking for; it puzzles me why it would do this sort of thing though since it seems like the kind of feature that should be implemented at the at the terminal emulator level (in your case PuTTY) rather than at the shell level.

 

[dak180]

Looking a bit farther: bracketed paste and because the freebsd forums are not loading for me currently:

You mentioned zsh, so I had a look at the man page zshall(1). ZLE is the line editor that zsh uses rather than devel/readline or something similar. It turns out that you can simply unset zle_bracketed_paste in an interactive session to disable it for that session. You can also simply disable the highlighting to retain the "safety" feature provided by bracketed paste using zle_highlight=('paste:none') in your .zshrc.

Zsh has 8 possible files that it reads upon startup, and using unset zle_bracketed_paste in every one of them still did not disable bracketed paste at the start of an interactive session, whether it was a login shell or not. Bracketed paste is enabled by default, so if it's unset (or not an array) then it is subsequently enabled. This behavior makes some sense at least: startup files are read prior to ZLE's initialization because the session may not be interactive, and if ZLE's initialization code doesn't find an array named zle_bracketed_paste, probably because it was unset or simply not declared in a startup file, then it will create the array and set default values.

Rather than unsetting the variable in vain, you need to declare the variable as an empty array using typeset -A zle_bracketed_paste in something like .zshrc instead of unsetting it. This only works because the ZLE code simply checks whether zle_bracketed_paste is an array of length 2 to determine whether to print the "bracket" strings. This means if it's an array with any other length, the "bracket" strings will not be printed to the terminal, and the terminal will not interpret the pasted text.

Note that some terminals may still choose to "bracket" pasted text on their own, but this at least solves the problem with ZLE.

 

[jgreco]

Yikes. Well, there we go, that was the entry point to this pile of pain. It's just a matter of knowing the right term to look for.

Actually so far, it is the act of having zle_highlight enabled that has been saving me. I *sometimes* notice the highlighted bits and understand it to mean that the zidiotshell has not actually done the thing that it was told to do. Unfortunately, this often happens after I've already added the next paste to the mix.

Perhaps I am just too used to the way things should work to see the benefits of this "newfangled" thing. Anyone have an explanation of how this idiocy would ever be USEFUL?

 

[Ericloewe]

Oh wow, this zsh thing is bizarre. I mean, this "feature" is probably useful if you're pasting commands one at a time... But what kind of masochist would do such a thing? Why not copy them one at a time in the first place? I mean, when given cd existingDir\n (as in a literal newline, not the character sequence '\' 'n'), it proceeds to call cd with the newline as part of the argument!?
Thing is, most Unix applications will just work with that anyway, but zsh's own built-in cd command thinks there might be an actual directory named "existingDir*NEWLINE*"?

Thank you Mr. Grinch, it's 21:14, I have an update to a web app to deploy, and now I'm pissed off at shells.

 

[jgreco]

this "feature" is probably useful if you're pasting commands one at a time...

Well, that's actually my exact use case in most cases. I'm manually manipulating trees on both servers. With literally every other shell I can possibly think of, including sh, csh, tcsh, bash, etc., I can just snag the command including the end of line with the highlight, and then paste it into the remote, and it automatically types it in and presses enter (because I copied the end of line).

With ZSH, and only with ZSH, I have to remember to actually LOOK at the target window and then notice it's highlighted, and press ENTER.

Or type "tcsh" for a less tardo shell.

 

[dak180]

Oh wow, this zsh thing is bizarre. I mean, this "feature" is probably useful if you're pasting commands one at a time...

My guess is that this is for people that paste directly into a terminal from something other than a terminal (or proper plain text editor) so you can check to see what odd formatting bits might have done before actually telling the shell to do something. I still say that this sort of thing should be done (or not) by the terminal program itself and not the shell though.

 

[jgreco]

I'm glad it isn't just me.

 

[Patrick M. Hausen]

How does the shell know something has been pasted instead of typed, at all? Isn't that a gross layer violation?

I have been using bash for interactive use for decades and tried zsh as recommended by a colleague. When I found that I could not do . .envrc to source a file in the current directory, I immediately switched back.

I am glad that FreeBSD will finally switch to a Bourne family shell for root, though. (with FreeBSD 14, IIRC)

 

[Ericloewe]

Some [Citation needed] justification for this: https://www.reddit.com/r/zsh/comments/c160o2/command_line_pasted_text/erbdiqj/

If that's the genesis, it seems like a solution looking for a problem.

 

[Ericloewe]

How does the shell know something has been pasted instead of typed, at all? Isn't that a gross layer violation?

Turns out the answer is Xterm: http://www.xfree86.org/current/ctlseqs.html#Bracketed Paste Mode

 

[Patrick M. Hausen]

So Apple's Terminal.app seems to do that, too. (bracketed paste mode)

 

[Arwen]

My Linux desktop started doing that with Bash SHELL, so it's not just the horror that ZSH might be, (have not used ZSH much or at all).

Searching, I found adding this was the fix for me;

Code:

/etc/inputrc
#
# Fix CR at end of copy & paste
#
set enable-bracketed-paste off

The issue for me was that some lame library made the change that affected the input to Bash :-(.

That all said, it's still occasionally problem elsewhere and I have not figured out the "whole" fix.

 

[Ericloewe]

The issue for me was that some lame library made the change that affected the input to Bash :-(.

I read about that, but it was supposed to be disabled by default...

 

[mr.quinns]

One could simply "exec bash" or "exec zsh" in terminal or what have you for the desired shell... if need be for a simple fix? I switch shells all the time when needed. I use Tilix as a my current terminal favorite w/ OMZ. Linux not Windoze...