> >What kind of naming structure would you suggest for people who just > >want > >to use extensions for organizational purposes? > > when you say for 'organizational purposes' do you > mean in terms of tracking the 'source code' in a > source code control system? Or do you mean tracking > named applications????
Sort of both, but more of the former. Basically, if I've got a directory sitting there with three or four different types of files in it, I'd like to know which ones are perl (and I can just open them up in vi and fix them) and which ones aren't (and I'll have to find the source somewhere if I need to fix them). Right now I use .pl for that. > how to manage the name space problem associated with > wanting to use 'code' that will be found in the environmental > variable PATH so that one does not have to type out > the fully > qualified path to the executable at the > command line > > One solution is the /opt/<myPackage>/bin approach in which one > will install all of their 'applications' inside of their own > package name space on the file system under "/opt" per the > POSIX standard. This is an approach that the Fink Folks like. That seems pretty extreme for my needs. > So the real question is > > Which Organizational Process???? Calling it a "process" is probably going too far. -- chuk -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
