[mdlug] I need a script Hero

[Aaron Kulkis]

Raymond McLaughlin wrote:
> Aaron Kulkis wrote:
>> Raymond McLaughlin wrote:
> 
>>> I agree that file extensions, while optional, are often a good option.
>> But not on scripts that are meant to be commands....
> 
> Is there some practical reason for this, some sort of convention, or is
> it just your own subjective view?
> 

who wants to type .sh or .ksh after every command?


> My own, admittedly subjective, view is that I like to know at a glance
> the file type of a command: I view it as a courtesy and a convenience.
> I don't see what is gained by obscuring it to save three bytes in the
> file name.

if that's the case, then why not go through /usr/bin and rename all
the scripts there to show the type of script they are (shell script
or perl script)

as somone running a command...the last thing I should care about
is what language it's written in ... which is also why all of these
java projects named "jThis" and "jThat" are just ..well... again,
who the heck cares what language it's written in?

The ONLY thing that needs to know the language type of a file is
a compiler or linker.  For everything, the #!/path/to/interpreter
takes care of all that, and nobody needs language-indicating
extensions or j-whatevers.

I don't have problem with kde components being called k*... that's
indicating that it's part of a family of programs....it's part of
a theme.... and k* programs are written in a variety of languages.


> 
>> Filename extensions, on the other hand, should really only be used
>> for files associated with compilers (source files, non-executable
>> object files, and libraries).
> 
> And I suppose orange juice is just for breakfast. :)
> 
> Actually it's not unusual to see something like:
>   A command on the $PATH symlinked to a script
>     /usr/bin/firefox --->/opt/mozilla.org/firefox/firefox.sh
>   the script checks and sets up the local environment then calls the
>   binary. ie. firefox.bin (or some such).
> This "division of labor" is similar to that used in your example, where
> you might have files: 'program.c', 'program.o' and finally 'program' in
> the same directory. I realize I'm using here an extensionless file name,
> but in this example it is a binary.

true...but that's a special case hidden from th euser... users NEVER
type firefox.sh....

> 
> I feel pretty sure that this is a case where there is no one right
> answer, especially not one that fits all situations. In the case that
> originated this thread we were talking about a setup script found in the
> root of a CD. Whether you read the directions or just mount the CD and

Yeah, i caught that later....

> pull up a dir, you really can't miss it, and I think the extension is
> appropriate. I cases where the command is buried somewhere in the system
> tree then the presence or absence of an extension would depend on how
> you expect the user to even know about the command. And if there is any
> question a symlink can be used:
>     setup ---> setup.sh



> 
> Can you name an instance where the presence of an extension caused a
> problem? Particularly a problem that wasn't really a problem of poor
> documentation?

it's not a technical problem..it's typing more characters for the
sake of typing more characters problem....