Re: autoexpect : can't find package Expect
after : $ sudo port uninstall expect $ sudo port selfupdate $ sudo port install expect giving : ---> Computing dependencies for expect ---> Fetching archive for expect ---> Attempting to fetch expect-5.45_1.darwin_11.x86_64.tgz from http://packages.macports.org/expect ---> Fetching expect ---> Verifying checksum(s) for expect ---> Extracting expect ---> Configuring expect ---> Building expect ---> Staging expect into destroot ---> Installing expect @5.45_1 ---> Activating expect @5.45_1 ---> Cleaning expect i ran autoexpect, having same prob : $ autoexpect can't find package Expect while executing "package require Expect" (file "/opt/local/bin/autoexpect" line 6) ??? best, Yvon 2011/10/1 Ryan Schmidt > > On Oct 1, 2011, at 00:48, Yvon Thoraval wrote: > > > I do have the MacPorts one : > > > > imyt% which tclsh > > /opt/local/bin/tclsh > > imyt% > > > > then, as far as i understand, i do have to clean expect first and then > reinstall it ? > > i think after a port selfupdate ? > > Oh. If you already have /opt/local/bin/tclsh then I don't know why it's not > working. But rebuilding expect wouldn't hurt as a troubleshooting step, so > yes, do "sudo port selfupdate", then you should be able to "sudo port > upgrade expect". > > > > > ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: autoexpect : can't find package Expect
On Oct 1, 2011, at 00:48, Yvon Thoraval wrote: > I do have the MacPorts one : > > imyt% which tclsh > /opt/local/bin/tclsh > imyt% > > then, as far as i understand, i do have to clean expect first and then > reinstall it ? > i think after a port selfupdate ? Oh. If you already have /opt/local/bin/tclsh then I don't know why it's not working. But rebuilding expect wouldn't hurt as a troubleshooting step, so yes, do "sudo port selfupdate", then you should be able to "sudo port upgrade expect". ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: autoexpect : can't find package Expect
I do have the MacPorts one : imyt% which tclsh /opt/local/bin/tclsh imyt% then, as far as i understand, i do have to clean expect first and then reinstall it ? i think after a port selfupdate ? best, Yvon 2011/10/1 Ryan Schmidt > > On Sep 30, 2011, at 23:16, Yvon Thoraval wrote: > > > i wanted to run autoexpect and got the folowing : > > imyt% autoexpect > > can't find package Expect > > while executing > > "package require Expect" > > (file "/opt/local/bin/autoexpect" line 6) > > imyt% > > > > This is strange because everything like that has been installed by > MacPorts : > > $ which expect > > /opt/local/bin/expect > > > > > > $ which autoexpect > > /opt/local/bin/autoexpect > > > > > > what sould I do in order to have autoexpect running ? > What about "which tclsh"? I expect (ha) that you get /usr/bin/tclsh, but > autoexpect would require it to be /opt/local/bin/tclsh. You probably > uninstalled the tcl port, which the expect port did not prevent you from > doing, because it only declared tcl as a build dependency; it should be > declared as a library dependency since it is also used at runtime. I've > fixed this in r84766. > > > ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: autoexpect : can't find package Expect
On Sep 30, 2011, at 23:16, Yvon Thoraval wrote: > i wanted to run autoexpect and got the folowing : > imyt% autoexpect > can't find package Expect > while executing > "package require Expect" > (file "/opt/local/bin/autoexpect" line 6) > imyt% > > This is strange because everything like that has been installed by MacPorts : > $ which expect > /opt/local/bin/expect > > > $ which autoexpect > /opt/local/bin/autoexpect > > > what sould I do in order to have autoexpect running ? What about "which tclsh"? I expect (ha) that you get /usr/bin/tclsh, but autoexpect would require it to be /opt/local/bin/tclsh. You probably uninstalled the tcl port, which the expect port did not prevent you from doing, because it only declared tcl as a build dependency; it should be declared as a library dependency since it is also used at runtime. I've fixed this in r84766. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: MacTex vs MacPorts
I've been meaning to make a BibDesk port for a while now. I don't recognize the others. Otherwise, MacPorts is pretty up to date. Especially if you install texlive+full Mark On Sat, Oct 1, 2011 at 12:54 AM, Scott Webster wrote: > On Fri, Sep 30, 2011 at 9:34 PM, Richard L. Hamilton > wrote: > > I imagine that if all the components were in MacPorts, it would be easy > enough to have a meta-port that just existed to give single name to cause > all the rest to be installed. > > > > Probably if you install texlive+full you get a lot of stuff :) I > didn't test this in my particular case. Perhaps it would have solved > my issues. > > Scott > ___ > macports-users mailing list > macports-users@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users > ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: MacTex vs MacPorts
On Fri, Sep 30, 2011 at 9:34 PM, Richard L. Hamilton wrote: > I imagine that if all the components were in MacPorts, it would be easy > enough to have a meta-port that just existed to give single name to cause all > the rest to be installed. > Probably if you install texlive+full you get a lot of stuff :) I didn't test this in my particular case. Perhaps it would have solved my issues. Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: MacTex vs MacPorts
Unless disk space is tight, or theres the potential for path confusion that couldnt be trivially avoided if one had both, I'd ask which had the best record of staying reliable and up-to-date. And not everyone wants to wait however long it takes for all the TeX stuff and its dependencies to build or even update from source. Not to mention that since MacPorts seems not always to be fully _tested_ in most reasonable combinations of ports and options (and some ports are outright mutually exclusive, including a few that probably don't have to be), I can see how some folks might just want to do a single download and install of binaries. Although I think I'd want LyX too somehow, if I were into the whole TeX world that much, unless one of those other GUI apps is something similar but better (I don't recognize most of them). I mean, way before TeX, I could use troff macros, or even write new macros, if I really wanted to, but mostly I don't want to bother anymore…so probably I'd want a decent GUI editor too. I imagine that if all the components were in MacPorts, it would be easy enough to have a meta-port that just existed to give single name to cause all the rest to be installed. On Oct 1, 2011, at 12:03 AM, Sam Kuper wrote: > Dear all, > > This thread was prompted by another thread I started recently, which > has since been resolved: > http://lists.macosforge.org/pipermail/macports-users/2011-September/025653.html > > I installed MacTex a couple of years ago, and although I'm not > currently using LaTeX for anything, I may want or need to use it again > in the future. > > MacTex has the advantage that it bundles everything needed for using > LaTeX on the Mac, including several handy GUI applications (BibDesk, > LaTeXiT, TeXShop, TeXworks, TeX Live Utility, and Excalibur), and > provides versions of each of these components that should be > compatible with each other. (Only two of those six GUI applications, > incidentally, seem to be available from MacPorts: LaTeXiT and > TeXShop.) > > However, MacTex has the disadvantage that it sits outside of any more > general package management system (e.g. MacPorts), which has the > following ramifications, IIUC: > > (1) it bundles utilities that may already be present on the user's Mac; > (2) if any of the utilities it bundles *are* present elsewhere on the > user's Mac, then the user is forced to decide which version to give > precedence to in the $PATH variable or other settings, and problems > may arise if other software installed on the Mac expects whichever > versions of those utilities that have *not* been given precedence in > the $PATH; > (3) its components can't be upgraded with a simple package manager > update/upgrade combo command. > > There may be additional disadvantageous ramifications that aren't > coming to mind right now. > > I'm trying to work out what the best compromise is. Should I keep > MacTex and just manage any conflicts with MacPorts as they arise (as > happened with ImageMagick as described in the thread I linked to > above)? Or should I ditch MacTex and instead rely upon MacPorts + > standalone installations of any LaTeX-related applications I might > like to use (e.g. BibDesk) that would have been included in MacTex, > but which aren't available from MacPorts? > > This make me wonder more generally whether it mightn't be possible for > the MacTex and MacPorts teams to combine forces with the aim of making > MacPorts the distribution system of choice for all the components of > MacTex (instead of MacTex's one or more giant ZIP files), thereby > removing the user's dilemma. Has this been discussed? If so, what > conclusions were reached? > > All advice appreciated. Thanks in advance, > > Sam > ___ > macports-users mailing list > macports-users@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users -- The waitress asked, "Do you want lemon or no lemon with that iced tea?" Naturally, I said "yes", and then burst out laughing, because there simply wasn't any other answer in Boolean logic. She didn't get it, but I got the lemon, which I wanted anyway. Later, I realized a quantum computer could have offered another answer: Schroedinger's Lemon! ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
autoexpect : can't find package Expect
Hey all, i wanted to run autoexpect and got the folowing : imyt% autoexpect can't find package Expect while executing "package require Expect" (file "/opt/local/bin/autoexpect" line 6) imyt% This is strange because everything like that has been installed by MacPorts : $ which expect /opt/local/bin/expect $ which autoexpect /opt/local/bin/autoexpect what sould I do in order to have autoexpect running ? Best, Yvon ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: MacTex vs MacPorts
I don't claim to have all the answers, but recently when I had to compile a "new" latex document I got from a colleague I found that it was not compatible with the macports versions. So I installed MacTex2011. It has a great prefpane to let you switch which tex distribution you want to have active (macports/mactex etc.). You can also choose exactly what you want to install when you install it. So I chose not to install ghostscript for instance, because I already had it via macports. I'm writing off my memory so hopefully I'm not too wrong, but in general it seems they can coexist reasonably well. If I only needed a few latex things I would probably just use macports, but I'm writing a thesis in latex right now and find the selection in MacTex helpful. In your case you might want to wipe out your (likely obsolete) MacTex and then only install the newer one if you need it... and when you do, customize the install to not interfere with macports. Anyway, just my 2 cents, Scott On Fri, Sep 30, 2011 at 9:03 PM, Sam Kuper wrote: > Dear all, > > This thread was prompted by another thread I started recently, which > has since been resolved: > http://lists.macosforge.org/pipermail/macports-users/2011-September/025653.html > > I installed MacTex a couple of years ago, and although I'm not > currently using LaTeX for anything, I may want or need to use it again > in the future. > > MacTex has the advantage that it bundles everything needed for using > LaTeX on the Mac, including several handy GUI applications (BibDesk, > LaTeXiT, TeXShop, TeXworks, TeX Live Utility, and Excalibur), and > provides versions of each of these components that should be > compatible with each other. (Only two of those six GUI applications, > incidentally, seem to be available from MacPorts: LaTeXiT and > TeXShop.) > > However, MacTex has the disadvantage that it sits outside of any more > general package management system (e.g. MacPorts), which has the > following ramifications, IIUC: > > (1) it bundles utilities that may already be present on the user's Mac; > (2) if any of the utilities it bundles *are* present elsewhere on the > user's Mac, then the user is forced to decide which version to give > precedence to in the $PATH variable or other settings, and problems > may arise if other software installed on the Mac expects whichever > versions of those utilities that have *not* been given precedence in > the $PATH; > (3) its components can't be upgraded with a simple package manager > update/upgrade combo command. > > There may be additional disadvantageous ramifications that aren't > coming to mind right now. > > I'm trying to work out what the best compromise is. Should I keep > MacTex and just manage any conflicts with MacPorts as they arise (as > happened with ImageMagick as described in the thread I linked to > above)? Or should I ditch MacTex and instead rely upon MacPorts + > standalone installations of any LaTeX-related applications I might > like to use (e.g. BibDesk) that would have been included in MacTex, > but which aren't available from MacPorts? > > This make me wonder more generally whether it mightn't be possible for > the MacTex and MacPorts teams to combine forces with the aim of making > MacPorts the distribution system of choice for all the components of > MacTex (instead of MacTex's one or more giant ZIP files), thereby > removing the user's dilemma. Has this been discussed? If so, what > conclusions were reached? > > All advice appreciated. Thanks in advance, > > Sam > ___ > macports-users mailing list > macports-users@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users > ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
MacTex vs MacPorts
Dear all, This thread was prompted by another thread I started recently, which has since been resolved: http://lists.macosforge.org/pipermail/macports-users/2011-September/025653.html I installed MacTex a couple of years ago, and although I'm not currently using LaTeX for anything, I may want or need to use it again in the future. MacTex has the advantage that it bundles everything needed for using LaTeX on the Mac, including several handy GUI applications (BibDesk, LaTeXiT, TeXShop, TeXworks, TeX Live Utility, and Excalibur), and provides versions of each of these components that should be compatible with each other. (Only two of those six GUI applications, incidentally, seem to be available from MacPorts: LaTeXiT and TeXShop.) However, MacTex has the disadvantage that it sits outside of any more general package management system (e.g. MacPorts), which has the following ramifications, IIUC: (1) it bundles utilities that may already be present on the user's Mac; (2) if any of the utilities it bundles *are* present elsewhere on the user's Mac, then the user is forced to decide which version to give precedence to in the $PATH variable or other settings, and problems may arise if other software installed on the Mac expects whichever versions of those utilities that have *not* been given precedence in the $PATH; (3) its components can't be upgraded with a simple package manager update/upgrade combo command. There may be additional disadvantageous ramifications that aren't coming to mind right now. I'm trying to work out what the best compromise is. Should I keep MacTex and just manage any conflicts with MacPorts as they arise (as happened with ImageMagick as described in the thread I linked to above)? Or should I ditch MacTex and instead rely upon MacPorts + standalone installations of any LaTeX-related applications I might like to use (e.g. BibDesk) that would have been included in MacTex, but which aren't available from MacPorts? This make me wonder more generally whether it mightn't be possible for the MacTex and MacPorts teams to combine forces with the aim of making MacPorts the distribution system of choice for all the components of MacTex (instead of MacTex's one or more giant ZIP files), thereby removing the user's dilemma. Has this been discussed? If so, what conclusions were reached? All advice appreciated. Thanks in advance, Sam ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Default `convert` command - MacPorts ImageMagick vs. existing installation
> From: Mr. Puneet Kishor > Date: 29 September 2011 14:27 > I don't think your assumption is correct. As far as I know, Apple will never > install anything in `/usr/local/` and definitely not so on a machine fresh > from the factory. By convention, `/usr/local/` is for the stuff that the user > installs. > From: Daniel J. Luke > Date: 29 September 2011 15:08 > Nope, Apple doesn't install anything in /usr/local (that place is reserved > for local system administrator use - ie. you). > From: Ryan Schmidt > Date: 29 September 2011 20:40 > No, Apple does not install software in /usr/local. That directory is > traditionally for users to install software into. Thanks, folks: consensus established; and since the consensus is that my assumption was wrong, I now agree with the decision to mark as invalid the bug I filed against the ImageMagick port. After a bit of digital archaeology, I'm sure the version of `convert` that was installed in /usr/local/bin got there due to my having installed MacTex a couple of years ago. (See http://www.tug.org/mactex/What_Is_Installed.pdf in case you're interested to know which utilities are bundled with MacTex.) I'm now going to consider uninstalling MacTex. Thanks again, Sam ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
