> Thanks for the responses.
>
> The -p or ps option, wow dude... thats wild.
>
> I get something looking like ..
> 4d534346000000008747cf05000000002c00000000000000030101003f03
> 00003705000049020100bc21010018050000000000000000793180492000
>
> Ok I can hadle that. So I tried ....
> :1,$s/5c57494e4e545c/5c57696e646f77735c/g
>
> Unfortunetely, after I type :%!xxd -r ,I get an error "Shell Returned
> 5" after it changes the files. I could not find what the error means.
It means the xxd utility returned an error code, specifically, code 5.
It may have some meaning you can get from the man pages.
> After some time evetually the program gets back to vim. But it looks
> different, like a bunch of ^@ with a few c:\windows for good measure.
> This methodology seems to screw up the file ???
>
You need to give the -p argument on the reverse conversion as well,
otherwise xxd expects the file in the rigid format you started with.
So you can use either:
%!xxd
%!xxd -r
or
%!xxd -p
%!xxd -p -r
but not a mix of the two.
At least, that's the theory. I've never tried the -p stuff because I
always just use replace mode when editing binary files.
> On the comments made by CJ. a cab file as you have properly deduced is
> like zip file only developed by MS. It is used to store MS things.
>
> I hear what your saying about changing binary files and Yes i agree
> its a dicy thing. Frankly Ive never realy know the differnce, accept
> that they have characters that most editors cant read. And that often
> if you change them you have broken it and made mashed potatoes. I know
> as well that some of the issues are related to editores putting in CR
> and the like, which obviously break the binary.
>
> However when you see an ascii character eg \windows\ It "should"
> empasis on SHOULD be ok. I have done this before and its ok
> sometimes.
>
> As far as your comment
> "As such, replacing 5 bytes by 7 bytes as in this example can wreak
> havoc with the contents of the file and make it unusable."
>
> On this comment I plead ignorace. Your absolutely right if you change
> the file enough it will not work. But I have found that if done on
> readable text delecately it can work.
>
Some file formats have byte counts/lengths embedded in the file, so
changing the length of the file can easily screw this up. Other file
formats use CRCs, checksums, and the like to detect file corruption,
meaning that if you change ANY bytes in the file, you're likely to
make the entire file unusable. Some compression methods depend on all
the previous data in a file to uncompress other data, making the data
unrecoverable if you change it.
I don't know whether CAB files employ any of these methods.
> Maybe this is just at the edge of what vim should do, and maybe it
> should not do what Im asking it to do. I duno. I just like vi and like
> that it might be able to do what I need in some of these advanced
> areas.
With a proper knowledge of the file format, and what tools reading the
format are expecting, it should be OK to use Vim to edit them. But
it's better to use tools designed for the task.
Sure, you CAN manually edit the assembly code emitted by a compiler,
but it's much better to edit the C code and use a compiler to
regenerate the assembly, 99.9% of the time.
--
You received this message from the "vim_use" 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
No comments:
Post a Comment