--245827083-1043122292-1326202270=:41207
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
> Fr=E5n: Andreas Ericsson =0A=0A>Till: Sven-G=F6ran Bergh =0A>Kopia: Nagios Developers List =0A>Skickat: tisdag, 10 januari 2012 10:07=0A>=C4=
mne: Re: [Nagios-devel] Fix CSV output in avail.c=0A> =0A>On 01/09/2012 06:=
38 PM, Sven-G=F6ran Bergh wrote:=0A>>> Fr=E5n: Andreas Ericsson=
=0A>> =0A>>> Till: Sven-G=F6ran Bergh; Na=
gios Developers List=0A>>> Kopia:=0A>>>=
Skickat: m=E5ndag, 9 januari 2012 16:38=0A>>> =C4mne: Re: [Nagios-devel] F=
ix CSV output in avail.c=0A>>>=0A>>> On 11/28/2011 09:04 PM, Sven-G=F6ran B=
ergh wrote:=0A>>>>=A0=A0=A0Hi,=0A>>>>=0A>>>>=A0=A0=A0attached patch fix the=
CSV output from avail.c=0A>>>>=A0=A0=A0to comply better with RFC-4180, see=
=0A>>>>=0A>>>>=A0 http://www.ietf.org/rfc/rfc4180.txt.=0A ... >>>=A0=A0=
=A0Content-type now is Text/csv, so the browser=0A>>>>=A0=A0=A0presents a v=
iew/save dialog.=0A>>>=0A>>> How is this an improvement over just hitting C=
trl+S once the page=0A>>> has loaded? Personally, I detest when pages I *kn=
ow* is plain text=0A>>> forces me to click something just in order to eithe=
r view or save,=0A>>> when saving after it's viewed is so simple anyway.=0A=
>> =0A>> Two of the reasons to why the patch was written in the first place=
=0A>> are:=0A>> - The Nagios CGIs are embedded in another GUI app that AJAX=
-load=0A>>=A0 =A0 the CGI pages in a div element. To get a stand alone wind=
ow that=0A>>=A0 =A0 is possible to Ctrl+S save would mean a lot of tweaking=
, while the=0A>>=A0 =A0 result would violate an otherwise smooth GUI.=0A>> =
=0A>> - Our users are no techies. An additional step would require a manual=
=0A>>=A0 =A0 (yah, no kidding) that no one reads anyway. They just want to =
get=0A>>=A0 =A0 the data directly into a spreadsheet with as little hassle =
as=0A>>=A0 =A0 possible.=0A>> =0A>>>>=A0=A0=A0Likewise, CRLF is used.=0A>>>=
>=0A>>>=0A>>> This could be tricky. I know there are parsers out there that=
handle=0A>>> the Nagios-style CSV format, and if they break because we sud=
denly=0A>>> choose to go strict with the style we use, we shove a broomstic=
k up=0A>>> our asses for no gain what so ever.=0A>>>=0A>>> So... Have you v=
erified that this patch doesn't break anything, or=0A>>> is that supposed t=
o be an exercise for one of the maintainers? If=0A>>> you haven't done it, =
it's unlikely to get done at all, and in that=0A>>> case the CRLF part of t=
he patch will almost certainly have to be=0A>>> dropped or modified so that=
line-endings are given as a character=0A>>> sequence by the user instead.=
=0A>> =0A>> No, I have not run any additional tests. Just a normal compilat=
ion=0A>> and our own in-house parser. Any specific parser/test you are thin=
king=0A>> about? Hmm, I will try to look into a solution with desired line-=
=0A>> ending supplied as a URI query variable that defaults to LF-only.=0A>=
> Feel free to drop the CRLF part for the moment. I'll be back.=0A>> =0A>=
=0A>I've done so. Since the only editor I know of that screws up LF/CRLF=0A=
>differences in Windows is Notepad, I'm not overly fussed about this=0A>and=
would rather just ignore it completely. I know all the major=0A>office sui=
tes (Open, Libre and MS) handle LF line-endings just fine=0A>in csv input t=
hough.=0A=0A=0A=0AI hear you. The patch is now revamped to listen to the us=
er. By default=0Anothing is changed.=0A=0ASummary:=0A- CSV output is either=
as today, or strict compliant with RFC4180.=0A=A0 No in betweens.=0A=0A- I=
f the URI query parameter "csvstrict" is supplied together with=0A=A0 csvou=
tput. The output will be strict according to RFC4180.=0A- Otherwise, the ou=
tput is the same as today.=0A=0A- An additional checkbox for csvstrict has =
been added=0A=0A- Output according to RFC4180 has the following changes com=
pared to the=0A=A0 traditional output:=A0 - HTTP,
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]