I am having a problem with text files on my work computer. They are regularly being corrupted and I can't tell if it is an OS problem (Windows 7) or problem with my text editor (Sublime Text 2), or both. Here's what's happening:
I am working on a coding project. I'll write some code, test it out, then save it. It may look something like this (I'm writing in Ruby):
class MyClass
def my_method
end
end
Then later, maybe the same day or the following day, I will attempt to run my code and will get a syntax error or invalid character error or unterminated string error, etc. I trace the error and find that one of my files will look like this:
class MyClass
def my_method
§`½š—ÍÚ
So I'll fix it and close the code blocks, and then run again. Often, I will get a second or third similar error and will have to trace out all of the files where this happens and fix the code.
The 'corruption' always occurs at the end of the file, so usually it is destroying some end statement for a class/module definition, but it also occurs at the end of scripts in the middle of print or puts statements, etc., wreaking a more general brand of havoc. (That is to say, it doesn't seem to only be happening to the keyword end.) The invalid characters that appear are not always the same characters, and so far I have not noticed any repeats. The problem is destroying about 5-10 characters at the end of the file, including new lines (like my example above).
Also, it doesn't seem to be occurring in specific files. But I'm not sure if it is limited to the files in the folder(s) I have open in Sublime text or if it is happening to any files that I open for editing with Sublime text. 99% of the time I'm working in one directory which I have open in Sublime text for my project. I don't know if the problem would occur with another text editor (i.e. Notepad) because I haven't taken significant time to test it out (i.e. coding for a couple of days strictly in Notepad).
The problem occurs in files that are currently (at runtime) open in Sublime Text and have remained open since I last worked on them and saved, and also occurs in files that have been closed since their last use.
This is very frustrating as I feel like I can't trust that my work will be ready to go when I need it, and I have to spend extra time a couple of times a day fixing the files. I have searched for a solution and so far haven't hit on anything that seems to solve or even describe my problem - though I may not be using the best keywords.
Any help is appreciated! Thanks!
Related
I have an issue, I wouldn't say it's a problem at the moment, but I can see how it could turn into one in the future.
I'm following some tutorials from Ruby, so I have a folder with a bunch of different files. In one of them, I was studying Hashes, and they showed that I could name its keys like :key. No problem so far.
The issue came when I was studying Classes and I had to declare the class attributes, IntelliSense (I guess, maybe it is another extension) would recommend code completion with the keys I declared in that Hashes ruby file.
So I tested some stuff and:
It wasn't unique to that file (of course).
It's not just in hashes, it will recommend any type of :attribute I create. Whether it is classes or hashes (which is what I have tried so far), it doesn't matter.
It isn't unique to that folder. If I have the files in different folders, with different depths let's say, it will still appear.
The only way I found to get rid of that was to erase the file, and that's no solution at all.
I guess my precise question is: How can I disable that code completion characteristic?
You can ignore file or folder in code completion by adding it to files.watcherExclude setting.
Files must be closed in editor: if ignored file is open, it will still be used for autocomplete.
I am using fastlane and snapshot to create screenshots automatically. To facilitate this I need to copy data into the app. In this case a series of folders and documents from one folder into another within a .app container.
So far the Documents folder is being created but no files are ever copied into it. At this point I’m not sure if I’m suppling the path incorrectly or what else I might be doing wrong to lead to this. It may be simply that I’ve got the wrong code to do that since I’m not that familiar with Ruby.
Any suggestions would be greatly appreciated, so tell me, what am I missing?
example_files = "./sample_data/Documents"
folder_name = "Documents"
setup_for_device_change do |lang, device|
app_path = "/tmp/snapshot/build/SyncSpace.app/"
FileUtils.mkdir_p(File.join(app_path, folder_name))
Dir.glob(File.join(example_files, '*')).each do |example_path|
FileUtils.cp_r(example_path, File.join(app_path, folder_name)) rescue nil # in case the file already exists
end
end
Update -
In the end my problem is that the path I’m using doesn’t work correctly for the files I want to transfer. When I give it a full path from the root level to the folder I need it works. Trying to use a shorter path with just the additional folders over the working directory fails.
So as a follow up, when my working directory is .../fastlane and my data is in .../fastlane/sample_data/Documents then why doesn’t just using ./sample_data/Documents work?
Don't use rescue nil. Ever, or at least until you're very aware of what your code could be doing and why you would want to use that. Instead use the normal form of:
begin
do_something
rescue TheExactExceptionYouWantToHandle => e
# handle the exception
end
That way you handle what you expect and blow up if it's something you didn't expect.
One of my programming mentors years ago told me
Never test for an error condition you don't know how to handle.
On the surface that sounds silly but experience teaches us we can get into situations where the program does the wrong thing trying to do the right thing. It's better to crash fast and safely and spew out an error, than to drag it out and damage things trying to recover or silently cover the error. Debugging a program that's rescuing improperly can be a major pain and a trailing rescue is a common culprit.
I need to quickly write a simple GUI over a command line application. Two steps are required:
Specify an input file path,
Specify an output file path (non existing)
I found out a previous post, however trying to get the above (1) to work seems like an insane task.
Indeed BrowseForFolder seems to only work in some weird cases, you can use BIF_BROWSEINCLUDEFILES for only *.pdf and/or *.txt (trial and errors). I can get an error if I select a *.dll and/or a *.jpg (don't ask).
So instead, I gave up this approach and followed another one, in this case (objIE.Document.all.FileSelect), only the name of the selected file is returned the path seems to be always set to "c:/fakepath" for some reason. So again I am missing the full path to be able to pass that to the command line app.
Is there any sane way (<10 lines of codes) to get (1) and (2) working on Win7/64bits (VBS, HTA...)?
Don't know if people are still interested in the BrowseForFolder file selection issue, but here's what I've found.
I had the same issue selecting files with BrowseForFolder using &H4000 / BIF_BROWSEINCLUDEFILES. I could get a return with .docx but not .doc files and as you say .pdf files.
For me .txt wouldn't return anything, as didn't WMI Backup .rec files that I needed for a script I'm writing, resulting in this error information:-
Error: Unspecified error
Code: 80004005
Source: (null)
After looking at other solutions I came back to this one as my preferred choice, plus it was doing my head in that it didn't want to work. So at the bitter end it seems to be this easy.
To get my .rec files recognized I add this to the registry:-
[HKEY_CLASSES_ROOT\.rec]
#="WMI.Backup"
[HKEY_CLASSES_ROOT\WMI.Backup]
#="WMI Backup"
"BrowseInPlace"="1"
To get .txt files recognized I add this to the registry:-
[HKEY_CLASSES_ROOT\txtfile]
"BrowseInPlace"="1"
So "BrowseInPlace"="1" seems to be the nugget.
Seems so unbelievably easy that I'm sure this solution is out there somewhere but I never came across it so thought I'd put it online.
I would be interested to find that it works for others as I fear that this issue may of sent me mad, still can't believe it seems to work.
Hope this helps.
Here are 3 different ways to do what you want:
http://www.robvanderwoude.com/vbstech_ui_fileopen.php
Anytime I open up the code editor in Visual Studio, there is always an empty new line at the end of generated codes. I usually delete them since they seem irrelevant to me. However, recently I read code at Github which said:
\ No newline at end of file
This was the last line. Now I'm thinking those empty new lines at the end of source codes do have some relevance. But what do they mean? Do they provide any performance boost?
Two things make me prefer having a newline at the end of files:
Code reviews are slightly easier when looking at diffs that occur at the end of the file (i.e., if a line is added at the end of the file, it appears that the previous line changed, when it only gained a newline)
Going to the end of the file (Ctrl+End in Windows) always puts me at the same column and not in some unexpected position out to the right
Pretty much the only difference it makes is that if you have a file with no newline - like this:
blah\n
bleh (no newline)
When you modify it to be:
blah\n
bleh\n
foo (no newline)
Then according to the diff, you modified 2 lines - one with content, the other one with newline... which is not what you wanted probably. Then again, in reality it doesn't matter that much which way you choose. If you include newlines, your diffs will be a little bit cleaner.
It also makes difference for some preprocessors as mentioned in other answer - but that depends on what language you use.
Of course it makes no performance difference at all.
No, it makes no difference whatsoever.
Some coding conventions say it's good to have a final newline, some say it's good not to.
Read more about new line in C++ here: "No newline at end of file" compiler warning
I suppose both Visual Studio and Git do it mostly for being coherent with the convention.
I've sort of got Fsi.exe working as expected on a Mac OS X (Snow Leopard) with Mono. I just noticed a little bit of odd behavior with cut and paste and I was wondering if anyone had seen this.
I've defined the following alias for fsi:
alias fsi='ledit mono ~/FSharp-1.9.7.8_2/bin/fsi.exe --gui-'
ledit is an Ocaml utility that seems to make the keyboard input work correctly--without it, fsi just never seems to read the input. To see what I mean, try Fsi.exe without ledit and enter
let square x = x * x;;
without ledit, it just never seems to parse the input. I mean it never comes back to the ">" prompt after you enter the string. With ledit, the ">" prompt comes back immediately.
Of course the --gui- keeps fsi from displaying all the messages about the lack of System.Drawing etc.
So this all seems to work. The oddity is when I copy and paste code into the FSI, certain characters seem to repeat over and over again. It seems to be conditioned by the size of the buffer I'm pasting in. When I paste small snippets there seems to be no problem. But if I paste in larger chunks, there's this oddity.
If I do the following:
open System.IO;;
then paste this code snippet in FSI:
let buildFileList basepath filespec =
seq {
yield! Directory.GetFiles(basepath, filespec, System.IO.SearchOption.AllDirectories)
}
That works fine. But if I copy and paste in a bigger chunk of code ending with that, it repeats the portion up to the yield! over and over again. It seems to be somehow related to fsi attempting to parse the code as it's being pasted in because the same code pasted in will cause parsing errors (like FS0010) when it's pasted at the end of a long chunk but won't cause an error when it's isolated.
If I #load the entire file, it parses correctly as well so I think my code is ok.
This oddity in copy/paste seems to happen both with and without ledit on the command line. I don't mind researching this issue myself but I'm kind of stumped about where I should proceed with this. I'm copying from GVim if that makes a difference but anyone have any idea where I might proceed in trying to isolate the cause of this odd behavior? I suppose I could take the extra step of copying into TextEdit first and then trying to copy into fsi but any ideas beyond that?
To bottom line this: has anyone else seen this odd behavior? If not, any suggestions about how I might proceed in trying to isolate the cause of this odd behavior?
When I encountered this behavior on my Mac, I went a different route. Instead of using ledit, I employed fsi's --readline option, seen below (where ${FSHARP} is my install path).
mono ${FSHARP}/fsi.exe --readline+ --gui-
You may also want to check your terminal settings. My terminal (for example) is declared as xterm-color, and I have unchecked delete sends CTRL-H. I think those are the only relevant settings, but don't hold me to it.