64Gbyte flash memory - hot stuff, unfortunately

Notepad uses CRLF line endings. AFAIK, vi uses LF only. How do you deal with that?

When using Windows to edit Unix files I usually use Wordpad since it accepts existing files with LF line ends.

I hope you meant Notepad++ editor there, and not the Microsoft toy.

---druck

A team usually has a set style of how things ought to be done.

So of you need to set it manually, you only need to do it once. What is so bad about a comment as the first line of the file? If the source is to be shared or to be reused by yourself some time later a few explanations there won't come amiss anyway.

Geany will do whatever you want, allows multiple files to be open, and even has a sort of method of invoking the complier from it.

AND its cross platform. Runs on winders.

Not sure about Macs.

In contrast that's my favourite solution because it can be presented with any tab settings and still align correctly. OTOH mixed spaces and tabs for indentation is guaranteed to be a mess if the tab settings aren't what you expect. Using only spaces works but is inflexible.

... but that's a one line fix in vi/vim: 1,$s/\r// Depends. Its simple for Java because all Java programs, including the compiler, don't care whether the linebreak is CR, LF or CRLF. IIRC ftp will do that conversion if you use ASCII mode for the transfer.

Otherwise I just run transferred the files through unix2dos or dos2unix in the Linux side of the transfer.

Sure, but who wants to do that each time!

Similarly, I find C compilers, make, and python don't worry about line endings so all builds are easy.

OK. It's a pity Notepad doesn't handle LF-only endings. Would save the hassle. But Wordpad does.

Indeed, and doing something like the search-and-destroy mission on all tabs in programs is usually quite a good way of getting slung off the team.

Granted its better than doing it with editor configuration because it does at least stay with the file. I've only see that done once in what |I suppose you could describe as a proto-IDE, and from memory contained rather more than just a tab setting line - it also contained the sort of compilation directives that C programmers expect to find in a Makefile.

Try

:1,$s/$/\r\n/

(hmm. Is $ the regex for end of line? I hate regex)

I don't care about that. Yet.

I zip files being transferred between machines. This ensures that time stamps are preserved (and, as a bonus, checksums the individual files). Zip also has options to fix up the line endings when going from machine to machine.

Interesting. My way gives me native line endings on both machines, though.

Yes, but I already know that won't work. I tried a variation earlier, editing a test file line this:

with them command in vim:

:1,$s/..$//

This converted the file to this:

IOW, it removed the last two characters in each line while leaving the newline (CRLF) untouched. I think this shows that $ doesn't represent a character, just the position at the end of the line. IOW $ isn't matchable simply because it represents the dimensionless space between the last character in the line and the line termination character(s) and that similarly ^ represents the dimensionless space between the preceding line termination character(s), if any, and the first character in the line. This would certainly fit the way in which ^ and $ work in a regex.

So, as I haven't been able to work out how the escaped characters \r and \n should be represented in a vim regex, I withdraw the suggestion that vim can fix the newline representation because I think its behaviour has changed (see below).

Other sidelights: I built the example text by running:

printf "Junk line\r\n" >x.txt

and than using vim to Append and another. to the first line. I was interested to see that this means that the latest vim accepts both LF and CRLF as valid line terminators and that it uses whatever newline symbol that was in the file as the terminator for any other lines the user adds.

This makes a change in vim's (default) behaviour: I distinctly remember that earlier (much earlier - 2005) versions of vim showed a symbol '^M' as the last character in Windows text files and that you could use the 'colon s' command to remove it. I can't find out a lot more because the vim online help isn't installed and I can't find/don't recognise the package containing it: I use vim so little that I'm not about to pull in all its packages 'just in case'.

Yes but these are bare bones, fallback, better than nothing editors. The first thing to do real work with should be be install a decent one. My personal choice is Notetab from Fookes in Switzerland, but there are dozens out there, all better than the minimal OS default.

For linux with a gui, frankly it takes a lot to beat Geany for programming work.

Without a GUI I'd probably use JOE if I had a lot to do, or simply learn vi for the sake of sheer ubiquity for small editing jobs

I learnt vi years ago simply because it was the only editor I could guarantee being present on any Unix machine I was called upon to write code on, or administer.

Its horrible, but it can be made to work.

I've been using vi for so long that any other editor just slows me down (my last serious attempt to use something different was Brief under MSDOS, I gave up on when I realised that I kept launching vi by reflex), with vi I don't have to think about the mechanics of editing anymore. The best editor is always the one you know best, just like the best layout style is the one chosen by the team you're working in.

Ah, OK. Moving files is more work than I had in mind but I take your point about using zip options.

I have my Unix systems present Windows shares so that I can edit files on a Unix box just as if they were on my Windows machines. No file transfers needed.

On Unix there are various ways to adjust the line endings. On Windows, you can replace LF with CRLF by copy from Wordpad and paste to Notepad.

I heartily recommend Notepad++ for code editing on Windows.

Apart from all the other neat things it does, it handles CR/LR/CR+LF endings, and can create an output file with any of those.

Geany is an editor with pretensions to being an IDE, but it's not actually an IDE, and won't cut the mustard if what you want is actually an IDE. As an editor it's pretty good ... but so is the Gnome text editor, gedit (or "pluma" as Mate calls it on this system).

The great advantage of vi is that it's fairly lightweight, and that it (or one of its clones) can more-or-less be guaranteed to be supported on almost any system, so for those little config-file edits you may find yourself having to do outside your favourite GUI it's invaluable. I wouldn't attempt to do anything sophisticated with it (even though one can) but it's my tool of choice at a command prompt.

A fair and balanced summary that I totally agree with.