geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell E Glaue <rgl...@cait.org>
Subject Re: What's the reason why not to add .sh extension to geornimo scripts ?
Date Wed, 13 Jul 2011 20:48:07 GMT


On 07/13/2011 02:43 PM, Russell E Glaue wrote:
> 
> On 07/06/2011 10:56 PM, Kevan Miller wrote:
>>
>> On Jul 2, 2011, at 4:13 AM, Shawn Jiang wrote:
>>
>>> I noticed that there are no extensions for all sh scripts of geornimo.
>>>   Does anyone know what's the background of this ?
>>>
>>>
>>> GERONIMO_HOME\bin\client
>>> GERONIMO_HOME\bin\deploy
>>> GERONIMO_HOME\bin\geronimo
>>> GERONIMO_HOME\bin\register-service
>>> GERONIMO_HOME\bin\shutdown
>>> GERONIMO_HOME\bin\startup
>>
>> I believe it started with bin/geronimo -- which was based on the karaf command and
that convention was carried over. Run 'svn log framework/configs/karaf-framework/src/main/distribution/unix-shell/bin/geronimo'
for more details.
>>
>> I know some people like to have <command>.bat and <command> that way
invoking a command is the same on linux/windows. Personally, I think we should have maintained
our existing conventions (e.g. geronimo.sh, etc). I'm somewhat used to typing 'geronimo',
now. So, don't have a strong opinion. Would value input from users.
>>
>> --kevan
> 
> The file name suffix, is primarily for the benefit of windows-type machines
> which need the file extension for determining run-time interpretation.
> 
> It would probably be necessary if the *nix shell script files appeared in a
> Windows OS installation of Geronimo, only so Windows users do not try to execute
> them.
> 
> Otherwise, the suffix is primarily for human visualization, so one can know the
> intention of the script by looking at the name. Without the suffix, one commonly
> pre-judges the script to be binary (though I will `head -1 file` it).
> 
> If the source is browsed in a Web Browser, having the suffix allows user-defined
> methods for viewing the files, instead of the browser and server assuming the
> suffix-less file is binary.
> 
> 
> Most of us don't double-click on unix scripts from a GUI, so it is not necessary
> to have the suffix extensions for the GUI's identification.
> 
> I would say a common documentation on how to execute the bat/sh scripts (without
> deviation for OS differences) is more important than GUI recognition of the file
> type. Most new users do not care how the script is interpreted. Most old users
> already know.
> 
> Besides, having a ".sh" extension does not tell you if the script is bash, csh,
> ksh, etc... So if you want to know the interpreter of a ".sh" file, you still
> have to look.
> 
> -RG
> 

Looking at what would be the likely Windows user download for the distribution
of Geronimo (the zip file), I see that Windows batch and Unix shell scripts are
intermingled in the bin directory, and that the shell scripts have no extension.

I would say that for alleviating any possible confusion among new Windows users,
we should put the ".sh" extensions back onto the shell script file names.

Either that, or we have the build process create two distributions, one for each
OS, which I think makes our release process unnecessarily more confusing. Adding
the suffix is much easier. IMO, A -3 character typing convenience is not a great
argument against the possible misidentification/confusion of new users.

Though I would prefer Documentation to be normalized for Unix environments, and
thus leaving off the .sh suffix, and having Windows environments be the
deviation, thus requiring the .bat suffix - I think most new users will be
application programmers, and they are still predominately using Windows. Our
effort should be focused on making things as less confusing as we can over
convenience.

-RG

Mime
View raw message