From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernhard Bitsch To: development@lists.ipfire.org Subject: Aw: Re: [PATCH] Fix for bug 12539 Date: Thu, 10 Dec 2020 19:49:42 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4109041628126068182==" List-Id: --===============4109041628126068182== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > Gesendet: Donnerstag, 10. Dezember 2020 um 17:45 Uhr > Von: "Adolf Belka" > An: "Michael Tremer" , "Bernhard Bitsch" > Cc: "IPFire: Development-List" > Betreff: Re: [PATCH] Fix for bug 12539 > > Hi, >=20 >=20 > On 10/12/2020 16:46, Michael Tremer wrote: > > Hi, > >=20 > >> On 10 Dec 2020, at 16:26, Bernhard Bitsch wro= te: > >> > >> > >> > >>> Gesendet: Donnerstag, 10. Dezember 2020 um 15:48 Uhr > >>> Von: "Michael Tremer" > >>> An: "Bernhard Bitsch" > >>> Cc: "IPFire: Development-List" > >>> Betreff: Re: [PATCH] Fix for bug 12539 > >>> > >>> Hello, > >>> > >>>> On 10 Dec 2020, at 15:35, Bernhard Bitsch w= rote: > >>>> > >>>> Hi, > >>>> > >>>>> Gesendet: Donnerstag, 10. Dezember 2020 um 14:29 Uhr > >>>>> Von: "Michael Tremer" > >>>>> An: "Bernhard Bitsch" > >>>>> Cc: "Adolf Belka" , development(a)lists.ipfir= e.org > >>>>> Betreff: Re: [PATCH] Fix for bug 12539 > >>>>> > >>>>> Hi, > >>>>> > >>>>>> On 10 Dec 2020, at 14:13, Bernhard Bitsch = wrote: > >>>>>> > >>>>>> Hello, > >>>>>> > >>>>>>> Gesendet: Donnerstag, 10. Dezember 2020 um 13:48 Uhr > >>>>>>> Von: "Michael Tremer" > >>>>>>> An: "Adolf Belka" > >>>>>>> Cc: development(a)lists.ipfire.org > >>>>>>> Betreff: Re: [PATCH] Fix for bug 12539 > >>>>>>> > >>>>>>> Hello, > >>>>>>> > >>>>>>> Great work. This looks like how it should be. > >>>>>>> > >>>>>>>> On 7 Dec 2020, at 15:01, Adolf Belka wrot= e: > >>>>>>>> > >>>>>>>> The installer recognises cups and cups-filters both as cups and pu= ts > >>>>>>>> two instances of cups in the add-on services table. > >>>>>>>> Based on input from Michael Tremer this patch replaces the command > >>>>>>>> returning the second element between hyphens with one that takes > >>>>>>>> what comes after "meta-" using Perl code rather than a shell comma= nd. > >>>>>>>> The second find command was changed as per Michael's suggestion. > >>>>>>>> > >>>>>>>> Tested in my ipfire test bed system and only results in one cups > >>>>>>>> entry. > >>>>>>>> Signed-off-by: Adolf Belka > >>>>>>>> --- > >>>>>>>> html/cgi-bin/services.cgi | 9 +++++---- > >>>>>>>> 1 file changed, 5 insertions(+), 4 deletions(-) > >>>>>>>> > >>>>>>>> diff --git a/html/cgi-bin/services.cgi b/html/cgi-bin/services.cgi > >>>>>>>> index 26ab4f314..36954ba70 100644 > >>>>>>>> --- a/html/cgi-bin/services.cgi > >>>>>>>> +++ b/html/cgi-bin/services.cgi > >>>>>>>> @@ -161,19 +161,20 @@ END > >>>>>>>> my $lines=3D0; # Used to count the outputlines to make different = bgcolor > >>>>>>>> > >>>>>>>> # Generate list of installed addon pak's > >>>>>>>> - my @pak =3D `find /opt/pakfire/db/installed/meta-* 2>/dev/null |= cut -d"-" -f2`; > >>>>>>>> + opendir (DIR, "/opt/pakfire/db/installed") || die "Cannot opendi= r /opt/pakfire/db/installed/: $!"; > >>>>>>>> + my @pak =3D sort readdir DIR; > >>>>>>>> foreach (@pak){ > >>>>>>>> chomp($_); > >>>>>>>> + next unless (m/^meta-/); > >>>>>>>> + s/^meta-//; > >>>>>>> > >>>>>>> Although this is the least intuitive thing to do. I have no idea wh= o designed Perl. I hope they are proud of all the chaos they have created :) > >>>>>>> > >>>>>>> -Michael > >>>>>> > >>>>>> Can't see where the solution is 'least intuitive'. As far as I can s= ee from the patch, now the directory of installed addons is read with Perl fu= nctions ( not in a extra forked process ). The definition of filenames is use= d consequently ( 'meta-', possible services are stored in /etc/in= it.d/ ). > >>>>> > >>>>> To be clear, I am complaining about the Perl language design instead = of the code. In my view something like > >>>>> > >>>>> name =3D name.replace(=E2=80=9Cmeta-=E2=80=9C, =E2=80=9C=E2=80=9D) > >>>>> > >>>>> is a thousand times easier to read. > >>>>> > >>>>> Best, > >>>>> -Michael > >>>>> > >>>> > >>>> Okay, that makes it clearer. > >>>> Perl has its roots in pattern matching. So the base functions of match= ing and replacing are defined with minimal overhead in writing. > >>>> Maybe the designer(s) of Perl had in mind the description of COBOL as = "speaking english with your computer". This was in the beginnings of computin= g, which did not experience all of us. ;) > >>>> With this single example you are right. Your formulation is much more = readable ( besides the fact that name is a string object ). But if you have m= any such snippets in your code, the Perl way makes a shorter and thus more un= derstandable program. > >>> > >>> I disagree. Why would the usage of something that is hard to comprehend= be better when it is being used more often? Getting used to the wrong patter= n doesn=E2=80=99t make it right. > >>> > >>> My main complaint about this is, that it is not clear what is being man= ipulated. It is better to use the variable name and then there is no confusio= n about it. The same is true for loads of other Perl-isms like shift, chomp, = chop, etc. > >>> > >>> Shorter code does not necessarily mean that it executes faster. Probabl= y the opposite is true in this case, because you would have to compile a regu= lar expression first and the Python version would simply perform a string sea= rch. > >>> > >>> The point is, that code should be obvious. It avoids bugs and it makes = it easier to understand for reviewers what is supposed to go on. > >>> > >> > >> The main difference between the Perl and the Python approach is the basi= c language class. Python works on objects and with their methods ( functions = ), Perl works on plain variables with operators. Types are determined by the = operator and context. Each operator has also a result which isn't destroyed b= y a assigment or statement end. This result is hold in a special variable whi= ch can be manipulated directly. > >> If I review code, I should know this basics. Thus it doesn't make a real= difference in comprehension ( to me ) if I read a object-oriented Python cod= e or a Perl code. Nevertheless is the Perl code shorter. In our special examp= le Perl avoids the generation (in written code ) of an intermeditiate variabl= e by use of the implicit $_. > >> But this is a case of habit. Some like to talk in English only, some lik= e to talk in their native language to be more exact. ;) > >=20 > > Yes, I understand that. But what do you do when you have more than one va= riable? Most of my code does. > >=20 >=20 > My Perl learning here included the existence of the implicit $_. I let it i= n place because the section covered by foreach (@pak) was using it. > However if the preference is to be explicit with variables, I have no probl= em in doing that in any future bug fixes etc that I do. >=20 I think it is necessary in this situations, to introduce an extra variable. T= he 'foreach (@pak)' construction is defined as traversing the list @pak and d= elivering the elements in $_. That is sufficient for such operations.=20 Best, Bernhard > Regards, > Adolf. >=20 > >> Best, > >> Bernhard > >>> Best, > >>> -Michael > >>> > >>>> > >>>> Best, > >>>> Bernhard > >>>> > >>>>>> > >>>>>> - Bernhard > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> # Check which of the paks are services > >>>>>>>> - my @svc =3D `find /etc/init.d/$_ 2>/dev/null | cut -d"/" -f4`; > >>>>>>>> - foreach (@svc){ > >>>>>>>> + if (-e "/etc/init.d/$_") { > >>>>>>>> # blacklist some packages > >>>>>>>> # > >>>>>>>> # alsa has trouble with the volume saving and was not really st= opped > >>>>>>>> # mdadm should not stopped with webif because this could crash = the system > >>>>>>>> # > >>>>>>>> - chomp($_); > >>>>>>>> if ( $_ eq 'squid' ) { > >>>>>>>> next; > >>>>>>>> } > >>>>>>>> -- > >>>>>>>> 2.29.2 > >=20 > --===============4109041628126068182==--