Coming from an enterprise and supercomputing background, we were able to control what shell was available, so bashisms weren't a problem any more than dashisms, fishisms, kornisms, perl or python versionisms, etc, might be.
But, when I was in a commercial environment, everything - shell, perl, C, text tools, etc - had to be tested and usage adjusted accordingly. It wasn't uncommon to have a starter script that performed compatibility tests and forked to the appropriate version... of the same code, functionally. Back to the OP's problem. I haven't seen the bash source, but if I had to guess, based on behavior, bash is only checking the line after the she-bang. With a little more testing, I've concluded that the nul ^@ can appear anywhere other than in line #2. My guess is that, after finding the she-bang, bash is reading one more line to make the "is or is not binary" determination. I imagine that is oodles less overhead than scanning the entire file. I have not tested the behavior if the first line is not a she-bang, such as if the script is run via argument to bash. On Thu, Apr 6, 2023 at 1:19 PM Adam Dinwoodie via Cygwin <cygwin@cygwin.com> wrote: > On Thu, Apr 06, 2023 at 04:43:51AM +0000, Fergus Daly via Cygwin wrote: > > I have a "hash bang" bash shell script i.e. first line > > #! /bin/sh > > or equivalently > > #! /bin/bash > > For various reasons I want this file to be identified as binary so its > second line > > is the single character null \x00 showing up in some editors e.g. nano as > > ^@ > > This does not prevent the script from running to a successful conclusion. > > Or not until recently. Now the script fails with > > /home/user/bin/file.old.sh: cannot execute binary file > > Q1 - was bash recently updated? Would this explain the changed behaviour? > > Q2 - if so, is this newly introduced "glitch" known and presumably > intended? Or > > an unintended consequence that will be retracted in a later update? > > I then altered the first line to > > #! /bin/dash > > whilst retaining the null character at line 2 and subsequent content > also unaltered.. > > The altered script file.new.sh runs as previously to a successful > conclusion. > > Q3 - at 1/8 the size of bash and sh, I am not at all sure of the role > and reach of dash. > > Should the edit (dash replacing bash/sh) be incorporated elsewhere or > would this be a > > bad idea (and retained only locally in what is indeed an eccentric and > one-off context)? > > Dash is smaller and much less feature-rich than Bash. Whether Dash is a > suitable replacement for Bash depends on how much (if at all) you're > relying on Bash-specific functions. For very simple scripts, the only > difference is likely that Dash will be very slightly faster, but working > out whether your script is using any "Bashisms" isn't always a trivial > job. > > (I have previously been involved work in migrating scripts between Ksh > and Bash, which is a similar-but-different problem, and there were *a > lot* of surprises in how the two differed.) > > Depending on why you want the file to be identified as a binary, and how > that identification is being done, you could move your null byte later > in the file. In particular, a pattern I've seen several times in Bash > is to have a normal Bash script, finishing with an explicit `exit`, > followed by an actual binary blob; this can be used to create things > like self-extracting bundles, where the binary blob is a tarball and the > script at the top of the file has the instructions for extracting the > tarball. > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation: https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
