I've found a lot of questions on .inputrc, and the answers included people using Mac OS X terminal.app.
But I've set this property on and it didn't change readline's behaviour. I tried the same .inputrc on Ubuntu and it worked…
Is there some specific action I should take on terminal.app?
Well, I think I've finally cracked it.
I will answer my own question for future reference here:
Mac OS X uses editline (descendant from libedit that kinda emulates readline) instead of the more commom readline command line text handler.
I'm still learning how editline works, but I guess it isn't 100% compatible with readline's .inputrc.
So my completion-prefix-display-length attribute probably doesn't work with my version of OS X editline.
So that was it indeed.
I've made the following test to prove my hypothesis:
I've compiled readline under Mac OS X and then run bash with the readline lib I've compiled (through with-readline tool).
It worked fine, all my inputrc attributes worked and I finished my questions.
So in Mac OS X readline is shadowed by editline (it still has readline.h includes and realine's dynamic libraries, but they are editline's code).
Related
It may be trivial question, but I'm looking over the internet and SO about namei in macos. I can't find it on Yosemite, also homebrew doesn't contains such package to install. From what I was searching, MacPorts doesn't have it neither. Could some pro developers from MacOs help me or suggest other command that will be able to check for ownership and permissions on a path?
I'm writing this as an answer vs. a comment although I will make a comment first and that is, this doesn't appear to be a question suited to this forum and you might want to ask elsewhere, e.g. Super User.
That said, namei is a part of the util-linux package and as such is not a command normally found under OS X. If it's even possible, you have to download the source code for util-linux and then selectively compile namei and then manually install namei by itself as you would not want to compile and install the entire util-linux package under OS X. I've done similar under OS X with individual utilities of the GNU Core Utilities package however not with the util-linux package.
I'm in trouble to make flyspell to work in emacs. I'm a Mac user, but I'm not using Aquamacs, which seems to provide this facility by default.
Starting new Ispell process [/usr/local/bin/aspell::default] ...
ispell-init-process: Error: No word lists can be found for the language "en_US".
The error message is trying to tell you that Emacs started the external program aspell in a subprocess, which is good, but that it couldn't find its dictionary file, which is bad.
Try typing M-x ispell-change-dictionary RET SPC to see if there are any dictionary files that Emacs knows about, and select one of them.
If that doesn't work, then there is something wrong with your installation of flyspell. What to try next depends on the version of Emacs you are using (the terminal version that comes with OS X, a newer terminal version installed via Homebrew or MacPorts, the Cocoa version, or Aquamacs). On my machine, for example, I am running Cocoa Emacs 24 under Snow Leopard, and flyspell.el comes preinstalled, but to actually get it to work I had to install the aspell package using Homebrew (which provided the aspell executable and its dictionary files). Can you give us more information about your environment (OS X version, Emacs version, etc.)?
So, we all know that Mountain Lion doesn't ship with X11 anymore and users needing X11 are directed to download Xquartz. Xquartz installs to /opt, but it also symlinks X11 and X11R6 to /usr. But when building software that requires linking to X11 include files, I've discovered that I must pass an environment variable adding /usr/X11/include (or /opt/X11/include) to the library search path to get ./configure to find the X11 libraries. My question is why?
I've done some research on Google (many results pointing back to Stack Overflow), and I've read Apple's documentation, and these sources all indicate that there is no equivalent in OS X to the /etc/ld.so.conf file found in many (if not all) Linux distributions. Apple even states that DYLD_LIBRARY_PATH is empty by default. However, under Lion (with Apple's last 'official' X11 installed), the same ./configure scripts would find the X11 libraries without adding anything to the library search path.
So, why can't ./configure scripts find X11 libraries in Mountain Lion without explicit modification of the library search path?
Asked more than a year ago... but as I came here with a similar problem...
Note that in the mentioned ruby question, there was no library search path being modified.
That solution just set an environment variable that is picked up by many Makefiles as the flags for the C++ compiler. That example defined the build time -I ncludepath, i.e. where to search for .h eaders -- not libraries (which would have been a -L option to your compiler/linker). Both would have been build time options.
Whether LD_LIBRARY_PATH or DYLD_LIBRARY_PATH -- both are environment variables that are considered by the dynamic linker at runtime. (For more, see http://en.wikipedia.org/wiki/Dynamic_linker )
I have no pre-10.8 machine at hand, but guess that there might have been a symlink
/usr/include/X11 -> /opt/X11/include/X11 -- otherwise I have no Idea atm how
it could have worked before, assuming same sources...
This is another potential solution for such problems (just fixed my realvnc build):
$ autoconf
$ ./configure
So your question for "why?" could be eventually answered with: Because your sources contained a 'pre-built' configure script that was based on older autotools that did not include
/opt/X11/include as a potential location to search for X11 includes or simply did not get some of the above mentioned compile time flags right on your current system.
I have autoconf installed through homebrew -- ahh, great stuff, cheers.
I have a unix command line app (with big nasty makefile) that I'm trying to run on a mac. I am compiling it on a 10.6 system, with all of the appropriate libraries of course. The deployment environment is a 10.5 system, with no extra libraries.
I compiled without -dynamic, and it appears to have static libraries, correctly. When I run it on the 10.6 system, it works. However, when I run it on the 10.5 system, I get:
dyld: unknown required load command 0x80000022
I got this same error when I compiled things for the 10.6 system using the 10.5 xcode, so it looks like a version mis-match type problem. However, I used gcc-4.0, and
$CFLAGS = -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5
so it SHOULD be set up for 10.5... any ideas?
thanks
Editing an ancient question:
I have the exact same problem on a different computer. This time I am at 10.5.8, fully update, the same executable works on 10.6 still.
Has anyone had any luck with this in the months since I asked this?
The reason for the dyld 0×80000022 error can be that, you are linking on OS X 10.6, and OS X 10.6 will use a load command (LC_DYLD_INFO_ONLY = 0×80000022) that OS X 10.5 does not understand.
To fix this, make sure you are using a deployment target by setting the environment variable just before your link command:
export MACOSX_DEPLOYMENT_TARGET=10.5
(or setenv MACOSX_DEPLOYMENT_TARGET=10.5)
You can always check if your executable uses the right load command like this:
otool -l executable
It will either show LC_DYLD_INFO_ONLY (without deployment target) commands or LC_DYLD_INFO (with deployment target).
I have been searching for the same issue, as I develop on 10.6 but must have a version that works on 10.5. In addition to the compiler flags above, you should add:
-no_compact_linkedit
It is described here:
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/ld.1.html
where it says:
Normally when targeting Mac OS X 10.6, the linker will generate compact information in the __LINKEDIT segment. This option causes the linker to instead produce traditional relocation information.
I got there from a discussion on the xcode-users mailing list about "unknown required load command 0x80000022".
i was able to solve this by passing -mmacosx-version-min=10.5 to the linker, e.g. --extra-ldflags="-mmacosx-version-min=10.5" passed to configure for ffmpeg which i was building shared. more info: http://lists.apple.com/archives/xcode-users/2009/Oct/msg00530.html
Depending on how many libraries you use, it may be difficult to get all of them linked statically. What does "otool -L your_binary' tell you?
In order to get a self-contained package for an application of my own, I made a custom MacPorts install in a non-standard directory, so that I could dynlink with the libraries from that directory and only be constrained in asking people to install the whole thing in the same place on their computers. Not great, not the Mac spirit at all, but it's an Unix app and you need to be familiar with Unix to use it anyway.
Good luck
Pascal
It turns out that there is a dynamic library load function (0x22) that got added at 10.5.6. The system I was running on was 10.5.5. I upgraded to 10.5.8, and everything runs!
Ok, SECOND solution, and NOT very satisfying, is to find a 10.5.8 computer, install the developer packages and re-compile... same for powerPC... sad but it will work...
I'm sure this is a newbie question, but every time I've compiled/dl'ed a new version of vim for os x, running vim on the command-line opens up the gvim app. I just want to upgrade the console version (so I can, for example, have python compiled in to use omnicomplete).
If I understsood the question correcty, here is another solution: check out http://www.andrewvos.com/2011/07/23/upgrading-vim-on-os-x-with-homebrew/
Really simple, fast, painless. It uses homebrew-alt and you also need to have mercurial installed (it will prompt you if not).
You can also use MacPorts to handle the installation for you. Once you've installed it, run the /opt/local/bin/vim binary. I place this in my PATH before the system binary dirs (although be aware that this may cause problems for cmdline tools that rely on the versions of tools shipped with OS X).
This may sound stupid, but are you copying the vim binary to /usr/bin? by default, the "vim" path is /usr/bin/vim. If you compile from source, you'll likely need to either copy the vim binary to /usr/bin/vim (thus overwriting the original vim), or launch the compiled version via absolute path (eg. ~/vim-checkout/build/vim).
that's just a guess, however. I can't see it being anything more than that.
With Homebrew:
brew install macvim
ln -s /usr/local/bin/mvim /usr/local/bin/vim
Can also symlink your new binary to /usr/local/bin/