Fix CSV output in avail.c

Andreas Ericsson ae at op5.se
Tue Jan 10 10:07:04 CET 2012


On 01/09/2012 06:38 PM, Sven-Göran Bergh wrote:
>> Från: Andreas Ericsson<ae at op5.se>
> 
>> Till: Sven-Göran Bergh<svengbergh-nagiosdevel at yahoo.com>; Nagios Developers List<nagios-devel at lists.sourceforge.net>
>> Kopia:
>> Skickat: måndag, 9 januari 2012 16:38
>> Ämne: Re: [Nagios-devel] Fix CSV output in avail.c
>>
>> On 11/28/2011 09:04 PM, Sven-Göran Bergh wrote:
>>>   Hi,
>>>
>>>   attached patch fix the CSV output from avail.c
>>>   to comply better with RFC-4180, see
>>>
>>>   http://www.ietf.org/rfc/rfc4180.txt.
>>>
>>>   Content-type now is Text/csv, so the browser
>>>   presents a view/save dialog.
>>
>> How is this an improvement over just hitting Ctrl+S once the page
>> has loaded? Personally, I detest when pages I *know* is plain text
>> forces me to click something just in order to either view or save,
>> when saving after it's viewed is so simple anyway.
> 
> Two of the reasons to why the patch was written in the first place
> are:
> - The Nagios CGIs are embedded in another GUI app that AJAX-load
>    the CGI pages in a div element. To get a stand alone window that
>    is possible to Ctrl+S save would mean a lot of tweaking, while the
>    result would violate an otherwise smooth GUI.
> 
> - Our users are no techies. An additional step would require a manual
>    (yah, no kidding) that no one reads anyway. They just want to get
>    the data directly into a spreadsheet with as little hassle as
>    possible.
> 
>>>   Likewise, CRLF is used.
>>>
>>
>> This could be tricky. I know there are parsers out there that handle
>> the Nagios-style CSV format, and if they break because we suddenly
>> choose to go strict with the style we use, we shove a broomstick up
>> our asses for no gain what so ever.
>>
>> So... Have you verified that this patch doesn't break anything, or
>> is that supposed to be an exercise for one of the maintainers? If
>> you haven't done it, it's unlikely to get done at all, and in that
>> case the CRLF part of the patch will almost certainly have to be
>> dropped or modified so that line-endings are given as a character
>> sequence by the user instead.
> 
> No, I have not run any additional tests. Just a normal compilation
> and our own in-house parser. Any specific parser/test you are thinking
> about? Hmm, I will try to look into a solution with desired line-
> ending supplied as a URI query variable that defaults to LF-only.
> Feel free to drop the CRLF part for the moment. I'll be back.
> 

I've done so. Since the only editor I know of that screws up LF/CRLF
differences in Windows is Notepad, I'm not overly fussed about this
and would rather just ignore it completely. I know all the major
office suites (Open, Libre and MS) handle LF line-endings just fine
in csv input though.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev




More information about the Developers mailing list