On Thursday, June 9, 2016 at 5:34:10 AM UTC-4, Ken Takata wrote:
> Hi cryptoz,
> 
> 2016/6/9 Thu 15:53:05 UTC+9 cryptoz wrote:
> > I have followed instructions on the Internet to edit gpg encrypted text 
> > file transparently. It almost works, but the file format is messed up for 
> > gpg files. 
> > 
> > OS: Windows 10.
> > vim version: 7.4.1023 and 7.4.1721 (tried both)
> > 
> > Problems: 
> > 
> > Suppose I have a file a.txt. It has only one character in it (say, 'a'). 
> > The file has three bytes:
> > 
> > 00000000: 61 0d 0a
> > 
> > If I encrypted the file with gpg without armor, the output file has 
> > hundreds of binary data. When I opened the gpg file with vim, there is an 
> > ^M at the end of the line. 
> > 
> > The fileformats is set to dos,unix and fileformat (detected) is dos.
> > 
> > If I use armored file (.asc), there is no issue.
> > 
> > The script I put in _vimrc to open *.gpg,*.asc files is similar to what I
> > got from http://vim.wikia.com/wiki/Encryption
> > 
> > I understand correctly, the steps are:
> > 
> > 1. set bin option before read the file.
> > 2. read the file into buffer.
> > 3. call gpg to decrypt the buffer. 
> > 4. set nobin option.
> > 
> > I am not sure when fileformat is detected during this process. I tried to 
> > set fileformat to dos in each step, it did not work. 
> > 
> > The problem could be the fileformat detection is done in 2. Since it is a 
> > binary file, fileformat is set to unix. In step 3, when decrypted text is 
> > placed back in buffer, there is ^M at the end of each line because 
> > fileformat
> > is already set to unix. 
> > 
> > I would think a better way to handle similar situations is add a user 
> > configurable filter to convert the stream read from the file into another 
> > format (e.g., decryption, encoding) and another filter one for writing.
> > 
> > Thanks.
> 
> I see a similar problem when I use a setting written in `:help hex-editing`:
> 
>       augroup Binary
>         au!
>         au BufReadPre  *.bin let &bin=1
>         au BufReadPost *.bin if &bin | %!xxd
>         au BufReadPost *.bin set ft=xxd | endif
>         au BufWritePre *.bin if &bin | %!xxd -r
>         au BufWritePre *.bin endif
>         au BufWritePost *.bin if &bin | %!xxd
>         au BufWritePost *.bin set nomod | endif
>       augroup END
> 
> When I open a *.bin file on Windows with this setting, each line ends with ^M.
> The following setting seems to fix the problem:
> 
>       augroup Binary
>         au!
>         au BufReadPre  *.bin let &l:bin=1
>         au BufReadPost *.bin if &bin | setlocal nobin nofixeol ff=unix | %!xxd
>         au BufReadPost *.bin setlocal ft=xxd | endif
>         au BufWritePre *.bin if &ft=="xxd" | setlocal bin | %!xxd -r
>         au BufWritePre *.bin endif
>         au BufWritePost *.bin if &ft=="xxd" | setlocal nobin | %!xxd
>         au BufWritePost *.bin setlocal nomod | endif
>       augroup END
> 
> (Sorry, not tested well.)
> 
> Maybe we need `set nobin` before reading from a filter and `set bin` before
> writing to a filter.  'fixeol' and 'ff' should be also adjusted properly.
> ('fenc' should be also adjusted?)
> 
> Regards,
> Ken Takata

Thank you, Ken. 

It seems working in the sense that ^M is removed. 

I added a line before sending everything to the filter. 

autocmd BufReadPre,FileReadPre      *.gpg setlocal bin
autocmd BufReadPost,FileReadPost    *.gpg setlocal nobin nofixeol ff=unix
autocmd BufReadPost,FileReadPost    *.gpg,*.asc '[,']!gpg -q --decrypt 2>NUL

The setlocal nobin line is the newly added one.
My understanding is that when feeding lines to the filter, try to make it 
binary (using nofixeol and ff=unix). When reading lines from the filter, treat 
them as text ( the nobin option). 

I also think there may be cases this method does not work (or not perfectly). 
As fileformat is set to unix before using the filter, the output of the filter 
should be unix. This may not be true for the program used in the filter and 
sometimes it is hard to change the behavior.

Another issue is that the fileformat is set to unix manually, the original end 
of line is lost. When saving the file, the end of line is set to unix (when the 
bin option is set before using the output filter).

So I think this method can remove ^M at the end of lines if the end of lines in 
the original file (in my case, the file before encryption) is dos style. When 
saving the file, the end of lines changes to unix style.

A better way to handle this could be a new function in vim: the input and 
output format of the filter can be configured separately. When decrypting, the 
input to the filter is binary and output is text. When encrypting, the input is 
text and output is binary. 

Another option could be to use a hidden buffer. It can be tedious to save, 
restore and copy settings between buffers.

Best, 

cryptoz

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui