You are not logged in.

#1 2008-03-05 01:37:58

Xs1t0ry
Member
From: Canada
Registered: 2007-07-01
Posts: 181

Python question

In the tutorial A byte of python, the author opens with an exercise like this

#!/usr/bin/python
# Filename : helloworld.py
print 'Hello World'

My question(s) is what do the first two lines do? In most distros, I guess the command prompt looks like a

$

? In python it is the #, right? This is confusing because the # is also to comment things out in Python. When we Archers are using the CLI, we get a prompt that looks like

[root@myhost]#

so how do we use the # as a short form like other distro users use the $?

Also, my python program is in /usr/lib/python2.5. Is it normal for it to be found in lib? Most sites I visit refer to it in /bin.

Thanks!

Offline

#2 2008-03-05 02:15:49

venox
Member
From: Curitiba, Brazil
Registered: 2003-08-23
Posts: 137
Website

Re: Python question

Xs1t0ry wrote:

My question(s) is what do the first two lines do?

The two first lines are just comments. Although, the first one tells the path to the python interpreter (/usr/bin/python in that case).
You have to add that #! line indicating the path if you want to "chmod +x helloworld.py" and run the script by "./helloworld.py" instead of "python helloworld.py".
The second line does nothing. Really, It's just a comment.

The command prompt is frequently referred as $ for a regular user, and as # for super user (root).
You can put your python script wherever you want. But /usr/lib/python2.5 probably isn't a good place to put it. Try using your home directory instead wink

Last edited by venox (2008-03-05 02:17:14)

Offline

#3 2008-03-05 02:30:57

Borb
Member
Registered: 2006-02-12
Posts: 30

Re: Python question

I think the best thing to put at the top of the file is:

#!/usr/bin/env python

Because that will find Python on a lot more systems.

Offline

#4 2008-03-05 02:39:47

elgatofelix
Member
From: Chile
Registered: 2007-07-03
Posts: 137

Re: Python question

