shebang

I have a problem when trying to run a python script on two different computers. On each computer I would like to run the script using python version 2.7.3 however the problem I am having is that the two computers name python 2.7.3 in different ways. One of the computers runs arch linux and on this computer it is named python2. The other computer is running redhat linux and it uses the name python2.7.3. What should I use in the shebang line so that the script is executable on both computers without requiring any changes? What I really want is some sort of conditional shebang line that could

I have a ruby file that does not have a .rb extension, and is instead identified as ruby code with a shebang at the beginning of the file: #!/usr/bin/env ruby . I want to require the code in this file in another ruby file, but it seems to be having a problem because require automatically appends the .rb extension to the files it looks for. Is there any way to suppress this behavior and make require only look for the file as the name is given? Use load instead: load 'file-name' We have scripts the users are allowed to call, which are accessed using symlinks. The symlinks exist in our /usr/local

I have an awk script that I have defined thus: #!/usr/bin/env awk BEGIN { if (!len) len = 1; end = start + len } { for (i = start; i < end; i++) { print $1 } } I have saved it as columns and chmod +x 'd it. I want invoke it so that start and end are defined as it traverses over a file. I was thinking this should work: cat some_file | columns -v start=2 But it doesn't. Help! Try using: #!/usr/bin/awk -f as an interpreter mss env is the easiest way to handle this problem: #!/usr/bin/env -S awk -f to add more options, and to ensure no interference with your arguments, and awk's arguments: #!/usr

I've been using this, but it changes the mimetype to text/x-shellscript , which makes editors like Emacs treat my code like Shell scripts. #!/bin/sh exec scala "$0" "$@" !# Keith Pinson The bangshe (!#) might be the problem I commented out the !# and the following works in my environment: File: hello.sh #!/usr/bin/env scala val name = readLine("What is your name? ") println("Hello " + name + "!") Changed to executable permissions and then ran: chmod a+x hello.scala ./hello.scala As I can test, just #!/usr/bin/env scala !# println("Args: " + args.toList) works fine: ➜ ./test.scala 1 hi Args:

At the beginning of all my executable Python scripts I put the shebang line: #!/usr/bin/env python I'm running these scripts on a system where env python yields a Python 2.2 environment. My scripts quickly fail because I have a manual check for a compatible Python version: if sys.version_info < (2, 4): raise ImportError("Cannot run with Python version < 2.4") I don't want to have to change the shebang line on every executable file, if it's possible; however, I don't have administrative access to the machine to change the result of env python and I don't want to force a particular version, as

What is the reason virtualenv does not associate .py(w) files with virtualenv's version of Python executables? This seems like an ideal task for virtualenv on Windows taking into consideration that there's no mechanism like shebang on Windows. File type associations are handled in the Windows registry. The virtualenv activate script would have to modify the registry keys and the deactivate script would need to restore the previous value (or risk breaking the associations). What happens if you activate a virtualenv, open a second instance of cmd.exe, and activate a different virtualenv? Unless