Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1.46, 10.2.33, 10.3.24, 10.4.14, 10.5.5
-
None
Description
Commit
mtr: use env for perl (37c88445e30d52c965bcb19b19fa710c3eb4fad9) has a error.
Several files have more 2 parts in shebang.
Shebang should contain 1 or 2 parts. Not 3 or more.
#!/usr/bin/perl
|
– valid
#!/usr/bin/perl -w
|
– valid
#!/usr/bin/env perl
|
– valid
#!/usr/bin/env perl -w
|
– not valid
Attachments
Activity
Just for the record, the perl -w option is to print out warnings and
should not be used in production:
https://manpages.debian.org/buster/perl-base/perl.1.en.html#DIAGNOSTICS
The "use warnings" pragma produces some lovely diagnostics. One
can also use the -w flag,
but its use is normally discouraged, because it gets applied to
all executed Perl code,
including that not under your control.
In 10.5.5 mytop is not using -w anymore. Only mariadb-report and some
test suite scripts and ColumnStore use -w (although ColumnStore is
alpha, so printing warnings there is I guess intentional).
The format "env perl" should not be used at all, it should always be "/usr/bin/perl" (at lest in Debian, https://www.debian.org/doc/debian-policy/ch-files.html#scripts) but for some reason it was reverted for innotop in https://github.com/MariaDB/server/commit/dbd1d7ea8e96a2b4cff89ec889494700d634b3a3
env is a stop gap until a better universal detection mechanism for the path of perl is determined and replaced in each script, because its not all about Debian. I'll take a debian policy violation compared to 'perl not found' on another platform.
-w removed from all scripts. Looking at scripts, its questionable as to why those scripts are there.
|
debian scripts also get policy compliant version |
--- a/debian/additions/mysqlreport
|
+++ b/debian/additions/mysqlreport
|
-#!/usr/bin/env perl -w
|
+#!/usr/bin/perl
|
|
|
--- a/debian/additions/innotop/innotop
|
+++ b/debian/additions/innotop/innotop
|
@@ -1,4 +1,4 @@
|
-#!/usr/bin/env perl
|
+#!/usr/bin/perl
|
Thanks for the bug report shaba
> env is a stop gap until a better universal detection mechanism for the path of perl is determined
> and replaced in each script, because its not all about Debian. I'll take a debian policy violation compared to 'perl not found' on another platform.
Sure, it is not "all about Debian" but in my experience typically the things that end up in the Debian policy are pretty universal good practices. There were some comments in your commits about FreeBSD not supporting /usr/bin/perl but I did not find any details about FreeBSD's policy on this. According to https://lists.freebsd.org/pipermail/freebsd-ports/2013-October/087104.html FreeBSD has had /usr/bin/perl at least since 2013.
On Debian (mariadb 10.3.24), there is also a dependency problem, we install libdbd-mariadb-perl but mytop requires libdbd-mysql-perl.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970681.