On 17/11/15 00:32, Marc Lehmann wrote: >> Ideally, I would like the data to come through *as-is*, 8bit clean. > > I understand what you wish for, but I think you are trying to use the > wrong tool here. For starters, can you define what "as-is" means when the > data is binary and the terminal is in utf-8? Or a non-utf-8 filename?
Encoding sits on top of the construct if we can make the paste transparent, it won't change the current status quo. >> Without filtering the termination sequence at all, there's *no* way to >> implement reliably *any* bracketed sequence. It *is* the job of the >> terminal program to filter the sequence, and only that sequence, from >> the paste. This is not sanitization of the input, it's just protocol. > > And with filtering it is also not possible to implement this "reliably". Very true, but I'm absolutely open to discuss on how to fix that. If we agree that the current scheme is insufficient for any purpose, let's break it for the better. There's basically no-one using bracketed paste currently. To answer with the following: >> I'd rather try to manually change and restore the terminal mode through >> the pty master in order for the bracketed paste to be fully transparent >> for all programs, but I didn't get to it yet. > > zsh doesn't have access to the pty master, and is unlikely to be able to > react fast enough. No, the attached program will never be able to do that reliably. The terminal needs to do that, if possible, but even that would break down in the context of a remote pty. A proper solution might actually to devise on how the pasted content should be encoded by the bracketed paste in a way that 1) allows embedded control sequences of any kind 2) they are escaped for the terminal discipline to pass-though. In that sense, we could just encode the block in a 7bit-safe encoding such as base64 or something more efficient. > The problem with this is that a large share of pastes would not benefit > from paste mode. It's basically only _some_ multiline pastes that would > benefit from it, while most would either not benefit or suffer negative > effects from it. Not really. Bracketed paste allows to make the distinction between a human typing and a paste, and that really makes a great difference. >> Firefox has nothing to do with it here, but it shows one of the most >> important aspects of a reliable bracketed paste: if bracketed paste is >> implemented correctly in the terminal, proper behavior *can* be >> implemented at the application level, as zsh now shows. > > Didn't you just write that zsh doesn't? And why would that be proper > behaviour? The number of times where I paste actual commands into my > shell completely dwarfs the few times where I paste hidden commands from > insecure apps such as firefox - or in other words, the only way to switch > zsh into proper mode would be to disable an option that would put it into > "proper mode". zsh now enables bracketed paste by default. It actually sends \e[?2004l to all terminals, as the ones we tried that didn't support bracketed paste simply swallowed the escape. A bracketed paste is also never executed by default. A newline is inserted literally (as ^J would), so that any command can be previewed. The paste is also quoted and the quoting style can be customized with a prefix argument, so that you can paste into a quote with quotes being escaped correctly, and invisible characters can always be seen. It's a major improvement in behavior for pasting in any sense. > This is going the same path as firefox - instead of plugging javascript > security holes, we get kludges (such as disabling file urls because > firefox can't guarantee their safety, or randomly renaming your profile > directory instead of keeping javascript from snooping around in your > filesystem). > > I very much disagree that keeping the user from pasting text that she or > he wants to paste is proper - it's just more bossing around because actual > bugs (like the one in firefox) don't get fixed. I doubt firefox will ever be able to fix this issue in a way that makes "copying" safe. Frankly, I do not care, as unicode issues will always be present. Let's fix bracketed paste.
