The following symbol shows up when i view my file in vim.
---<snip>----
^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#
^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#^#fstalone
---<snip>-----
The file that I create is by redirecting stdout and stderr of my utility, like this: #./my_util > util.log 2>&1. This file tend to grow quite huge ( ~4 MB )
What is this symbol?
How to get rid of it?
That is the null character, in a format (which Vim uses a lot, as you've probably noticed) called caret notation. Basically, somehow you're getting bytes full of zeros into your file.
Since we don't know what your utility is doing, if it's the culprit, you'll need to show us some code if you want us to help. Otherwise, if you just want to remove the characters from your file, use a substitution:
%s/<Ctrl-V><Ctrl-J>//g
Ctrl-V marks the beginning of an escape sequence. After pressing Ctrl-J as well, you should see ^# appear in your command. Thus, as you guessed, Ctrl-V, Ctrl-J is one escape sequence for the null character.
None of the above worked for me. I had a file with '^#' at the end of some lines that I wanted to replace. I managed the substitute it by searching for '[\x0]' using:
%s/[\x0]//g
I hope it saves someone an hour of their life.
There's an explanation here that I will go back to read when I'm not so busy:
A discussion with a better explanation
^# shows up when you try to open a non text file in vim. For example if you open a exe file or an image file ^# is shown which is a non-readable character. Try opening the file in some other editor and see the result
Related
I'm writing an errorformat string, and it works for the most part. My problem is that I have lines like this as the makeprg output:
Some text I want to show in the QuickFix window^M
Yes, the line ends with an spurious ^M character I want to remove. So, what I want in my QuickFix window is this, without the ^M character:
|| Some text I want to show in the QuickFix window
but I have this instead:
|| Some text I want to show in the QuickFix window^M
So far, this is the relevant part of my errorformat:
set errorformat=%+GSome text%m
I've tested, without success, something like this:
set errorformat=%+GSome text%m%-G^M%.%#
but it throws an error (not from the ^M which is a literal control-M char, not a caret followed by an M).
Obviously the solution is not using %G but I am at a loss here.
How can I remove the line ending character from the line here? And also, removing the initial || would be a plus, but I think it's impossible to do in Vim.
Thanks in advance!
Edited to make clearer how the input text looks
Well, turns out I found a solution, probably not very good but it works, using trial and error.
set errorformat=%\\(Some Text%*[^.]).%\\)%\\#=%m
That is, the solution is using the Vim pattern (regex) expressions within errorformat, which has a quite arcane look but works, together with %* to match unknown text on the rest of the line
The solution uses \#=, a zero-width match, and requires some kind of terminator for the line, which appears before the ^M character I want to ignore, and some kind of text appearing somewhere on the line to match that line and not others.
Probably there is a much better solution but this is the best I could do myself.
I have written some c code, and the end of my output is '\n', when I check the output text file in vim, I cannot find the last empty line, however, when I open it with another text viewer, I can find the last empty line. How can I configure my vim to show the empty line?
The way Vim shows \n / 0x0a at the end of the file is that it opens the file without complaining about [noeol] when :editing the file (in a kind of "reverse logic" from what you expect). Vim's (and Unix) philosophy is that the trailing newline should be there. This can be confusing when one is used to other editors or predominantly works on MS Windows.
There's a lot of discussion and questions about this (e.g. here); as this is unlikely to change, get used to it.
I'm reviewing some logs with Java exception spam. The spam is getting is making it hard to see the other errors.
Is is possible in vim to select a block of text, using visual mode. Delete that block every place it occurs in the file.
If vim can't do it, I know silly question, vim can do everything. What other Unix tools might do it?
Sounds like you are looking for the :global command
:g/pattern/d
The :global command takes the form :g/{pat}/{cmd}. Read it as: run command, {cmd}, on every line matching pattern, {pat}.
You can even supply a range to the :delete (:d for short) command. examples:
:,+3d
:,/end_pattern/d
Put this togehter with the :global command and you can accomplish a bunch. e.g. :g/pat/,/end_pat/d
For more help see:
:h :g
:h :d
:h :range
Vim
To delete all matching lines:
:g/regex/d
To only delete the matches themselves:
:%s/regex//g
In either case, you can copy the visual selection to the command line by yanking it and then inserting it with <C-r>". For example, if your cursor (|) is positioned as follows:
hello wo|rld
Then you can select world with viw, yank the selection with y, and then :g/<C-r>"/d.
sed
To delete all matching lines:
$ sed '/regex/d' file
To only delete the matches themselves:
$ sed 's/regex//g' file
grep
To delete all matching lines:
$ grep -v 'regex' file
grep only operates line-wise, so it's not possible to only delete matches within lines.
you can try this in vim
:g/yourText/ d
Based on our discussion in the comments, I guess a "block" means several complete lines. If the first and last lines are distinctive, then the method you gave in the comments should work. (By "distinctive" I mean that there is no danger that these lines occur anywhere else in your log file.)
For simplifications, I would use "ay$ to yank the first line into register a and "by$ to yank the last line into register b instead of using Visual mode. (I was going to suggest "ayy and "byy, but that wold capture the newlines)
To be on the safe side, I would anchor the patterns: /^{text}$/ just in case the log file contains a line like "Note that {text} marks the start of the Java exception." On the command line, I would use <C-R>a and <C-R>b to paste in the contents of the two registers, as you suggested.
:g/^<C-R>a$/,/^<C-R>b$/d
What if the yanked text includes characters with special meaning for search patterns? To be on the really safe side, I would use the \V (very non-magic) modifier and escape any slashes and backslashes:
:g/\V\^<C-R>=escape(#a, '/\')<CR>\$/,/\V\^<C-R>=escape(#b, '/\')<CR>\$/d
Note that <C-R>= puts you on a fresh command line, and you return to the main one with <CR>.
It is too bad that \V was not available when matchit was written. It has to deal with text from the buffer in a search pattern, much like this.
I work with Wordpress a lot, and sometimes I changed Wordpress core files temporarily in order to understand what is going on, especially when debugging. Today I got a little surprise. When I was ready to commit my changes to my git repository, I noticed that git status was marking one of Wordpress files as not staged for commit. I remember I had reverted all the changes I did to that file before closing it, so I decided to use diff to see what had changed. I compared the file on my project with the file on the Wordpress copy that I keep in my downloads directory. It turns out the files differ at the very end. diff indicates that the there is a newline missing at the end of the original file:
1724c1724
< }
\ No newline at end of file
---
> }
I never even touched that line. The changes I made where somewhere in the middle of a large file. This leads me to think that vim added a newline character at the end of the file. Why would that happen?
All the answers I've seen here address the question "how could I prevent Vim from adding a newline character at the end of the file?", while the question was "Why would Vim add a new line at the end of a file?". My browser's search engine brought me here, and I didn't find the answer to that question.
It is related with how the POSIX standard defines a line (see Why should files end with a newline?). So, basically, a line is:
3.206 Line
A sequence of zero or more non- <newline> characters plus a terminating <newline> character.
And, therefore, they all need to end with a newline character. That's why Vim always adds a newline by default (because, according to POSIX, it should always be there).
It is not the only editor doing that. Gedit, the default text editor in GNOME, does the same exact thing.
Edit
Many other tools also expect that newline character. See for example:
How wc expects it.
GCC warns about it.
Also, you may be interested in: Vim show newline at the end of file.
Because vim is a text editor, it can sometimes "clean up" files for you. See http://vimhelp.appspot.com/vim_faq.txt.html#faq-5.4 for details on how to write without the ending newline, paraphrased below:
How do I write a file without the line feed (EOL) at the end of the file?
You can turn off the eol option and turn on the binary option to write a file without the EOL at the end of the file:
:set binary
:set noeol
:w
Alternatively, you can use:
:set noeol
:w ++bin
Adding a newline is the default behavior for Vim. If you don't need it, then use this solution: VIM Disable Automatic Newline At End Of File
To disable, add this to your .vimrc
set fileformats+=dos
You can put the following line into your .vimrc
autocmd FileType php setlocal noeol binary
Which should do the trick, but actually your approach is somewhat wrong. First of all php won't mind that ending at all and secondly if you don't want to save your changes don't press u or worse manually try to recreate the state of the file, but just quit without saving q!. If you left the editor and saved for some reason, try git checkout <file>
3.206 Line
A sequence of zero or more non- characters plus a terminating character.
Interestingly, vim will allow you to open a new file, write the file, and the file will be zero bytes. If you open a new file and append a line using o then write the file it will be two characters long. If you open said file back up and delete the second line dd and write the file it will be one byte long. Open the file back up and delete the only line remaining and write the file it will be zero bytes. So vim will let you write a zero byte file only as long as it is completely empty. Seems to defy the posix definition above. I guess...
The answer to this must be somewhere but I'm not finding it -- can anyone help me understand why in Gedit, if I have a page of code there is no extra trailing blank line, but then when I do a file comparison for my svn commit it shows an extra line being added at the end of the file?
I have a feeling that Gedit is automatically adding an ending line break. But why, I have no idea...
Reality finally won and it's been fixed, but the broken behavior is still the default; enable the WYSIWYG behavior in a terminal with
gsettings set org.gnome.gedit.preferences.editor ensure-trailing-newline false
It's a feature. I don't think it can easily be disabled.
this is intentional: text files should always be terminated by \n, otherwise
tools like 'cat', 'sed' etc may have problems. However there is no reason to
always show an empty line at the bottom of the text view, that's why we do not
show the last \n
paolo borelli [gedit developer]
Some editors (I'm unfamiliar with Gedit specifically) will try to ensure that a file always ends with a newline character. Other editors, like perhaps the one that you originally created the file with, will allow you to end a file without a final newline character.
Try the Whitespace Remover plugin.