wxpython not executing in terminal/command mode.

I have a wxpython script which does not execute in a manner I thought it
would.

How can I get a wxpython script to run from the desktop ? I can only get it
to run at the command/terminal mode by first entering “python scriptname.py
”.

It will not execute by using “./scriptname.py” Other scripts will execut
using “./scriptname” in the
directory where it is stored.

The hash bang (#!/usr/bin/env/ python) is the first line in the script.

···

--
View this message in context: http://wxpython-users.1045709.n5.nabble.com/wxpython-not-executing-in-terminal-command-mode-tp5721089.html
Sent from the wxPython-users mailing list archive at Nabble.com.

Is there a space between env/ and python in your hashbang line as there is in your post? Get rid of it.

did you chmod the py file to be executable? (I'm a linux noob, but I think you need this too)

···

On 5/19/2014 5:34 PM, eightbits wrote:

I have a wxpython script which does not execute in a manner I thought it
would.

How can I get a wxpython script to run from the desktop ? I can only get it
to run at the command/terminal mode by first entering “python scriptname.py
”.

It will not execute by using “./scriptname.py” Other scripts will execut
using “./scriptname” in the
directory where it is stored.

The hash bang (#!/usr/bin/env/ python) is the first line in the script.

--
View this message in context: http://wxpython-users.1045709.n5.nabble.com/wxpython-not-executing-in-terminal-command-mode-tp5721089.html
Sent from the wxPython-users mailing list archive at Nabble.com.

Thanks Rufus, I will verify that the space is not a problem. Other

scripts execute

with the same. Yes, I have execute privileges for the file in the

directory where

it is stored.

I will give it a shot anyhow. I am thinking this has something to do

with paths which

i am not sure what the problem is with that.

I can execute by (1) going to command mode

                     (2) go to the directory.

                     (3) type "python scriptname.py"
···

On Mon, May 19, 2014 at 4:52 PM, Rufus V. Smith [via wxPython-users] <[hidden email]> wrote:

On 5/19/2014 5:34 PM, eightbits wrote:

I have a wxpython script which does not execute in a manner I thought it

would.

How can I get a wxpython script to run from the desktop ? I can only get

it

to run at the command/terminal mode by first entering "python

scriptname.py

".

It will not execute by using “./scriptname.py” Other scripts will execut

using “./scriptname” in the

directory where it is stored.

The hash bang (#!/usr/bin/env/ python) is the first line in the script.

View this message in context:

http://wxpython-users.1045709.n5.nabble.com/wxpython-not-executing-in-terminal-command-mode-tp5721089.html
Sent from the wxPython-users mailing list archive at Nabble.com.

Is there a space between env/ and python in your hashbang line as there

is in your post? Get rid of it.

did you chmod the py file to be executable? (I’m a linux noob, but I

think you need this too)

You received this message because you are subscribed to the Google Groups

“wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to [hidden email].

For more options, visit https://groups.google.com/d/optout.


If you reply to this email, your message will be added to the discussion

below:

http://wxpython-users.1045709.n5.nabble.com/wxpython-not-executing-in-terminal-command-mode-tp5721089p5721090.html
To unsubscribe from wxpython not executing in terminal/command mode., click

here.

NAML

"You’re neither right nor wrong

because people agree with you.

You’re right because your facts

and your reasoning are right."

Warren Buffett


View this message in context: Re: wxpython not executing in terminal/command mode.

Sent from the wxPython-users mailing list archive at Nabble.com.

I was wrong about the space. Told you I was a noob.

I'd say put a simple script of the same name in the same place.

like:

#!/usr/bin/env python
print "I executed."

and see if that works.

perhaps your script is executing and popping out?

···

On 5/19/2014 5:59 PM, eightbits wrote:

Thanks Rufus, I will verify that the space is not a problem. Other
scripts execute
with the same. Yes, I have execute privileges for the file in the
directory where
it is stored.

I will give it a shot anyhow. I am thinking this has something to do
with paths which
i am not sure what the problem is with that.

I can execute by (1) going to command mode
                         (2) go to the directory.
                         (3) type "python scriptname.py"

On Mon, May 19, 2014 at 4:52 PM, Rufus V. Smith [via wxPython-users] > <[hidden email] </user/SendEmail.jtp?type=node&node=5721091&i=0>> wrote:

> On 5/19/2014 5:34 PM, eightbits wrote:
>
>> I have a wxpython script which does not execute in a manner I thought it
>> would.
>>
>> How can I get a wxpython script to run from the desktop ? I can only get
>> it
>> to run at the command/terminal mode by first entering "python
>> scriptname.py
>> ".
>>
>> It will not execute by using "./scriptname.py" Other scripts will execut
>> using "./scriptname" in the
>> directory where it is stored.
>>
>> The hash bang (#!/usr/bin/env/ python) is the first line in the script.
>>
>> --
>> View this message in context:
>> http://wxpython-users.1045709.n5.nabble.com/wxpython-not-executing-in-terminal-command-mode-tp5721089.html
>> Sent from the wxPython-users mailing list archive at Nabble.com.
>>
> Is there a space between env/ and python in your hashbang line as there
> is in your post? Get rid of it.
>
> did you chmod the py file to be executable? (I'm a linux noob, but I
> think you need this too)
>
> --
> You received this message because you are subscribed to the Google Groups
> "wxPython-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [hidden email].
> For more options, visit https://groups.google.com/d/optout.
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://wxpython-users.1045709.n5.nabble.com/wxpython-not-executing-in-terminal-command-mode-tp5721089p5721090.html
> To unsubscribe from wxpython not executing in terminal/command mode., click
> here.
> NAML

--

"You're neither right nor wrong
because people agree with you.
You're right because your facts
and your reasoning are right."
Warren Buffett

------------------------------------------------------------------------
View this message in context: Re: wxpython not executing in terminal/command mode. <http://wxpython-users.1045709.n5.nabble.com/wxpython-not-executing-in-terminal-command-mode-tp5721089p5721091.html&gt;
Sent from the wxPython-users mailing list archive <http://wxpython-users.1045709.n5.nabble.com/&gt; at Nabble.com.
--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com <mailto:wxpython-users+unsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

eightbits wrote:

I have a wxpython script which does not execute in a manner I thought it
would.

How can I get a wxpython script to run from the desktop ? I can only get it
to run at the command/terminal mode by first entering “python scriptname.py
”.

It will not execute by using “./scriptname.py” Other scripts will execut
using “./scriptname” in the directory where it is stored.

The hash bang (#!/usr/bin/env/ python) is the first line in the script.

No one has asked yet what operating system you're running. Are you, in
fact, on Linux?

What DOES happen? Do you get an error? Or does it seem to run, but
produces no output? As an example, if you had something like this:

    if __name__ == '__main':
        myApp = myApplication(0)
        myApp.MainLoop()

That would happily run and return immediately without doing anything,
because of the typo.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

I have another python script that runs just fine from the Ubuntu 12.04
desktop. By that I mean when clicking on the Icon I will be prompted to
execute in terminal mode or display. Of course I select the run in terminal
mode.
As a matter of fact the script that will NOT run is a GUI version of the
same type of code without the wxpython generated GUI. Just to clarify, the
script that does run is just number of inputs using the “raw_input” function
and then performing some basic math functions and the appending the results
to a file.

The GUI (wxpython) version does the same thing, only replacing the input
prompts to use TextCtrl instead.

At first I thought it might have something to do with the “import wx”
module. To test this , I edited the non GUI version and just added in
“import wx” at the beginning of the the script. This original (non GUI)
script still executes as before, no problems .
So, I am thinking it is not due to the wxpython code but could be wrong.
Also, I am thinking that this may not be a path issue but I haven't a clue.

It is interesting that the suspect (GUI) version runs to run if I use the
terminal/command mode,
navigate to the directory where the python files is stored and then at the
command line
use “python filename.py”. Also, after navigating to the directory and
executing at the command line “./scriptname.py” generates the following:”
*bash: ./NewGasChkWIP.py: /usr/bin/env/python^M: bad interpreter: Not a
directory*”. If I could figure that one out, then progress may happen

···

--
View this message in context: http://wxpython-users.1045709.n5.nabble.com/wxpython-not-executing-in-terminal-command-mode-tp5721089p5721102.html
Sent from the wxPython-users mailing list archive at Nabble.com.

eightbits wrote:

It is interesting that the suspect (GUI) version runs to run if I use the
terminal/command mode,
navigate to the directory where the python files is stored and then at the
command line
use “python filename.py”. Also, after navigating to the directory and
executing at the command line “./scriptname.py” generates the following:”
*bash: ./NewGasChkWIP.py: /usr/bin/env/python^M: bad interpreter: Not a
directory*”. If I could figure that one out, then progress may happen

Do you see the problem here? You have
    #! /usr/bin/env/python
where you should have
    #! /usr/bin/env python

The ^M is also suspicious. Is it possible you edited this on Windows
and then copied it to Linux? Bash does not like DOS line endings on the
she-bang line. If you edit in vim, you should do ":ff unix" to change
the line endings.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

OS = version *Ubuntu 12.04*
Python version *Python 2.7.3* (default, Feb 27 2014, 19:58:35)

this is the file attributes (ls -la NewGasChkWIP.py):
* -rwxrwxr-x 1 jerryl jerryl 10936 May 20 14:03 NewGasChkWIP.py*

OK, on the chance that something in the format of the hashbang line might be
the problem
i tested every combination(s) I could think of. And to clarify, I used the
terminal.command mode
and tested using "*./NewGasChkWIP.py*".
It always seem to work if in file directory is use: python NewGasChkWIP.py

Results from: *./NewGasChkWIP.py* on command line in the file's directory

The following is tested the various hash bang methods:

*#!/usr/bin/python* and this gives:
: bash: ./NewGasChkWIP.py: /usr/bin/python^M: bad interpreter: No such file
or directory

*#!/usr/bin/ python* and this gives:
bash: ./NewGasChkWIP.py: /usr/bin/: bad interpreter: Permission denied

*#!/usr/bin/env python* and this gives:
: No such file or directory

*#!/usr/bin/env/python* and this gives:
bash: ./NewGasChkWIP.py: /usr/bin/env/python^M: bad interpreter: Not a
directory

*#!/usr/bin/env/ python* and this gives:
bash: ./NewGasChkWIP.py: /usr/bin/env/: bad interpreter: Not a directory

*#!/usr/bin/env/python* and this gives:
bash: ./NewGasChkWIP.py: /usr/bin/env/python^M: bad interpreter: Not a
directory

···

--
View this message in context: http://wxpython-users.1045709.n5.nabble.com/wxpython-not-executing-in-terminal-command-mode-tp5721089p5721104.html
Sent from the wxPython-users mailing list archive at Nabble.com.

eightbits wrote:

OK, on the chance that something in the format of the hashbang line might be
the problem
i tested every combination(s) I could think of. And to clarify, I used the
terminal.command mode
and tested using "*./NewGasChkWIP.py*".
It always seem to work if in file directory is use: python NewGasChkWIP.py

These are all still showing a ^M at the end of the first line, and
that's fatal. The shebang line interpretation is done at a very low
level, and it does not accept DOS line endings. The name must be
immediately followed by a \n character (an ASCII linefeed).

What editor are you using, exactly?

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

I am using GEDIT. I don't have any problems with some other scripts. BTW, the
script
does run using IDEL.

···

--
View this message in context: http://wxpython-users.1045709.n5.nabble.com/wxpython-not-executing-in-terminal-command-mode-tp5721089p5721108.html
Sent from the wxPython-users mailing list archive at Nabble.com.

Ok, thanks to all those who pointed me in the right direction. I opened the
file in question, this time using GHEX a Linux hex editor. I removed all of
the 0x0d,0x0a (CR/LF) bytes. That allowed the code to work and it did not
exhibit the problems I was struggling with.

So, that begs the question: Is the GEDIT editor not suitable to generate
proper python/wxpython code?
I really hate to start all over and learn to use another editor

But, the bottom line here is that the group solved the problem and pointed
me in the correct
direction. I was so happy to see the ability to run the script from a
Desktop Icon.
I was to the point of just giving up. I have several other python and
wxpython scripts that had the
same issue(s), so I will look into that.

···

--
View this message in context: http://wxpython-users.1045709.n5.nabble.com/wxpython-not-executing-in-terminal-command-mode-tp5721089p5721109.html
Sent from the wxPython-users mailing list archive at Nabble.com.

eightbits wrote:

Ok, thanks to all those who pointed me in the right direction. I opened the
file in question, this time using GHEX a Linux hex editor. I removed all of
the 0x0d,0x0a (CR/LF) bytes. That allowed the code to work and it did not
exhibit the problems I was struggling with.

So, that begs the question: Is the GEDIT editor not suitable to generate
proper python/wxpython code?
I really hate to start all over and learn to use another editor

Not at all. Usually, this kind of thing arises in one of two ways:
either you copied the file from a Windows source originally, or you
accidentally added the CR through some unintentional key sequence. In
the former case, there is a "dos2unix" command that will change the line
endings to Linux style. Alternatively, there is a gedit plugin that can
show you and change the line-endings

Python doesn't care about the line endings. Indeed, most user-mode
tools do not. However, that #! line is actually handled by the Linux
kernel, believe it or not, and the kernel is very particular about the
format. Now that you know what to look for, you'll recognize it if you
see it again.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

the problem is your #! line, probaly that darn DOS line ending:

A quick tutorial:

···

It always seem to work if in file directory is use: python NewGasChkWIP.py

if you call python explicitly then the !# line is not used, so this confirms that you have a #! line problem.

The following is tested the various hash bang methods:

#!/usr/bin/python and this gives:

: bash: ./NewGasChkWIP.py: /usr/bin/python^M: bad interpreter: No such file

or directory

this would call the system python, but that ^M is a DOS line ending, and *nix does not know what to do with that – fix the file – your editor may have a setting for what kind of line endings to use, or you jsut need to delete that line ending and put in a new on e (I suspect teh editor is set to DOS line endings – it may have auto-detected it from the file). Note that Python itself is forgiving of multiple line ending types, which is why it runs OK when you explicitly call python.

#!/usr/bin/ python and this gives:

bash: ./NewGasChkWIP.py: /usr/bin/: bad interpreter: Permission denied

this is trying to call the /usr/bin interpreter with python as an argument, but there is no such thing – it’s a directory

#!/usr/bin/env python and this gives:

: No such file or directory

That should work unless you have an odd install, /usr/bin/env shuld be the env utility, which will call the following command inside your default environemnt (i.e. use PATH to find python). (it also does other stuff, but that’s what we’re using it for here). try:

$ /usr/bin/env

to make sure it’s there – if not your Linux install is lacking, this is a very standard utility.

#!/usr/bin/env/python and this gives:
bash: ./NewGasChkWIP.py: /usr/bin/env/python^M: bad interpreter: Not a

directory

this shouldn’t work either – it would look for pythn inside the /usr/bin/env directory, but that’s not a directory…nor is python in it… And you have that pesky ^M on there…

#!/usr/bin/env/ python and this gives:

bash: ./NewGasChkWIP.py: /usr/bin/env/: bad interpreter: Not a directory

similar – the slash at the end says you think /usr/bin/env is a directory – it’s not.

#!/usr/bin/env/python and this gives:
bash: ./NewGasChkWIP.py: /usr/bin/env/python^M: bad interpreter: Not a

directory

didn’t you already do that (though this has that pesky ^M again!)

Short answer – it’s the DOS line ending! And that has gotten you all confused about everything else.

HTH,

-Chris

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice

7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

I suspect that GEDIT auto-detects the line endings used in a file, so once
you load a file with DOS line endings, it will keep using them. I"m sure
there is a way to change it for a particular file.

-CHB

···

On Tue, May 20, 2014 at 5:28 PM, Tim Roberts <timr@probo.com> wrote:

eightbits wrote:
> Ok, thanks to all those who pointed me in the right direction. I opened
the
> file in question, this time using GHEX a Linux hex editor. I removed all
of
> the 0x0d,0x0a (CR/LF) bytes. That allowed the code to work and it did
not
> exhibit the problems I was struggling with.
>
> So, that begs the question: Is the GEDIT editor not suitable to generate
> proper python/wxpython code?

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

I am thinking that I did open the start file from the "wxPython IN

ACTION" example

and it might have been created in a Windows/DOS environment. I did

indeed find non Linux end of line char’s following the hashbang line

and did not change that at first. I did remove the 0x0d char and that

allowed the program to execute. I am thinking that the fact that the

script would run if calling python followed by the py file should have

indicated to me that was the issue.

To test out GEDIT this morning, I created a very simple script and

checked it with

using GHEX editor and there was no extraneous 0x0d there, just the

Unix EOL char 0x0a. So, that must have been the issue. That should be

a warning in using download python files that could be generated on a

Windows platform.

BYW Chris, I am sort of a NOAA fan as I always thought NOAA operated

some very interesting ocean going vessels. I am a former Merchant

Marine and those things always get my attention.

You have a valid point in that GEDIT may work as you described, using

the auto-detect feature.

Best Regards

···

On Wed, May 21, 2014 at 10:45 AM, Chris Barker - NOAA Federal [via wxPython-users] <[hidden email]> wrote:

On Tue, May 20, 2014 at 5:28 PM, Tim Roberts <[hidden email]> wrote:

eightbits wrote:

Ok, thanks to all those who pointed me in the right direction. I opened

the

file in question, this time using GHEX a Linux hex editor. I removed all

of

the 0x0d,0x0a (CR/LF) bytes. That allowed the code to work and it did

not

exhibit the problems I was struggling with.

So, that begs the question: Is the GEDIT editor not suitable to generate

proper python/wxpython code?

I suspect that GEDIT auto-detects the line endings used in a file, so once

you load a file with DOS line endings, it will keep using them. I"m sure

there is a way to change it for a particular file.

-CHB

Christopher Barker, Ph.D.

Oceanographer

Emergency Response Division

NOAA/NOS/OR&R (206) 526-6959 voice

7600 Sand Point Way NE (206) 526-6329 fax

Seattle, WA 98115 (206) 526-6317 main reception

[hidden email]

You received this message because you are subscribed to the Google Groups

“wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an

email to [hidden email].

For more options, visit https://groups.google.com/d/optout.


If you reply to this email, your message will be added to the discussion

below:

http://wxpython-users.1045709.n5.nabble.com/wxpython-not-executing-in-terminal-command-mode-tp5721089p5721115.html
To unsubscribe from wxpython not executing in terminal/command mode., click

here.

NAML

"You’re neither right nor wrong

because people agree with you.

You’re right because your facts

and your reasoning are right."

Warren Buffett


View this message in context: Re: Re: wxpython not executing in terminal/command mode.

Sent from the wxPython-users mailing list archive at Nabble.com.

Yes, gedit works as Chris described.

But you didn't need to mess with a hex editor - Tim pointed you to the
dos2unix command.

···

On Wed, 21 May 2014 10:53:33 -0700, eightbits wrote:

I am thinking that I did open the start file from the "wxPython IN
ACTION" example and it might have been created in a Windows/DOS
environment. I did indeed find non Linux end of line char's following
the hashbang line and did not change that at first. I did remove the
0x0d char and that allowed the program to execute. I am thinking that
the fact that the script would run if calling python followed by the py
file should have indicated to me that was the issue.

To test out GEDIT this morning, I created a very simple script and
checked it with using GHEX editor and there was no extraneous 0x0d
there, just the Unix EOL char 0x0a. So, that must have been the issue.
That should be a warning in using download python files that could be
generated on a Windows platform.
You have a valid point in that GEDIT may work as you described, using
the auto-detect feature.