I'm no bash scripting expert, but I think the problem here is that the
Anaconda pythonw script does not quote "$@". That is, I suspect that the
third line of the script should be:
/Users/Harold/anaconda/python.app/Contents/MacOS/python "$@"
rather than:
/Users/Harold/anaconda/python.app/Contents/MacOS/python $@
The latter causes command line arguments that contain spaces to be split
and passed on as multiple arguments, while the former avoids the splitting.
So, for example, if I create a file called "test.py" containing
import sys
print sys.argv
and run
pythonw test.py "1 2" 3
(where pythonw invokes the regular Anaconda pythonw) the output is
['test.py', '1', '2', '3']
but with the "$@" quoted I get:
['test.py', '1 2', '3']
I discovered this apparent fix by reading the "Positional Parameters"
section at http://www.tldp.org/LDP/abs/html/internalvariables.html#APPREF .
Harold Mills
On Thursday, August 21, 2014 7:40:04 PM UTC-4, Chris Beaumont wrote:
>
> There are some idiosyncrasies to Anaconda's pythonw -- for example, the
> behavior of "-c":
>
> python -c "print 1+2" -> 3
> pythonw -c "print 1+2" -> Nothing
> /usr/bin/pythonw -c "print 1+2" -> 3
>
> chris
>
> On Thu, Aug 21, 2014 at 6:59 PM, Chris Barker > wrote:
>
>> On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer > > wrote:
>>
>>> The only potential issue I can think of for making python=pythonw is
>>> that pythonw is a shell script:
>>>
>>
>> I agree -- that could create issues (though will mostly work, I suppose)
>>
>> But somehow the python.org build has managed to make a pythonw that IS a
>> proper executable:
>>
>> ORRW-M-1275474:bin chris.barker$ pwd
>> /Library/Frameworks/Python.framework/Versions/2.7/bin
>>
>> ORRW-M-1275474:bin chris.barker$ ls -l pythonw
>> lrwxr-xr-x 1 root wheel 8 Jul 16 2013 pythonw -> pythonw2
>>
>> ORRW-M-1275474:bin chris.barker$ ls -l pythonw2
>> lrwxr-xr-x 1 root wheel 10 Jul 16 2013 pythonw2 -> pythonw2.7
>>
>> ORRW-M-1275474:bin chris.barker$ ls -l pythonw2.7
>> -rwxr-xr-x 1 chris.barker admin 9180 May 13 2013 pythonw2.7
>>
>> ORRW-M-1275474:bin chris.barker$ file pythonw2.7
>> pythonw2.7: Mach-O executable i386
>>
>> (yes, ti works for 64 bit too -- this just happens to be what I have)
>>
>> It would be nice if Anaconda would do it the same way.
>>
>> -Chris
>>
>>
>>
>>
>>
>>
>>
>>> #!/bin/bash
>>> export PYTHONEXECUTABLE=/Users/aaronmeurer/anaconda/bin/python
>>> /Users/aaronmeurer/anaconda/python.app/Contents/MacOS/python $@
>>>
>>> This is needed because otherwise Python thinks its sys.prefix is
>>> ../../ from the executable, i.e.,
>>> /Users/aaronmeurer/anaconda/python.app/Contents/MacOS
>>>
>>> $~/anaconda/python.app/Contents/MacOS/python
>>> Python 3.4.1 |Continuum Analytics, Inc.| (default, Aug 11 2014, 14:17:03)
>>> [GCC 4.2.1 (Apple Inc. build 5577)] on darwin
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import sys
>>> >>> sys.prefix
>>> '/Users/aaronmeurer/anaconda/python.app/Contents'
>>>
>>> I'm not sure what kinds of issues this would cause having python be a
>>> shell script rather than a Mach-O 64-bit x86_64 executable (or a
>>> symlink to a Mach-O 64-bit x86_64 executable).
>>>
>>> I suppose you could do this (replace 3.4 with 2.7 if you use Python 2):
>>>
>>> $mv ~/anaconda/bin/python3.4 ~/anaconda/bin/python3.4-orig
>>> $ln -s ~/anaconda/bin/pythonw /Users/aaronmeurer/anaconda/bin/python3.4
>>>
>>> and see if anything breaks (or if you don't want to risk breaking your
>>> main Python install, do it in a separate conda environment).
>>>
>>> Aaron Meurer
>>>
>>>
>>> On Fri, Aug 15, 2014 at 2:37 PM, Derek Homeier
>>> > wrote:
>>> > On 14 Aug 2014, at 11:40 pm, Chris Barker >> > wrote:
>>> >
>>> >> On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing >> > wrote:
>>> >> but as far as I can see, on OSX, there is no *advantage* to
>>> non-framework python. Is this correct?
>>> >>
>>> >> Suggestion for anaconda:
>>> >> make bin/python a link to ../python.app/Contents/MacOS/python
>>> >>
>>> >> NOTE: the python.org python build has been doing this (or something
>>> like it) for years and many versions -- I had gotten pretty used to it and
>>> was pretty annoyed when I discovered Anaconda keeps anon-framework binary
>>> as the default.
>>> >>
>>> >> It was annoying enough that I had to explicitly call pythonw (or
>>> alter the #! line) for my wxPython scripts, but with ipython it's even
>>> worse -- how would I start up ipython with a framework build?
>>> >>
>>> >> NOTE: if the Anaconda folks really think there is a real downside to
>>> using the framework executable for the default python, maybe the ipython
>>> start up script could use pythonw ?
>>> >>
>>> >> Eric - have you tried recent MPL with the python.org builds to
>>> confirm the issue? I'm a bit surprised that it would even semi-work -- when
>>> I try wxPython with the regular executable, I get an error message and it
>>> wont run at al
