On Fri, Mar 09, 2018 at 07:44:36PM +0000, Ralph Corderoy wrote: > Hi Colin, > > > As with my similar previous patch, these are always invoked using the > > necessary interpreter, so the #! lines were unnecessary, and caused > > Debian's `lintian' tool to complain about installed non-executable > > scripts. > ... > > contrib/gpinyin/subs.pl | 6 ++---- > > contrib/groffer/main_subs.pl | 6 ++---- > > contrib/groffer/man.pl | 2 -- > > contrib/groffer/split_env.sh | 2 -- > > contrib/groffer/subs.pl | 2 -- > > contrib/groffer/version.sh | 2 -- > > src/roff/grog/subs.pl | 1 - > > I realise you're doing the minimally intrusive edit to fix the problem, > but I've always found these suffixes perverse, and wondered why it's not > groff.exe, etc., to match.
For actual executables, I entirely agree with you, of course. An extension on those requires the user to type additional characters (at least on Unix; Windows at least has the justification that the user doesn't have to type the ".exe" part), and it encodes the implementation in the interface in an inappropriate way that can cause problems later. The same considerations don't really apply to internal library files, though, which these are. If subs.pl were rewritten in Python for some reason, then groffer would have to do a whole lot more than changing "require 'subs.pl'" to "require 'subs.py'". :-) It's useful to have exactly one of a #! line or a file extension, because they serve the purpose of cluing editors into which syntax highlighting mode to enable without the need for embedding editor-specific metadata in the file. And both .pl and .sh have a long history in their respective communities of indicating a library file in the relevant language that's loaded by some means other than fork/exec. So, for all these reasons, I wouldn't be in favour of removing the extensions here. > Is another solution to remove these silly, foreign-platform, suffixes, > and make the files executable? For the most part, they definitely shouldn't be executable, because they're not intended to be executed directly: for example, the Perl components are libraries loaded using 'require'. Setting the executable bit on them would be quite misleading. There is one possible exception in the above list: split_env.sh is at least theoretically useful when executed directly, even though groffer specifically invokes it using 'sh'. But it's in fact an internal helper for groffer, so I don't think it really makes sense to suggest that its executability is part of its interface. Thanks, -- Colin Watson [cjwat...@debian.org]