The exercise isnt 'interactive', that's the content of a valid python program (a file).
The first one is a 'flag' to treat your script like a standalone program (always starts with a #!/path/to/the/interpreter)
The second one is just a python comment.

You are confusing the shell prompt (bash), with the python's prompt (when in interactive mode), when u get
the >>> prompt OR when u run a python script (a file) python has the control (or u control python smile)

About the location of python thats ok, the library (that u use with import statement) is located there, surely
the interpreter is in /usr/bin/python


Are u listening?

Offline

#5 2008-03-05 02:41:43

Xs1t0ry
Member
From: Canada
Registered: 2007-07-01
Posts: 181

Re: Python question

Thanks! I understand everything except the #! line. How does that allow you to chmod the script?

Offline

#6 2008-03-05 03:01:17

Allan
Pacman
From: Brisbane, AU
Registered: 2007-06-09
Posts: 11,392
Website

Re: Python question

It does not allow you to chmod the script in itself.  However, once you have done a "chmod +x scriptfile", the first line allows you to run it like "./scriptfile" rather than using "python scriptfile".  So essentially the first line lets your computer know it is to use python as the interpreter.

Offline

#7 2008-03-05 03:01:23

coarseSand
Member
From: Ottawa, Canada
Registered: 2008-02-11
Posts: 203

Re: Python question

It doesn't, that's a Unix shell script line that tells your shell where the interpreter for your script resides (in this case Python). You have to chmod +x manually, but after that it can be run just by typing ./whateverthenameis, or clicking on it in a file manager. Your shell reads the line, and uses that interpreter on your script.

Edit: Great, beaten by six seconds. tongue

Last edited by coarseSand (2008-03-05 03:01:55)


vim? EMACS? Pssh, I code in Scribus.

Offline

#8 2008-03-05 03:25:23

Xs1t0ry
Member
From: Canada
Registered: 2007-07-01
Posts: 181

Re: Python question

Thanks. So you need to specify the interpreter because the computer doesn't know what 'type' of file it is? i.e. like a python script or a C script or a Java script? If so, does that mean the computer ignores file extensions?

Offline

#9 2008-03-05 03:28:18

buttons
Member
From: NJ, USA
Registered: 2007-08-04
Posts: 620

Re: Python question

Xs1t0ry wrote:

Thanks. So you need to specify the interpreter because the computer doesn't know what 'type' of file it is? i.e. like a python script or a C script or a Java script? If so, does that mean the computer ignores file extensions?

Yes.  File extensions don't tell you much, anyway.


Cthulhu For President!

Offline

#10 2008-03-05 03:37:03

Xs1t0ry
Member
From: Canada
Registered: 2007-07-01
Posts: 181

Re: Python question

Oh. That's strange. So then how come if you don't add a proper file extension (like forget to add the .py to a python script) it doesn't work? Granted, I haven't tried to run a program without an extension but with a shebang line. Or would it work as long as you chmod'd it and specified the interpreter in the file?

Offline

#11 2008-03-05 04:00:48

mrcold
Member
Registered: 2008-01-24
Posts: 150

Re: Python question

it will still work without the file extension if it is the only script being run.  However, later when you start importing OTHER scripts that you have written, they will need to have the correct extension for python to know what to do.

all the first line does is tell the computer that this is a python script.  without that line, to run the script you would need to type (from a command line) 'python /home/whatever/script.py'  ( <--- the extension still doesn't matter)
of course, as others have said, you will still need to allow it to run as a program (chmod...)

Offline

#12 2008-03-05 04:02:53

ssjlegendx
Member
Registered: 2008-01-01
Posts: 94
Website

Re: Python question

For more information on the first line, check out this page. Though it seems that you've already gained a better understanding of how file types are handled in Linux, I'm going to give it a quick run-down:

#! is commonly referred to as a shebang. You'll find lines beginning with #! in many scripts (Python, Perl, BASH, etc.). Without the shebang, the file could be invoked with Python explicitly. Assuming you are in the directory that contains your script, you would run:

python ./helloWorld.py

The text directly following the shebang specifies what program should be used to execute the contents of the file (in this case, the Python interpreter). Basically, if your file is named helloWorld.py, issue the following command:

chmod +x ./helloWorld.py

Because you have just made the file executable, you should be able to run the script as follows:

./helloWorld.py

Some other operating systems (perhaps most notably Windows) rely heavily on file extensions to derive this type of information. In Linux, file extensions are perhaps most important to the users themselves (though they might sometimes be used to determine file type). You could just as easily have named the Python script helloWorld.sh or helloWorld.exe (though doing so would have gone against generally-accepted file-naming conventions such as the customary .py for Python scripts).

I'm not quite certain why you ran into issues when not using the .py extension. To the best of my knowledge, including the proper shebang path and making the file executable (with the above chmod command) should allow the script to be run properly (from the command line), despite its file extension.


#!/vim/rocks

Offline

#13 2008-03-05 04:13:28

peets
Member
From: Montreal
Registered: 2007-01-11
Posts: 936
Website

Re: Python question

Welcome to Unix! I like it here.

Offline

#14 2008-03-05 16:04:18

coarseSand
Member
From: Ottawa, Canada
Registered: 2008-02-11
Posts: 203

Re: Python question

You know, I've never understood why ./scriptname runs a script, when all ./ supposedly does is refer to the current working directory. It's a weird convention.

You can also omit the ./ when chmod +x ing or telling an interpreter (python in this case) to run the script. Just os you don't wind up typing ./ all the time, I think I only do it when running a script I'm working on.


vim? EMACS? Pssh, I code in Scribus.

Offline

#15 2008-03-05 16:21:19

FeatherMonkey
Member
Registered: 2007-02-26
Posts: 313

Re: Python question

I stumbled across this on a py script that had been developed for windows, my conclusion in the end went like this.

#!/usr/bin/env python
Now with the /r of windows it failed and wouldn't run though python file.py would.

#!/usr/bin/python
Now this ran it fine with /r

A little one that had me beat till i determined with bash -x \r was the problem. So my conclusion one is using python directly which had no problem with /r but using env it needed a unix/linux newline \n

Perhaps that little snippet helps further.

Offline

#16 2008-03-05 16:36:00

Xs1t0ry
Member
From: Canada
Registered: 2007-07-01
Posts: 181

Re: Python question

Thanks for all your help!

Offline

#17 2008-03-05 18:18:32

moose jaw
Member
From: Milwaukee
Registered: 2007-08-20
Posts: 104

Re: Python question

coarseSand wrote:

You know, I've never understood why ./scriptname runs a script, when all ./ supposedly does is refer to the current working directory. It's a weird convention.

You can also omit the ./ when chmod +x ing or telling an interpreter (python in this case) to run the script. Just os you don't wind up typing ./ all the time, I think I only do it when running a script I'm working on.

It's not just a matter of convention, it's a matter of the shell's PATH variable. If you want to run a script that has been set to +x simply by typing its name (and not, e.g., by typing "python scriptname.py" or whatever), the script has to be located in a directory that's in your shell's PATH environment variable. If the script's location isn't in your PATH, then Bash won't be able to find it, and you'll need to type the full path (or start with "./" if you're already in the directory that contains the script).

Offline

#18 2008-03-05 18:34:53

pauldonnelly
Member
Registered: 2006-06-19
Posts: 776

Re: Python question

coarseSand wrote:

You know, I've never understood why ./scriptname runs a script, when all ./ supposedly does is refer to the current working directory.

If you like, you can add "." to your path, and you'll be able to just type the name.

Offline

#19 2008-03-05 21:27:17

coarseSand
Member
From: Ottawa, Canada
Registered: 2008-02-11
Posts: 203

Re: Python question

moose jaw wrote:

It's not just a matter of convention, it's a matter of the shell's PATH variable. If you want to run a script that has been set to +x simply by typing its name (and not, e.g., by typing "python scriptname.py" or whatever), the script has to be located in a directory that's in your shell's PATH environment variable. If the script's location isn't in your PATH, then Bash won't be able to find it, and you'll need to type the full path (or start with "./" if you're already in the directory that contains the script).

