New to Oracle...
I have a bunch of SQL scripts from SQL Server that I want to edit into Oracle. I load these notepad-capable ASCII text files (ex: myscript.sql) into SQL Developer. When I open it, SQL Developer adds an extra line break between every line I had in the ascii text file. Annoying, but I can deal with that. I soldier on. I edit and change syntax. I run it. It works. I save. I'm happy so far. Feeling good.
But...
Now when I try to open myscript.sql in Notepad, line breaks are gone... there is a blank between every character in a word... it's a mess.
What the heck happened? And how do I make it stop? I know I'm old school, but I like to edit the format of my scripts myself... I want them in ascii text so that I can use a bulk file editor to change things...
I have googled this for a couple hours and have found countless pages regarding saving the OUTPUT of a script as text, but nothing about saving a SQL Developer script as plain text.
Welcome to the world of UNIX vs Windows/DOS line ending differences.
I would recommend using a better editor than Notepad. A modern code editing program will automatically handle the conversion and display.
http://www.cs.toronto.edu/~krueger/csc209h/tut/line-endings.html
So I still don't know how a couple of my scripts got so mangled up, because I can't recreate the issue. Other scripts are editing and saving just fine.
But I did figure out how to fix the couple scripts that did get hosed up.
I loaded Notepad++ for Windows. I opened the offending script, which shows a bunch of [NUL] all over the place. I was able to use the Searce/Replace function in 'extended mode' to search for \x00 (aka null) and replace it with nothing.
Next was the annoyance with line breaks (new line) versus "carriage return plus new line". I was able to use extended search and replace to replace \n with \r\n .
This now got me a file that I could edit in 'regular' notepad. I still don't know where the extra line breaks came into play, but I was able to spin through the file and remove the extra blank lines.
So all is well with the universe again. I got my couple of mangled scripts back in order, and others seem to behave properly now.
Thanks to all for the help. This site has been invaluable to me.
Related
I have noticed that some .Net code committed by a new contracting team has strange line endings. When I do a hex dump of the files I see that each line ends with 2 carriage returns (0d) and 1 line feed (0a).
When viewed in Visual Studio it looks like every code line has an empty line after it, which looks very odd.
What can cause this? It it some strange IDE? Could it be caused by Perforce? (I got the code out by syncing a Perforce workspace).
The only time I've ever seen non-standard line endings before is when people copy/paste code from a web page, email, or chat window. Could that be the cause?
If they submitted Windows-style (CRLF) line endings but used the unix (LF) LineEnd setting in their client workspaces, then the files would have an extra CR as part of each line, and a Windows machine would sync them down as CRCRLF. That's the most likely explanation for what you're seeing.
The ideal way to fix this is just for everyone to use a LineEnd that matches their environment (usually the default of local works just fine for this), but if someone needs to use a mix of tools/platforms within a single workspace, switching to the share LineEnd option will force everything to be normalized on submit by stripping all the CRs. (This also makes it impossible to submit text files with actual CR characters, but that's usually not a big deal -- for files where you don't want any sort of transformation to occur, use the binary filetype.)
I'm not sure if this question is appropriate here but I have nowhere else to ask. I recently started to typeset some 'mathsy' stuff using Latex and it became a hobby for me. I've been using TeXnicCenter for this, but feeling that I've got familiar with Latex language, I decieded to improve 'efficiency' of typesetting by changing the editor.
So I decided to use Vim (latest version, 7.4) with Suite-Latex. I've just installed Vim and Suite-Latex, following exactly what was instructed here. I made every necessary changes mentioned here, and it seemed to me that installation was successful (I got what was expected on Step 4)
Then I started to work through this tutorial and everything went fine until this section.
When I press F9 for autoreference, I see that Vim is working on something for split seconds and red error message refering to "can't find [some file name]" in my user/appdata/local/temp directory. The "file name" changes every time I do this (so its kind of temporary file as its directory suggests?). And then it produces a new window with title __ OUTLINE __ where 2 empty lines are showing up.
If I press n (in the new window described above) error message saying "E486: Pattern not found: rf" pops up and pressing j results in going down one row. If I press enter key, message ":call Tex_FinishOutlineCompletion()" pops up.
More frustratingly, if I try to compile a file by entering command \ll, a new window pops up where there are two lines saying:
1.ll I can't find file `newfile.tex'. newfile.tex
2.ll Emergency stop
and below these is a message saying
[Quickfix list]: latex -interaction=nonstopmode -file-line-error-style newfile.tex
So I thought it maybe is something to do with VIM not being able to find files in my computer (so something wrong with grep?), and I tried to resolve it by downloading a software called "cygwin" on which developers said their tests were successful, but it changed nothing.
But I think the two problems are related.
As it is, I am completely newbie in this type of editing environment (or any kind of programming) but I really would like to learn some Vim seeing how efficient it is in typesetting etc. Sorry for not being a pro at typing codes here. Thanks for reading!
I believe you need a latex compiler---I've had this issue and well, one thing that's left out of the conversation a lot is the compiler (pdflatex, latexmk, etc). As of now, you should download a compiler since vim-latex (latex-suite) doesn't actually come with a compiler (that I know of) and it's just a plug in with some cool stuff in it, but not what you need to make a file.pdf out of your file.tex.
It happened to me before. I found out that this problem may happen when you have special characters (such as white space and other symbols) in your file name or folder path. Try again with file name and path only in English letters.
Good day,
I am a CNC program not a computer programer. I am using CAM software to make cutting programs for our CNC router. The router is a bit old and can only take files 200-300 kb big. We are doing carvings that require 1-2 megs text files. I am using a program called GSplit ( http://www.gdgsoft.com/gsplit/ ) to divvy up the text file. It generates 10-25+ files with a custom header that our machine can read. All the files are great and it works, but I have to manually add the closing lines/footer to each file. The files that are created and used are normal .txt files but with a specific extension, .ANC.
Is there any way to automate this process of opening each individual file, scrolling to the end and copy/pasting the same 1-2 lines of code? The files are NAME[number].ANC in a contained folder. Would it be possible to just direct to a folder and say "add this 'text' to every file in this folder"?
Thanks for your time.
What OS are you using? Using Unix you can do a simple script on command line. If you are in the directory with the specific files simply execute:
for file in *; do echo "APPEND THIS" >> $file; done
If you are running Windows you should be able to do the same using cygwin (probably you could also use the power shell, but I don't know anything about the that)
I found a program Notepad++ (apparently the last person to find it...). USed the find/replace files option. A regular expression(note sure exactly what these are but I'm sure you guys do) "\s+\z" as to what to look for. It finds the last space or whatever at the end of all the files and then adds the code I need. Easy, free, and I don't need to write any computer code. Thanks for the attempt to help me Dirkk! :)
I have a delphi prog that reads from thousands of .txt script files that I have created over some years. I had to do some mass changes so used a search and replace program which in itself took a good few hours! The problem is now the top line of all the txt files seems to be messed up somehow - to me it looks fine however the delphi program doesn't read it and TortoiseSVN records it as a changed line!!
What on earth has happened and how might I resolve it? So far I'm having to delete all the files and remake them. Deleting the line and rewriting doesn't work - even Crtl+A and pasting the old file contents doesn't work! Its as if the header is corrupt?
Could it be a problem with end lines? (windows/UNIX/Mac are different eg \n or \n\r ) use an editor able to show special characters. I think you can with tortoise diff, switching the right option. Else, try with notepad++, for example
Sometimes I work with a file that contains source code, columns, plain text, sometimes all 3. It looks great on the screen. However, when I send it to a printer, it comes out a mess: columns/tables are misalignment, code looks like a spaghetti, etc.
I use Vim (7.2). How do I reformat the file to please the printer?
Perhaps I should shorten the length of a line?
How do you send it to printer? Try :hardcopy command.
You can also lookup printing-related options printfont, printdevice, printoptions, etc.
See also printoptions and others on vimdoc.sourceforge.net
It's not a pure-Vim solution, but I've had good experiences with GNU a2ps for converting (relatively) poorly formatted text documents (a couple Project Gutenberg titles, to be specific) to a nice, printable pdf/postscript file.
If you aren't worried about having to have a one-step process with no intermediary between Vim and the printer, here is a fairly flexible strategy.
If you have a dark background in Vim with light foreground but would like to print black-on-white since white-on-black is great for terminals but not so great for printed media, try colorscheme shine. (Another nice colorscheme for this is Hemisu, which is superior to Shine for printing diffs.)
Use :TOhtml to convert the document to HTML.
Save the file and open it in your browser.
Open print preview from your browser and set up the window appropriately.
For example, I just printed a nearly 200 column file brought in from Vim this way, and it worked out fine (both in the sense of "well" and in the sense of "small print" :) because I was able to use Firefox's print preview to set the file to print in landscape mode.
Print the file from your browser.
I agree there is a problem. yim has 'formatoptions' to 'wrap' lines together the way you want and break lines at appropriate places ('linebreak', 'breakat') which would give you an elementary wysiwyg word-processing capability, except that it only works on the display and has no effect when sent off to print.