From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-3.9 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 9E0271F4BD; Tue, 1 Oct 2019 20:58:14 +0000 (UTC) Date: Tue, 1 Oct 2019 20:58:14 +0000 From: Eric Wong To: Alyssa Ross Cc: meta@public-inbox.org Subject: Re: [PATCH] #!/usr/bin/perl -> #!/usr/bin/env perl Message-ID: <20191001205814.GA19918@dcvr> References: <20190924204312.7875-1-hi@alyssa.is> <20190926024938.GA19132@dcvr> <87a7akcq8h.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87a7akcq8h.fsf@alyssa.is> List-Id: Alyssa Ross wrote: > >> certs/create-certs.perl | 2 +- > > > > Documentation in corresponding t/*.t files could be better > > about running that and instead recommend "$^X" > > Makes sense. This was the one that was giving me problems in the first > place. > > >> t/hl_mod.t | 2 +- > > > > Oops, there probably shouldn't have a shebang there at all > > since none of the other *.t files have it. I've also seen > > "#!perl -w" (no '/' at all) in other projects, but I don't think > > it's worth the effort unless some external tools/highlighters > > work better with it. I expect "#!/usr/bin/perl -w" to be most > > compatible with highlighters and stuff like file(1). > > #!perl has some nice characteristics -- it's understood by the > interpreter for setting flags, and for -x, but at the same time it's > clear that a file with #!perl is not supposed to be directly executed. Agreed. However, I'm not sure if compatibility with highlighters would be as good as a full path. > Assuming you don't want to change to #!perl, do you want a patch to > recommend running certs/create-certs.perl and remove the shebang from > t/hl_mod.t? And should the executable bits still be set on the other > files? Just the messages in t/*.t for certs/create-certs.perl is fine. Thanks. I don't think the other changes would affect users/testers. Also, t/hl_mod.t as-is could be a good comparison for syntax highlighters in the future (and I am leaning towards dropping "use warnings"). Not sure if there's executable bits worth changing, now; I think it's a good way to inform users that a given file can be executed (rather than loaded via `require'); but the '.t' files might be a special case...