On Thu September 23 2004 22:53, s. keeling wrote: > Incoming from Curtis Sloan: > > I have a single text file (a .vcs from Outlook2vCal) that requires some > > modifications before importing into korganizer (apparently a bug in > > korganizer, but I couldn't find a solution in the archives upon first > > swath and I'm kind of anxious to be rid of Outlook ;-). > > > > Specifically, the DESCRIPTION section in every VEVENT needs to be edited > > such that: > > > > -every comma is escaped (strange, other nasty characters like ':' already > > are) -each additional line after the first must start with a space > > (otherwise it is ignored, don't ask me why) > > -newline/carriage return is honored (currently not -- additional lines > > are strung together... but is the newline/carriage return character > > actually there? I don't know -- how to check?) > > <snip> > > *First, make a copy of this file and work on that.*
Roger that. That's the first thing I did. :-) > All of those work well for simple content mangling. However, that bit > about "each additional line after the first must start with a space" > is non-trivial. Aye, there's the rub. > Given a better description of the problem, it's likely easy to fix. Let me try to simplify: I need to add a space to the beginning of every line in every DESCRIPTION section. However, I can't do a global replace (add a space to the beginning of _every_ line in the file) because the vCal format gets wrecked and won't import anymore. Basically, I need a programmatic way to determine the beginning and end of every DESCRIPTION section and only do the replace on those blocks of text. I can't do it manually, because there are ~650 VEVENTs. This just screams "script me!" but I don't know how to start. > vi should show you right away if the newlines are Unix newlines. If > not, you'll see ^M at the end of each line. You can use tr to remove > the ^M chars if they're there: > > tr -d '^M' < infile > outfile > > When typing in that command, type "CTRL-v CTRL-m" to get a real ^M in > there. Excellent, that's helpful (and another thing I didn't know). > So, in vi: > :%s/\,/\\,/g > > Should escape the commas (coincidentally (not), that's what you'd be > doing in sed too). You might want to fiddle with it and verify it's > doing what you want. ":q!" in vi quits without writing. I knew how to do a global replace in vi but my initial concern was that there are commas in other fields as well (CATEGORIES, LOCATION, etc.) and that escaping them might impair those fields. After doing some testing, it appears this is not the case and a global replace on commas will work just fine. So scratch one off the list. :-) > od can display the file in any manner you'd want to see. Try "od -c > infile | less". That'll show the ^M chars if they're there. Thanks, that's an excellent utility! I see \r \n being used regularly, but my question to myself is, why won't korganizer parse the ones in the DESCRIPTION field?. Or probably more to the point, how can I work around it? Is there a way to force a CR/newline or does it depend on the app parsing it? I'm going to try a two-pronged offensive and see if I can't find a resolution from the korganizer end of things. In the meantime, all pointers are welcome and much appreciated. Scripting and advanced text manipulation are things I have wanted to learn more about under Linux, so this is a good time for me to jump in. Sincerely, Curtis _______________________________________________ clug-talk mailing list [EMAIL PROTECTED] http://clug.ca/mailman/listinfo/clug-talk_clug.ca