pauldonnelly wrote:

If you like, you can add "." to your path, and you'll be able to just type the name.

Thanks very much moose jaw, that actually does make perfect sense, I hadn't considered the environment variables at all. I just might take paul's suggestion and add . to my PATH.


vim? EMACS? Pssh, I code in Scribus.

Offline

#20 2008-03-06 00:38:24

Xs1t0ry
Member
From: Canada
Registered: 2007-07-01
Posts: 181

Re: Python question

That is a good idea! I went to http://en.wikipedia.org/wiki/Environment_variable#UNIX but I found some of the stuff hard to understand. What exactly is meant by environment variables? I understand the concept of PATH--and how to change it--but this puzzles me

Offline

#21 2008-03-06 00:40:15

elgatofelix
Member
From: Chile
Registered: 2007-07-03
Posts: 137

Re: Python question

coarseSand wrote:
moose jaw wrote:

It's not just a matter of convention, it's a matter of the shell's PATH variable. If you want to run a script that has been set to +x simply by typing its name (and not, e.g., by typing "python scriptname.py" or whatever), the script has to be located in a directory that's in your shell's PATH environment variable. If the script's location isn't in your PATH, then Bash won't be able to find it, and you'll need to type the full path (or start with "./" if you're already in the directory that contains the script).

pauldonnelly wrote:

If you like, you can add "." to your path, and you'll be able to just type the name.

Thanks very much moose jaw, that actually does make perfect sense, I hadn't considered the environment variables at all. I just might take paul's suggestion and add . to my PATH.

Why the "." isn't default in the PATH ? Any cons ?


Are u listening?

Offline

#22 2008-03-06 01:07:13

coarseSand
Member
From: Ottawa, Canada
Registered: 2008-02-11
Posts: 203

Re: Python question

Xs1t0ry wrote:

That is a good idea! I went to http://en.wikipedia.org/wiki/Environment_variable#UNIX but I found some of the stuff hard to understand. What exactly is meant by environment variables? I understand the concept of PATH--and how to change it--but this puzzles me

Here Xs1tory, you might enjoy this. It's a good tutorial for bash commands and scripting. Definitely worth reading through before you start into python.

Reminds me that I stopped at chapter 9 of the scripting part, I really should finish that myself.


vim? EMACS? Pssh, I code in Scribus.

Offline

#23 2008-03-06 01:07:55

Xs1t0ry
Member
From: Canada
Registered: 2007-07-01
Posts: 181

Re: Python question

Thank you!

Offline

#24 2008-03-06 04:37:11

ssjlegendx
Member
Registered: 2008-01-01
Posts: 94
Website

Re: Python question

elgatofelix wrote:

Why the "." isn't default in the PATH ? Any cons ?

Though including . in one's PATH is usually harmless, it can be a security hole of sorts -- especially if it is placed near the beginning of the PATH variable.

For instance, suppose that a user wishes to list the contents of the current directory. Typically, he could do so by issuing a simple ls; however, if a malicious user had somehow placed a "harmful" executable script named ls in the user's current directory, issuing the aforementioned command would actually execute the noxious script!

Again, this issue would only really come into play if . were placed toward the beginning of the user's PATH -- before the directories that contain common utilities and other binaries.

As Mark G. Sobell warns in his book A Practical Guide to Linux Commands, Editors, and Shell Programming, including . in the root user's PATH can create a serious security hole.

Last edited by ssjlegendx (2008-06-18 21:20:46)


#!/vim/rocks

Offline

#25 2008-03-06 06:21:43

Xs1t0ry
Member
From: Canada
Registered: 2007-07-01
Posts: 181

Re: Python question

Interesting

Offline

Board footer

Powered by FluxBB