Python scripts not working

English Applications
#1

Hi
Recently i have been learning python and yesterday i run a script that did not work. Since then a lot of the scripts i have made do not work
I have noticed that when i do a ‘LS’ in the directory that contains the scripts all the scripts that don’t work the text is coloured black and the ones
that do work are coloured green. When i run the script i got this output

/path to the script including /name,py  $ Line 1 \r command not found

This was the case for about eight lines then the script stopped. Line 1 is just some commented out text eg name of script

I am using opensuse 13.1 and the latest version of python

Thanks

#2

On 05/01/2014 11:36 PM, Subzero01 wrote:
>
> Hi
> Recently i have been learning python and yesterday i run a script that
> did not work. Since then a lot of the scripts i have made do not work
> I have noticed that when i do a ‘LS’ in the directory that contains
> the scripts all the scripts that don’t work the text is coloured black
> and the ones
> that do work are coloured green. When i run the script i got this
> output
>
>
>
> Code:
> --------------------
> /path to the script including /name,py $ Line 1 \r command not found
> --------------------
>
>
> This was the case for about eight lines then the script stopped. Line 1
> is just some commented out text eg name of script
>
> I am using opensuse 13.1 and the latest version of python
>
> Thanks
>
>

Just a wild guess but do the scripts have permission to actually
execute? I am only asking this since you mentioned the ones that work
are green for ls. You can check the permissions using ls -l.

Read more about it here
http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions

–
Bring the Penguins Back! https://features.opensuse.org/316767
openSUSE 13.1
KDE 4.13.0

#3

That \r is a Windows line endings aka Carriage return, did you created that scrip from a Windows text editor or from a Windows machine? If so you should know that Unixes and Windows has different line endings. Unix systems use Line Feeds (LFs) only. You can check it out

cat -e name.py

or

sed -n l name.py

If you see something like

Blahblahblah**\r$**
**\r$**
More Blah blah blah\**r$**

Then you probably have Cr in your scripts. Some windows text editor you can configure the line endings and choose which one you want but don’t ask me how to do it in Windows ;). Any way it is just a hunch but please do send us some more info.

#4

If it is a permission issue the error would probably be

name.py: Permission denied

:wink:

#5

The very first line of your script should be the shebang or the hashbang and the first two bytes should be #! followed by the absolute path where your executable resides, e.g /bin/python and it is a MUST for the kernel to know how to interpret your script.

#6

On 2014-05-02, Subzero01 <Subzero01@no-mx.forums.opensuse.org> wrote:
>
> Hi
> Recently i have been learning python and yesterday i run a script that
> did not work.

It would also helpful if you could provide example of one of your scripts which do not work.

> Since then a lot of the scripts i have made do not work
> I have noticed that when i do a ‘LS’ in the directory that contains
> the scripts all the scripts that don’t work the text is coloured black
> and the ones
> that do work are coloured green. When i run the script i got this
> output
>
>
>
> Code:
> --------------------
> /path to the script including /name,py $ Line 1 \r command not found
> --------------------

Please clarify: are you naming your scripts name,py' (with a comma) or name.py’ (with a full stop) - you should use a
full stop, not a comma before an extension.

> I am using opensuse 13.1 and the latest version of python

Please confirm then you are using Python 3.x rather than Python: 2.7.x.

#7

Yeah I know but OP mentioned green so I figured I would ask that.

