Simon Josefsson wrote: > > The first phase is a script 'autopull.sh'. > > The second phase is a script 'autogen.sh'. > ... > > The names of these scripts end with '.sh' in order to make them easily > > editable in editors that recognize the file type from the suffix. > > What do you think about dropping the .sh suffix? As far as I know, few > if any tools that users/developers are expected to invoke have a .sh > extension. To me, these scripts are similar to ./configure or > ./bootstrap and we haven't used the .sh suffix for those.
That was my initial thought too: If we want a standard interface for invocation only, then we don't need a suffix. But: * The majority of packages will probably (like libunistring, gettext, libiconv, libsigsegv, gperf, etc.) continue to use hand-written autopull and autogen scripts. Simply because a 10-lines hand-written script is easier to start with than yet another configuration file whose syntax and semantics has to be understood. * Such scripts share the same limitations as configure: They can call only the coreutils, sed, grep, and git. Therefore it's unlikely that they will be compiled programs or python or perl scripts. * By adding the suffix '.sh' we're inviting the developers to see what's in it, rather than to consider them as a black box. And to create their own from scratch. > I know autogen.sh is a common idiom, but it does different things in > different projects If the concept of the two phases, that you defined, is convincing, the other packages will converge to this semantics over time. Bruno