OS X bash 3.2 doesn't run the bash completion
sscherfke opened this issue · comments
eval "$(vex --shell-config bash)" prints an error when executed with the OS X (10.9) default bash:
syntax error in conditional expression: unexpected token `('
syntax error near `@($'
` if [[ "${prev}" != @($take_args) ]]; then'
I think this is because OS X still uses bash 3.2. I don't get this error on Linux with bash 4.3.
bash 3.2, that's amazing, I'm not even mad.
Do you want to propose an edit to the completion script for bash so that it will work on both versions?
Otherwise I can just document a version requirement for bash.
As a lazy user I would ask you to make vex compatible with bash 3.2.
As a developer I would just tell Mac users to update their bash via homebrew (I guess most developers will have homebrew installed).
Since I’m not very experienced with bash programming, I cannot estimate the efforts of making vex compatible with bash 3.2. If it would be an easy fix, it may be a good idea to do it just to have less unsatisfied users. If it’s gonna be a lot of work, just add a note to the docs that bash completion requires bash > 4.whatever. :-)
I've tried downloading and compiling both of the variants of 3.2 from GNU, 3.2 and 3.2.48, and could not replicate this eval issue by directly running the command given (although 3.2 also gets unexpected token `(' against bash completions shipping with Ubuntu, to give an idea of how pervasive this seems to be...)
Not your fault at all, I want to help; but I really wish it were not necessary to be out of pocket for Apple hardware to legally run OS X in order to support Apple users who have had all these peculiarities like some deviant bash from 8 years ago dumped on them - as if the time required to sort out their (edit: the company's) weird decisions weren't enough...
I'll poke more at this again later
I can't debug this issue without access to the software that produces it and I'm not willing to blindly change this (try to fix the given error, push it up, have you run it again and produce anothe error, etc. - a ton of noise and a lot of frustration for both of us)
So my proposal is that if you (or some other OS X user) presents me with a version that works on your bash, and it also works for me and looks clean, then I will merge that and the bug will be fixed.
Sorry to kick this back to you but after trying several bash versions I can't find any options here to properly test against OS X without personally owning an Apple machine.
@sashahart - if you are interested in continuous integration, Travis does offer multi-OS builds, so it's possible to get free OS X testing...
Until recently I was using vex both with bash from OS X and bash from MinGW32 which is even more impressively ancient - bash 3.0 :-). These are exactly the audiences who could benefit the most from vex, since virtualenvwrapper is quite confusing for beginners…
It appears that this is not a bash 3.2 issue so much as a "completion support must already be sourced" issue. It depends on the bash-completion package from homebrew, in other words, not the bash package; with that installed, vex's completion seems to be working. I don't quite understand how this is possible, given that it's a syntax error and not a missing command or variable, but I will let you know if I come up with anything.
After trying whatever bash 3.2 I could get my hands on without replicating, I won't be surprised if it has something to do with a platform-specific build or configs rather than the version.
If the homebrew bash-completion package solves this somehow, it's particularly confusing that this would appear as a syntax error. I wonder what the homebrew package for bash-completion is really doing relative to the default bash for OS X.
Being able to check for the condition at the root of sscherfke's symptom would at least make it possible to provide a slightly more helpful message than that opaque syntax error.
I've made abortive attempts to replicate the complaint by messing up bash configs without much success, and will spend some more time next week on that since I'm also distantly concerned about the relevant variations the bash environment might suffer on other platforms.
This kind of investigation by OS X users is very helpful because it's an awkward kind of issue to track down without interactive access to a similarly configured system.
In the interim or in the worst case, this can be mitigated slightly in the README. I'll entertain amendments to #37 that would describe to OS X users what they should do, insofar as it's stuff vex can't reasonably do (like installing packages).