On Thursday, Nov 13, 2003, at 09:32 US/Pacific, Chuk Goodin wrote: [..]
[..]
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????
Allow me to illustrate my point, there is the compiled binary executable 'head' that happens to have no extension. But one of the small oopsies of installing the LWP onto a Mac OSX box was that the file system is 'case insensitive' so HEAD - the perl code stepped on 'head' the binary. So I had two choices,
a. get the c-code source for 'head' and recompile
b. whack in the perl code alternative for itOk, so I also liked some of the SYSV arguments that can be used with 'head' the binary, that are not in the BSD variant, so I hacked the perl code to do what I wanted rather than the standard BSD release version.
At which point we get to the core problem,
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 lineOne 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.
Yes, if one wanted to have 'head.plx' as the lwp link to the lwp-request code that would check to see how it was called to set default options, then one would have to hack the actual lwp-request code to clean that up...
And that gets us where in all of this???
So the real question is
Which Organizational Process????
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
