Run a python script and the #!/usr/bin/python line

[pascor]

I'm coming from the MSW development world and a few things in linux/ubuntu for "getting things done" have got me stumped.

If I have my python app in "/usr/local/pyscripts" named "myapp.py", how can I set up things so that I can run it from anywhere on the command line by simply giving the command "myapp arg1 arg2 arg3" ? (I can write bash scripts and set aliases if necessary.)

What (good) is the shebang line for in Python scripts ? What part of the OS uses it ?

TIA :-)

[Mariostg]

/usr/local/pyscripts must be in your path which you can set in your .bashrc file.
The shebang thells which python your script will be executed with. So you could have python using python 3 and another one using python 2.7. Very common on Arch Linux, probably others too.

[pascor]

As it turns out, the shebang is somewhat useful only when running during development. Considering its 2 requirements it is far more direct to simply use the command line like :
$ python myapp.py

The shebang line is useless for trying to run myapp.py giving only :
$ myapp

Using the utility cxfreeze is a way [ the only known way ?] to be able to create any kind of executable and be able to place it in an existing dir on PATH such as /usr/local/bin . Once the file [myapp ] is marked as executable I can then run the command :

$ myapp arg1 arg2 ...

from anywhere with no dependencies or further setup.


Thanks

[numberwhun]

@pascor: I think there is some confusion. The shebang line refers to the location of the Python interpreter. It has no bearing on where your script is located, or whether or not you have to use the full path to execute the script. Its simply telling the script immediately, where it can find python. That way you don't need to use the "python <script name>" method of execution. If you move the script to a system that has python installed in a different location, then you would simply need to modify the shebang to point to that location.

That limitation is able to be circumvented by using the following shebang line in your scripts:

#!/usr/bin/env python
 

That way, no matter what *nix system you put the script on, it will invoke the env command with the python option, finding the interpreter immediately. This may also solve your issue of the shebang line not working after you create your executable, but not sure it will solve it for a Windows platform.

Now, as for your ability to execute the script without the absolute path, @Mariostg was correct about modifying your PATH variable to include the directory in your search PATH.

Regards,

Jeff

[pascor]

Thanks - I got it working now. I haven't yet found all the conditions necessary to get shebang lines to work documented all in one place.

I find it very unfortunate that to execute a local script (python, bash, etc.) the prefix "./" must be added to the script filename. This seems pointless and counter-productive as well as being the exact opposite that all Window OSs, python, C compilers, etc., check to locate files.

All in all, I find it easier to create a true executable using cx-freeze and then put it in /usr/local/bin, which is already in PATH. Despite these files being 1MB+ in size, these apps can be run from any working directory and solve my desire to have to give only the command "myapp arg1, arg2 ...". Hard drive space is very inexpensive, unlike during the not-so-distant past.

[dwblas]

I find it very unfortunate that to execute a local script (python, bash, etc.) the prefix "./" must be added to the script filename.

As Mariostg already stated, the only paths that are searched are the ones in the .bashrc file's PATH. If your program is in a directory that is searched, i.e. in the PATH, then you can just enter the file name. On Linux you can choose what you want the system to do instead of having all of the decisions made for you.

[Mariostg]

I find it very unfortunate that to execute a local script (python, bash, etc.) the prefix "./" must be added to the script filename. This seems pointless and counter-productive as well as being the exact opposite that all Window OSs, python, C compilers, etc., check to locate files.

I suggest you do a little bit of searching on the topic. It is a security issue. You can modify your $PATH to include the current directory if you want. If you do it, don't do it for root.

[pascor]

Adding every development directory to the PATH is just not feasible or even reasonable. I create them/use them/delete them much too often.

Is there a way to automatically add the CWD to PATH without creating duplicate entries ? In other words, how can I get the OS check the CWD *first* to search for files ?

[Mariostg]

Current directory = . (dot). Therefore, include . in your $PATH. PATH (wikipedia). But you have been warned.

[pascor]

But you have been warned. 

Why do you say this ?

[numberwhun]

If you would like to know the reasoning behind why dot is a bad thing to have in the PATH variable, then read this.

As per the article, if you do decide to add it to your path, only add it at the end and not the beginning of the PATH variable. You could simply put this in your .bashrc and open another window:

PATH = $PATH:.
 

But know that myself and probably most other unix people here are just fine with putting the ./ before our scripts. We don't find it to be an issue because:

#1. We know the security risks behind it and
#2. Most importantly, this isn't a Windows system. Windows is insecure (IMHO) because of its lax nature of how it does things. You aren't going to make this Windows and are just going to have to deal with the nuances of it. They are there for a reason.

Regards,

Jeff

[pascor]

Security (and the lack there of) and the OS getting programs in PATH mixed up generally have nothing to do with each other.

This forum isn't the place to flame Windows security issues. There are plenty of other places to do that.

[numberwhun]

Believe me, I wasn't flaming Windows, I was pointing out what, in my opinion, is a fact. You made the comparison to Windows in post #5 above, I just added an observation to it.

Further to that, we definitely need to get the point across that searching the current directory first is extremely insecure and should not be done. Personally I would stick to using the ./ in front o things, and always do, versus adding the current directory to my path. Don't learn that lesson the hard way, it can wreak havoc.

[Mariostg]

Really pascor how much time did you spent researching about your problem? Did you even bother looking at the links that were provided to you? I sincerely believe all replies provided to your queries are fair. There are several exemples on the internet about the nasty things that could happen if you set your current directory in the path. As @Numberwhun
said, if you want it in your path, put it last. It is a wise advise.

[pascor]

The security issues amount to just 2 potential problems:

1 - If a user is stupid enough to name a program the same as an already existing program or script name. This implies the user is only slightly smarter than a head of cabbage and doesn't first use the [ which ] utility to avoid name duplications.

2 - If the system is hacked. This implies that the OS is inherently unsafe, anyway, and much more anti-malware protection is needed.

Since I'm not a professional developer, I think the risks are minimal.

[numberwhun]

They would not have the security warnings against something if it wasn't a concern. You would think that people wouldn't do it, but it happens. Heck, people alias things all the time and get themselves in trouble without even knowing it. Users are the inherent threat that all sys admins guard against, its just the way things go. Doesn't matter the OS, the user is the reason for rules most of the time.

I am not going to go any further with this. You have been given the articles to read on the security risks and the system you are working on is yours. If you take the risk then you have nobody to blame but yourself if something goes wrong. We can only give you advice.

Regards,

Jeff