From mboxrd@z Thu Jan 1 00:00:00 1970
From: Adolf Belka <ahb.ipfire@gmail.com>
To: development@lists.ipfire.org
Subject: Re: [PATCH] Fix for bug 12539
Date: Thu, 10 Dec 2020 17:45:21 +0100
Message-ID: <fe4a3308-9dd7-60ad-0442-4cc406742803@gmail.com>
In-Reply-To: <F20024B0-4D75-4C77-896D-108EF414F565@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6997931065873147120=="
List-Id: <development.lists.ipfire.org>
--===============6997931065873147120==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Hi,
On 10/12/2020 16:46, Michael Tremer wrote:
> Hi,
>=20
>> On 10 Dec 2020, at 16:26, Bernhard Bitsch <Bernhard.Bitsch(a)gmx.de> wrote:
>>
>>
>>
>>> Gesendet: Donnerstag, 10. Dezember 2020 um 15:48 Uhr
>>> Von: "Michael Tremer" <michael.tremer(a)ipfire.org>
>>> An: "Bernhard Bitsch" <Bernhard.Bitsch(a)gmx.de>
>>> Cc: "IPFire: Development-List" <development(a)lists.ipfire.org>
>>> Betreff: Re: [PATCH] Fix for bug 12539
>>>
>>> Hello,
>>>
>>>> On 10 Dec 2020, at 15:35, Bernhard Bitsch <Bernhard.Bitsch(a)gmx.de> wro=
te:
>>>>
>>>> Hi,
>>>>
>>>>> Gesendet: Donnerstag, 10. Dezember 2020 um 14:29 Uhr
>>>>> Von: "Michael Tremer" <michael.tremer(a)ipfire.org>
>>>>> An: "Bernhard Bitsch" <Bernhard.Bitsch(a)gmx.de>
>>>>> Cc: "Adolf Belka" <ahb.ipfire(a)gmail.com>, development(a)lists.ipfire.=
org
>>>>> Betreff: Re: [PATCH] Fix for bug 12539
>>>>>
>>>>> Hi,
>>>>>
>>>>>> On 10 Dec 2020, at 14:13, Bernhard Bitsch <Bernhard.Bitsch(a)gmx.de> w=
rote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>> Gesendet: Donnerstag, 10. Dezember 2020 um 13:48 Uhr
>>>>>>> Von: "Michael Tremer" <michael.tremer(a)ipfire.org>
>>>>>>> An: "Adolf Belka" <ahb.ipfire(a)gmail.com>
>>>>>>> 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 <ahb.ipfire(a)gmail.com> wrote:
>>>>>>>>
>>>>>>>> The installer recognises cups and cups-filters both as cups and puts
>>>>>>>> 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 command.
>>>>>>>> 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 <ahb.ipfire(a)gmail.com>
>>>>>>>> ---
>>>>>>>> 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 bg=
color
>>>>>>>>
>>>>>>>> # Generate list of installed addon pak's
>>>>>>>> - my @pak =3D `find /opt/pakfire/db/installed/meta-* 2>/dev/null | c=
ut -d"-" -f2`;
>>>>>>>> + opendir (DIR, "/opt/pakfire/db/installed") || die "Cannot opendir =
/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 who =
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 see=
from the patch, now the directory of installed addons is read with Perl func=
tions ( not in a extra forked process ). The definition of filenames is used =
consequently ( 'meta-<addon name>', possible services are stored in /etc/init=
.d/<addon name> ).
>>>>>
>>>>> 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 matchin=
g and replacing are defined with minimal overhead in writing.
>>>> Maybe the designer(s) of Perl had in mind the description of COBOL as "s=
peaking english with your computer". This was in the beginnings of computing,=
which did not experience all of us. ;)
>>>> With this single example you are right. Your formulation is much more re=
adable ( besides the fact that name is a string object ). But if you have man=
y such snippets in your code, the Perl way makes a shorter and thus more unde=
rstandable program.
>>>
>>> I disagree. Why would the usage of something that is hard to comprehend b=
e better when it is being used more often? Getting used to the wrong pattern =
doesn=E2=80=99t make it right.
>>>
>>> My main complaint about this is, that it is not clear what is being manip=
ulated. It is better to use the variable name and then there is no confusion =
about it. The same is true for loads of other Perl-isms like shift, chomp, ch=
op, etc.
>>>
>>> Shorter code does not necessarily mean that it executes faster. Probably =
the opposite is true in this case, because you would have to compile a regula=
r expression first and the Python version would simply perform a string searc=
h.
>>>
>>> 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 basic =
language class. Python works on objects and with their methods ( functions ),=
Perl works on plain variables with operators. Types are determined by the op=
erator and context. Each operator has also a result which isn't destroyed by =
a assigment or statement end. This result is hold in a special variable which=
can be manipulated directly.
>> If I review code, I should know this basics. Thus it doesn't make a real d=
ifference in comprehension ( to me ) if I read a object-oriented Python code =
or a Perl code. Nevertheless is the Perl code shorter. In our special example=
Perl avoids the generation (in written code ) of an intermeditiate variable =
by use of the implicit $_.
>> But this is a case of habit. Some like to talk in English only, some like =
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 vari=
able? Most of my code does.
>=20
My Perl learning here included the existence of the implicit $_. I let it in =
place because the section covered by foreach (@pak) was using it.
However if the preference is to be explicit with variables, I have no problem=
in doing that in any future bug fixes etc that I do.
Regards,
Adolf.
>> 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 stop=
ped
>>>>>>>> # mdadm should not stopped with webif because this could crash th=
e system
>>>>>>>> #
>>>>>>>> - chomp($_);
>>>>>>>> if ( $_ eq 'squid' ) {
>>>>>>>> next;
>>>>>>>> }
>>>>>>>> --
>>>>>>>> 2.29.2
>=20
--===============6997931065873147120==--