On 13 Aug 2010, at 02:32, Tom Lieber wrote:
The normal would be the opposite: the miniAudicle has a pre-made symlink to /usr/local/bin/chuck. Then, when the latter is updates, miniAudicle will use it.
If for some reason, one does not want miniAUdicle to change, just let it have a binary as is the case now. One will then run different binaries in it and from the console.
I'm not quite sure what you're saying, but if miniAudicle installs a ChucK in /usr/local/bin, then I don't see a reason to have a separate package just for command-line ChucK.
Mac OS X has a mixture of traditions, one comes from Mac OS 9, making applications (directories) which are complete in themselves, and should be able to run in any directory, but normally put into / Applications/. For example, the LilyPond application has its lilypond binary in LilyPond.app/Contents/Resources/bin/lilypond When checking miniAudicle, it seems it just have a binary miniAudicle.app/Contents/MacOS/miniAudicle but not 'chuck' binary. This is the binary used when starting miniAudicle from the GUI (Finder); it then gets some extra startup argument from the system (as can be seen using 'ps -x'). It is otherwise just a normal Unix binary adapted to be calleed from the GUI. The other tradition comes from BSD Unix. The stuff is normally put into /usr/local. These traditions can be combined, which is done by the TeX Live package. It puts all traditional Unix stuff into /usr/local/, but also has some application in /Applications/ which calls it. Since miniAudicle does not seem to install 'chuck', the installer might simply do that to. Possibly one might have the choice not installing it.