From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Fischer To: development@lists.ipfire.org Subject: Re: Bug #11494 Date: Tue, 03 Oct 2017 14:44:51 +0200 Message-ID: <14733b0a-2485-a330-e3e3-6f0a14754f59@ipfire.org> In-Reply-To: <000001d33c39$7c8b6930$75a23b90$@googlemail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1157687231979310520==" List-Id: --===============1157687231979310520== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 03.10.2017 13:19, Wolfgang Apolinarski wrote: > Hi, Hello, > thanks for discovering the bug, I'm sorry that I did not find it during my = tests. Regarding a possible solution, I have the following comment: >=20 > We could resolve it in 3 different files: > extrahd.pl - which actually emits the output by a PRINT statement (line 51)= which looks a little bit like a debug statement. Nevertheless, it might make= sense that this file gives some output. Jm2C: That is exactly what I'm still thinking: debug output. Where could this "print"-output be used, anyway? > extrahdctrl.c - which only calls the extrahd.pl, but might be used by user= s in the commandline, so removing/redirecting the stdout could make sense, bu= t still it might be that users actually expect output here. Alternatively, a = --quiet option could be introduced here that suppresses the output. One more: I'm NO programmer, but in this file I'm actually missing a "return 0;" at the "penultimate" line (Sorry =3D> "vorletzte Zeile" =3D> Google translator ;-) ). Nearly all other *.c-files in '/src/misc-progs' have one. > extrahd.cgi - which is used by the web-frontend. Here, the "system" call co= uld be exchanged with an "qx" call or backticks, which would maybe make it mo= re explicit that we are not using stdout at this point. The commands could th= en be unchanged. I'm not a perl expert, so I'm not familiar if qx is preferre= d over system when the stdout should be ignored. In php, exec would be more a= ppropriate, I suppose. Handling this is - far - beyond my knowledge... ;-) Best, Matthias --===============1157687231979310520==--