Re: Avoiding a shebang to call awk

[Alan D. Salewski]

On 2023-02-22 13:26:26, Greg Wooledge <greg@wooledge.org> spake thus:
> On Wed, Feb 22, 2023 at 05:18:05PM +0000, goncholden wrote:
> > Do people customarily not care that the tool is an awk script ?
[...]

> The name of the file that implements a shell command is the name by 
> which you invoke that command.  The name should reflect what the 
> program *does*, not what language it's written in.
>
> Separating the command's name from its initial implementation language 
> also allows you the freedom to rewrite it in a different language later, 
> without having to change every script that uses it.

Indeed.

In the context of languages that have a facility such as Bash's 'source'
command, I do make one exception, however, for the files being "sourced".

If I use Bash-specific constructs in such a file, I'll typically give it a
'.bash' extension to document that intentionality.

Similar for POSIX-shell-compatible snippets ('.sh') and ksh snippets ('.ksh').

In those cases, the implementation language does matter, though. I'm not 100%
consistent in my application of this convention, do not feel strongly about,
and note that the main benefit is just easy identification of such files -- it
makes the files easy to find, and serves (kinda-sorta) as a hint to the end
user that the file is not intended to be run directly. It can also help
explain why such files (in my typical usage) do not have their executable
bit(s) set.

Of course, there are files that are intended to be run meaningfully regardless
of whether they are invoked directly or sourced[0]. For those, the convention
of /not/ indicating the intended interpretter is probably the way to go,
unless there is a good reason to do otherwise[1].

-Al


[0] E.g., from the '/etc/init.d/README' file from the 'sysv-rc' package on
    Debian based systems:
    -->8--
        * /etc/init.d/*.sh scripts must not rely for their correct functioning
          on their being sourced rather than executed.  That is, they must work
          properly when executed too.
    --8<--

[1] Since I mentioned Debian above, I'll note that different Debian packages
    are inconsistent in this regard. Most do not have an extension, but some
    do (e.g., "mountkernfs.sh" (and others) from the 'initscripts' package).

--
a l a n   d.   s a l e w s k i
ads@salewski.email
salewski@att.net
https://github.com/salewski