Re: [groff] [PATCH] Remove #! lines from more non-executable files

[Colin Watson]

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                                       address@hidden