I'm very very new to Vim. I've been using it for 2 days now (out of the womb new), and I've been having some problems navigating a certain Ruby file of mine without it crashing.
Before I get to the error message, here are the steps I did to reproduce the problem...
First I opened up the file as read-only with the :edit command
If the file has no syntax coloring turn it on :syntax on. (For some reason it doesn't crash without it.)
Navigate up and down the file with j and k (reproduces the crash quicker when you set the cursor in a position where it would
scatter the cursor more. For ex, the end of a line)
At first I thought something was wrong with my .rb file, but I was able to reproduce the same crash with the tk.rb file as well which is located in lib\ruby\2.2.0\ folder. It took some more time to do it with tk.rb since the comments in the code make it harder to crash. (I recommend to try it on files with lots of lines like this).
Here's a gif of me reproducing the problem and the file I was navigating through to reproduce the crash...
http://puu.sh/jHXXG/14d2cf6460.gif
http://puu.sh/jHVG2/fdae9e38fa.rar
I'm using Vim 7.4 and windows 10. If any more information is needed please ask in the comments. I would like to know how to resolve this. Vim looks like a really nice program. However, if its gonna break itself and my heart from navigating with hjkl. I might have to travel back to the fork in the road, and walk down the emacs path.
As it was indicated on the comments, you should open a bug report if the problem is indeed in Vim.
But first you should try the following:
Ensure you are using a version with the latest patches; there were some reports similar to the problem you are describing, and there are chances that it is already solved.
Check if any setting/plugin is triggering the problem, beyond the :syntax. The procedure at Vim-FAQ 2.5 can be helpful. Some relevant parts follows:
2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a
problem with my setup or with Vim? / Have I found a bug in Vim?
First, you need to find out, whether the error is in the actual
runtime files or any plugin that is distributed with Vim or whether it
is a simple side effect of any configuration option from your .vimrc
or .gvimrc. So first, start vim like this:
vim -u NONE -U NONE -N -i NONE
this starts Vim in nocompatible mode (-N), without reading your
viminfo file (-i NONE), without reading any configuration file (-u
NONE for not reading .vimrc file and -U NONE for not reading a .gvimrc
file) or even plugin.
If the error does not occur when starting Vim this way, then the
problem is either related to some plugin of yours or some setting in
one of your local setup files. You need to find out, what triggers the
error, you try starting Vim this way:
vim -u NONE -U NONE -N
If the error occurs, the problem is your .viminfo file. Simply delete
the viminfo file then. If the error does not occur, try:
vim -u ~/.vimrc --noplugin -N -i NONE
This will simply use your .vimrc as configuration file, but not load
any plugins. If the error occurs this time, the error is possibly
caused by some configuration option inside your .vimrc file. Depending
on the length of your vimrc file, it can be quite hard to trace the
origin within that file.
The best way is to add :finish command in the middle of your .vimrc.
Then restart again using the same command line. If the error still
occurs, the bug must be caused because of a setting in the first half
of your .vimrc. If it doesn't happen, the problematic setting must be
in the second half of your .vimrc. So move the :finish command to the
middle of that half, of which you know that triggers the error and
move your way along, until you find the problematic option. If your
.vimrc is 350 lines long, you need at a maximum 9 tries to find the
offending line (in practise, this can often be further reduced, since
often lines depend on each other).
If the problem does not occur, when only loading your .vimrc file, the
error must be caused by a plugin or another runtime file (indent
autoload or syntax script). Check the output of the :scriptnames
command to see what files have been loaded and for each one try to
disable each one by one and see which one triggers the bug. Often
files that are loaded by vim, have a simple configuration variable to
disable them, but you need to check inside each file separately.
If the previous steps doesn't solved the problem you could try checking similar bug reports and try maybe some of the patches which still weren't merged:
long line with syntax highlighting crashes vim w/ 100% CPU
Segfault on 7.4 caused by syntax :on with Ruby file
vim_dev search
Related
I had MAFFT running fine on my computer (MacOS 11.6), until I downloaded PRANK (a probabilistic multiple alignment program distributed by Wasabi) which also runs on its own MAFFT Unix executable file. The original MAFFT is located in the directory /usr/local/bin, and PRANK and its associated files live in another directory called /programs/prank/bin, both of which are in my $PATH variable, with the /usr/local/bin directory having priority. Now, not only is the MAFFT within PRANK giving the error below when I type the ‘prank’ command, but I also get this error when trying to use my original version of MAFFT by typing ‘mafft.’ Deleting my original MAFFT and only using the PRANK version does not fix things. If I fully delete PRANK and MAFFT and redownload MAFFT alone, I can get it to work again.
I’ve tried all the steps listed in the error output below. My $MAFFT_BINARIES file appears to be empty or nonexistent, and there is no MAFFT_BINARIES line in my .bash_profile or any of the other settings files listed.
Does anyone have any insight into what may be causing this or how I should go about fixing it? Has anyone experienced the same conflicts with PRANK? Please let me know if I can provide any additional information about my system or set-up that would be helpful. As you might be able to guess, I'm not particularly experienced in this level of digging around in the guts of my file directories, but I know just enough to get myself into trouble...
Error: Initial alignment with Mafft failed. The output generated was:
v7.490 != v7.450 (2019/Aug/23)
There is a problem in the configuration of your shell.
Check the MAFFT_BINARIES environmental variable by
$ echo $MAFFT_BINARIES
This variable must be *unset*, unless you have installed MAFFT
with a special configuration. To unset this variable, type
$ unset MAFFT_BINARIES
or
% unsetenv MAFFT_BINARIES
Then retry
$ mafft input > output
To keep this change permanently, edit setting files
(.bash_profile, .profile, .cshrc, etc) in your home directory
to delete the MAFFT_BINARIES line.
On MacOSX, also edit or remove the .MacOSX/environment.plist file
and then re-login (MacOSX 10.6) or reboot (MacOSX 10.7).
Please send a problem report to katoh#ifrec.osaka-u.ac.jp,
if this problem remains.
I accidentally discovered that I can't edit any files that end in .lrp using vi. This is the case on OS X (High Sierra), on Ubuntu 16.04 as well as on Debian. Haven't tried any others, but this seems to occur on all of my colleagues machines as well. It's not a .vimrc setting by the looks of it either.
To reproduce, simply try to create or edit any arbitrary filename in vi, the filename needs to end in .lrp.
vi starts, but then has a red bar at the bottom stating:
***error*** (tar#Browse) File not readable<...path to file...>
Can anyone shed some light on this highly confusing matter?
Edit 1: I just wanted to add that this really sucks if you're stuck with a software package that has config files ending in .lrp you need to frequently edit manually. I can work around it creating a symlink, but that's not a nice option.
Edit 2: went through the vim sourcecode at github and stumbled across one line in this file runtime/autoload/tar.vim that declares .lrp files to be tar files... I've been around the block a few times yet never even heard of this. Perhaps an autoload option that can be disabled? my vimrc doesn't load any tar extensions or anything to would point that way.
Vim believes this file ending is a package of "Linux Router Project", which is compressed. Vim will try to open it with tar.
If you don't need this feature, you can disable this plugin completely.
let g:loaded_tarPlugin = 1
let g:loaded_tar = 1
Or open the file without autocommands
:noau e file-name.lrp
enter image description here
PLEASE HELP! I can't seem to run my file. I've compiled it so it should run shouldn't it?
It also happens to my other files and I can't seem to fix it.
Ok, so a quick point of notice:
It is usually appreciated if you post your code directly in your question and use the code markup for that. It makes it easier to answer your question and prevents the image from turning into a dead-link at one point in time.
Then, regarding your code: it seems your Topic3ex1.c still has some errors, it always helps to fix them first. Maybe the errors are preventing Topic3ex1 (which I believe you have selected as the output file with the -o option? I am not familiar with gcc's syntax.) from being formed. Check if the file exist first by executing ls -a from the command line.
If you get a message saying "No such file or directory" while it is indeed there, this is usually caused by a lack of user rights. Try executing chmod u+x Topic3ex1.c and then run your command again. This will give your current user the right to execute the file (read up on chmod if you do not know it already, you will need it often).
Final question: is Topic3ex1 supposed to be a file or a folder? For if it is a file, then executing it like ./Topic3ex1 will only work if it is a shellscript (in that case, best rename your file to Topic3ex1.sh, its best to always mention the extension of the file). If it is a folder the ./ command won't do anything and the cd Topic3ex1 (cq. change directory-)command you where experiencing with will activate it as your working directory. If it is a file however, then the change directory command will, of course, be useless.
I set the HOME variable in /etc/launchd.conf using the following line: setenv HOME /Users/student
Now the machine wont boot at startup. I tried holding shift at startup but safe mode doesn't seem to be working. I tried holding cmd+s on startup and got into single user mode. I was able to bring up the /etc/launchd.conf file but I can not save/overwrite the existing file due to permission issues.
Is there some way to reset this file from single user mode or other to fix this? I'm open to other approaches as well. I am not a unix/linux power user by any means, fyi :)
Thank you in advance.
I'll give you two options, but first a warning: both of these involve using the command line to undo the damage, and if you do it wrong there's a possibility you'll make it even worse. A backup would've been a good idea, but it's a little late for that (well, actually, there are still ways to do it, but they also involve a risk of getting it wrong...). So whatever your do, be careful.
Option 1: use single-user mode (Command-S at startup). This will leave you running as root, which means you are not subject to normal file permissions; after remounting the startup disk for write access (mount -uw /) you should not get permissions errors. You said this didn't work; the most likely thing is that you mistyped the command (I see this happen a lot -- people either leave out the "/", or the space between "-uw" and "/"). Hint: if the mount command prints anything (other than the prompt for the next command) you typed it wrong. If that still doesn't do it, check the file's flags and metadata with ls -leO# /etc/launchd.conf and report the results.
Option 2: use recovery mode (Command-R at startup). This boots from a small hidden partition with a minimal copy of OS X. In recovery mode, pull down the Utilities menu and choose Terminal. This is actually a fair bit like single-user mode, except that the normal startup disk won't be /, it'll be /Volumes/Macintosh HD (or whatever it's named), and it'll already be mounted for write access. Since there's (probably) a space in the volume name, you'll have to quote or escape it:
$ cd "/Volumes/Macintosh HD"
$ mv launchd.conf launchd.conf-disabled
I have a very large CSV file, over 2.5GB, that, when importing into SQL Server 2005, gives an error message "Column delimiter not found" on a specific line (82,449).
The issue is with double quotes within the text for that column, in this instance, it's a note field that someone wrote "Transferred money to ""MIKE"", Thnks".
Because the file is so large, I can't open it up in Notepad++ and make the change, which brought me to find VIM.
I am very new to VIM and I reviewed the tutorial document which taught me how to change the file using 82,449 G to find the line, l over to the spot, x the double quotes.
When I save the file using :saveas c:\Test VIM\Test.csv, it seems to be a portion of the file. The original file is 2.6GB and the new saved one is 1.1GB. The original file has 9,389,222 rows and the new saved one has 3,751,878. I tried using the G command to get to the bottom of the file before saving, which increased the size quite a bit, but still didn't save the whole file; Before using G, the file was only 230 MB.
Any ideas as to why I'm not saving the entire file?
You really need to use a "stream editor", something similar to sed on Linux, that lets you pipe your text through it, without trying to keep the entire file in memory. In sed I'd do something like:
sed 's/""MIKE""/"MIKE"/' < source_file_to_read > cleaned_file_to_write
There is a sed for Windows.
As a second choice, you could use a programming language like Perl, Python or Ruby, to process the text line by line from a file, writing as it searches for the doubled-quotes, then changing the line in question, and continuing to write until the file has been completely processed.
VIM might be able to load the file, if your machine has enough free RAM, but it'll be a slow process. If it does, you can search from direct mode using:
:/""MIKE""/
and manually remove a doubled-quote, or have VIM make the change automatically using:
:%s/""MIKE""/"MIKE"/g
In either case, write, then close, the file using:
:wq
In VIM, direct mode is the normal state of the editor, and you can get to it using your ESC key.
You can also split the file into smaller more manageable chunks, and then combine it back. Here's a script in bash that can split the file into equal parts:
#!/bin/bash
fspec=the_big_file.csv
num_files=10 # how many mini-files you want
total_lines=$(cat ${fspec} | wc -l)
((lines_per_file = (total_lines+num_files-1) / num_files))
split --lines=${lines_per_file} ${fspec} part.
echo "Total Lines = ${total_lines}"
echo "Lines per file = ${lines_per_file}"
wc -l part.*
I just tested it on a 1GB file with 61151570 lines, and each resulting file was almost 100 MB
Edit:
I just realized you are on Windows, so the above may not apply. You can use a utility like simple text splitter a Windows program which does the same thing.
When you're able to open the file without errors like E342: Out of memory!, you should be able to save the complete file, too. There should at least be an error on :w, a partial save without error is a severe loss of data, and should be reported as a bug, either on the vim_dev mailing list or at http://code.google.com/p/vim/issues/list
Which exact version of Vim are you using? Using GVIM 7.3.600 (32-bit) on Windows 7/x64, I wasn't able to open a 1.9 GB file without out of memory. I was able to successfully open, edit, and save (fully!) a 3.9 GB file with the 64-bit version 7.3.000 from here. If you're not using that native 64-bit version yet, give it a try.