And I checked after I made the post and you can run the script without execute permission with this (you dont even need #!/path/to/python)

python file.py

Cant edit those posts though :stuck_out_tongue:

Regarding the \r, isnt there some utility that can do the conversion for you? I think its called dos2unix.

And to the poster above me, even if the file is named name,py, linux doesnt seem to care (try it). I think some clarification is needed, maybe the source code if OP is willing.

#8

On 2014-05-02, alanbortu <alanbortu@no-mx.forums.opensuse.org> wrote:
> And to the poster above me, even if the file is named name,py, if OP is
> running with the command I posted above, linux doesnt seem to care. I
> think some clarification is needed.

Perhaps I’m misunderstanding, but GNU/Linux (or rather Python running within GNU/Linux) does care if you’re trying
python name,py' when the file is called name.py’ or the other way round. But I certainly agree with you that much more
clarification is required from the poster. It should always be possible to execute a python script within a Python
shell e.g.:


sh-4.2$ python
Python 2.7.6 (default, Nov 21 2013, 15:55:38) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> execfile("name.py")

If that doesn’t work, then there are only three possibilities:

  1. The script isn’t in an available Python path or current working directory.
  2. The code has an error.
  3. There’s something wrong with the Python installation or site packages.

Whether or not `name.py’ is executable or not is irrelevant because it is a source file not an executable binary.

#9

Sorry, this post is kinda long.

Ah maybe, I was just talking about something like this:


> cat test,py 
print("hi")

>python test,py 
hi

But when I tried as you suggested:


> ls
test,py

> python2
Python 2.7.6 (default, Nov 21 2013, 15:55:38) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> execfile("test,py")
hi
>>>

Really? Because when I try to run python files from zsh I get permission errors. I am guessing you are talking about the python shell?


> ll test.py 
-rw-r--r-- 1 gum users 31 May  2 10:44 test.py

> cat test.py 
#!/usr/bin/python3
print("hi")

> ./test.py
zsh: permission denied: ./test.py
./test.py: command not found         

> chmod u+x test.py
> ./test.py 
hi
#10

There seem to be some misunderstrandings here. My contribution for what it is worth.

A program (any program, binary or script) can only be executed directly (e.g. by using it as first word in a command line) when the user doing the call has execute rights for the file. Thus in:

henk@boven:~/bin> l
totaal 36
drwxr-xr-x  2 henk wij  4096  2 mei 17:29 ./
drwxr-xr-x 84 henk wij  4096  2 mei 15:25 ../
-rwxr--r--  1 henk wij   434 23 jul  2012 fototime*
-rwxr-xr-x  1 henk wij 19126 23 jan  2011 mmcheck*
-rw-r--r--  1 henk wij   434  2 mei 17:29 somescript
henk@boven:~/bin>

the file forotime can be executed by the owner (henk) and by nobody else. The file mmcheck can be executed by anybody (if having access to the directory of course). The file somescript can not be executed:

henk@boven:~/bin> somescript
bash: /home/henk/bin/somescript: Toegang geweigerd
henk@boven:~/bin>

(meaning Permission denied).
The * is an extra indication that the execute permission is set and in some terminal emulations, the filename is also shown in green.

The first word on a command line (the program that should be executed) is in fact a file name. That file must of course be found. That can either be done by giving it a path (either relative or absolute). Many use, during testing, the relative path ./ when their working directory is the directory that contains the file. Another much used option is having the file in one of the directories mentioned in the PATH environment variable. For that reason it is often nice to put a (production) program in ~/bin. You can then call it without any path added.

When such a program is a script, the kernel must know which interpreter to use to run it. In fact then not the file is loaded, but the interpreter and the file is offered as an argument to the interpreter. Telling the kernel is done using the “shebang”. The first line with, in the case of pyton:

#!/usr/bin/python3

(I saw this above, I do not know if this is the correct call, but I hope you get the message).

There is allways the possibility to ignore all these niceties and call the interpreter yourself and giving the script file as an argument.

All this is regardless of the suffix of the file name. When you like it to have the suffix of .py, that is of course OK, but it is purely for your own administration and/or satisfaction… Unix/Linux has no concept of an “Extension” as e.g. MS-DOS has.

My two cents.

#11

On 05/02/2014 11:56 AM, hcvv wrote:
>
> My two cents.
>

Thank you, that was very informative :slight_smile:

–
Bring the Penguins Back! https://features.opensuse.org/316767
openSUSE 13.1
KDE 4.13.0

#12

Remember that MSDOS/Windows uses a CR+linefeed to end a line but in Linux/Unix only a linefeed ends a line. So if importing you must remove all Carriage Returns and when moving to DOS/Windows you need to add a CR before each linefeed.

#13

Although I don’t have it in front of me at the moment,
I’ve been using vim to replace characters at the end of every line for scripts that got mangled when they were saved by a Windows app (typically adds various characters at the end of every line).
You can also use this to remove characters by simply “replacing” the characters with an empty space.

If needed, I’ll look up what works for me, I had to go through a few suggestions on the Internet to find working commands (several don’t).

TSU

#14

There are tools for that: dos2unix and unix2dos. See:

man dos2unix
#15

The * is an extra indication that the execute permission is set and in some terminal emulations, the filename is also shown in green.

l is aliased to ls -alF

type l
l is aliased to `**ls -alF**'

or

command -V l
l is aliased to `**ls -alF**'

That is the reason for the *

ls is aliased to _ls

type ls
ls is aliased to `**_ls**'

or

command -V ls
ls is aliased to `**_ls**'

_ls is function

type _ls
_ls is a function
**_ls** () 
{ 
    local IFS=' ';
    command ls** $LS_OPTIONS **${1+"$@"}
}

If you unset _ls like this.

unset **_ls**
type **_ls**
bash: type: **_ls**: not found

$LS_OPTIONS are the options for ls that is defined in that function, that is the reason for the colored green for the executables.

echo **"$LS_OPTIONS"**
-N --color=tty -T 0

In the end what you’re really running is

command ls -N --color=tty -T 0 -LaF

Regardless of what terminal emulator you are using.

For that reason it is often nice to put a (production) program in ~/bin. You can then call it without any path added.

In fact you can create a directory anywhere and put your scripts executable in there, just make sure you add that directory to your PATH.
Lets create a Script directory inside “$HOME”.

mkdir  "${HOME}/Scripts"

Then add the code below in your ~/.profile or “${HOME}/.profile”

if  -d "${HOME}/Scripts" ]; then
    PATH=$PATH:$HOME/Scripts
fi

Finally source it.

source  ~/.profile

You can check it now

echo "$PATH"

to find out where the options are defined.

find /etc -type f -exec grep -F '$LS_OPTIONS' {} +
/etc/profile.d/ls.tcsh:    setenv LS_OPTIONS "-A -N $LS_OPTIONS -T 0"
/etc/profile.d/ls.tcsh:    setenv LS_OPTIONS "-N $LS_OPTIONS -T 0"
/etc/profile.d/ls.tcsh:alias ls 'ls $LS_OPTIONS'
/etc/profile.d/ls.bash:        LS_OPTIONS="-A -N $LS_OPTIONS -T 0"
/etc/profile.d/ls.bash:        LS_OPTIONS="-N $LS_OPTIONS -T 0"
/etc/profile.d/ls.bash:         command ls $LS_OPTIONS ${1+"$@"}
/etc/profile.d/ls.bash:         command ls $LS_OPTIONS ${1+"$@"}
/etc/profile.d/ls.bash: *)  alias ls='/bin/ls $LS_OPTIONS' ;;

Any ways those are my two cents :slight_smile:

#16

Thank you to everyone who replied, I suspect it might be a windows file.
Thanks for your help

#17

On 2014-05-02, hcvv <hcvv@no-mx.forums.opensuse.org> wrote:
> A program (any program, binary or script) can only be executed directly
> (e.g. by using it as first word in a command line) when the user doing
> the call has execute rights for the file.

Henk: perhaps I’m misunderstanding you but for Python scripts, this is not case…


sh-4.2$ ls -l *.py
-rwxr-xr-x 1 user users 20 May  6 12:00 hw.py
sh-4.2$ cat hw.py
print "hello world"
sh-4.2$ python hw.py
hello world
sh-4.2$ chmod -x hw.py
sh-4.2$ ls -l *.py
-rw-r--r-- 1 user users 20 May  6 12:00 hw.py
sh-4.2$ python hw.py
hello world
sh-4.2$

… since source code can be executed directly from Python without having to enter a Python shell.

#18

On 05/06/2014 07:10 AM, flymail wrote:
> On 2014-05-02, hcvv <hcvv@no-mx.forums.opensuse.org> wrote:
>> A program (any program, binary or script) can only be executed directly
>> (e.g. by using it as first word in a command line) when the user doing
>> the call has execute rights for the file.
>
> Henk: perhaps I’m misunderstanding you but for Python scripts, this is not case…
>
>


> sh-4.2$ ls -l *.py
> -rwxr-xr-x 1 user users 20 May  6 12:00 hw.py
> sh-4.2$ cat hw.py
> print "hello world"
> sh-4.2$ python hw.py
> hello world
> sh-4.2$ chmod -x hw.py
> sh-4.2$ ls -l *.py
> -rw-r--r-- 1 user users 20 May  6 12:00 hw.py
> sh-4.2$ python hw.py
> hello world
> sh-4.2$
>

>
> … since source code can be executed directly from Python without having to enter a Python shell.
>

I believe its because you are using the interpreter to execute the code,
its like doing bash script.sh where script.sh does not have #!/bin/bash
at the top.

–
Bring the Penguins Back! https://features.opensuse.org/316767
openSUSE 13.1
KDE 4.13.0

#19

For some reason (language barrier? English is not my native language) it seems that I missed completley to make clear to you what I explained.

Calling a python script by using python as you do it:

pyton hw.py

works of course indpendant from having x-permission for hw.py (but you must have r-permission). In that case the x-permission must be on /usr/bin/python, because that is the program that is executed.

When you want to call the program as you call a program “normaly”:

hw.py

you must have x-permission;
you must have the shebang;
your PATH environment variable must have the directory where the hw.py file is, as an item.

That is (of course) true for all programs. Also for python, to take just an example. You can use:

python ...

because:
there is a file named python found in an item of your PATH (in /usr/bin/);
that file/usr/bin/python has x-permission for owner, group and world, thus for you;
that file /usr/bin/python is either a binary executable program, or a script with a correct shebang.

#20

Sorry, I did not see your post because I was composing mine. But what you say is correct.

And even when there is a shebang, it will be ignored when you call it this way. Do not forget that lines starting with a # are comment to bash, sh, ksh, python and more.

BTW in all cases the .py and/or .sh postfixes are purely for your personal satisfaction. For the system they do not have any significance. So please do not let lure you into using them because it is a must. That is not the case and you are free to name your script files as you like (the system is full of scripts in many languages not having such postfixes).