I've been writing a Tkinter program and I don't want the console to show, so I used a .pyw file. However the program ran with an error that said the program could run usr/bin/python3, so I removed the shebang line, and it worked, but do I need a shebang line? Or should I keep it as is.
If it works without the shebang line:
Your computer found a version of Python to run it (likely in your "PATH" environment variables).
If it didn't work with the shebang line, either:
You made a typo, or
You gave it an incorrect path to your version of Python
Make sure you know exactly where Python is installed on your device:
Mac/Linux
Windows
(To anyone simply copy-pasting what you see in tutorials - without a good grasp of what it's doing: Try googling terms like "shebang line" and figure out what they might be doing behind the scenes)
Related
I have a Python virtual environment on my linux machine. It has been working fine for two weeks, but all of a sudden I woke up today, and while in the environment I can't execute any commands. For example, if I try to use pip list, or jupyter notebook, this is what I get (env is the name of my environment):
~/env/bin$ pip list
-bash: /home/ubuntu/env/bin/pip: /home/ubuntu/env/bin/python: bad interpreter: No such file or directory
The same thing happens with basically any other command, except Python. Typing python brings up the Python shell just fine. Interestingly it says Anaconda though, when I only used pip with this environment.
I've tried to find info on this but they all seem to be pertaining to running scripts.
Edit: Also want to mention that when I manually look in the environment bin, the packages I installed are all there in green, except Python is in red.
Thank you in advance.
You have a script /home/ubuntu/env/bin/pip and the script has shebang #!/home/ubuntu/env/bin/python but the file is either absent or is not executable.
Check if the file /home/ubuntu/env/bin/python exist. Check if it can be executed by the current user (just run it from the command line). If not — you need to find out a working executable (for example, it could be /home/ubuntu/env/bin/python3), edit the first line of /home/ubuntu/env/bin/pip to fix the shebang.
In advance, sorry if this is question ought be on SuperUser or another site
The python3 shebang doesn't seem to work on win10. (I cant check right now, but I believe the analogous approach worked on MacOS for me last night). Consider the following
#!/usr/bin/env python3
print("hello world")
Leads to the error 'python' is not recognized as an internal or external command,
operable program or batch file. This makes sense because I only have a python3 distro on my machine (which can only be called like python3). However, Atom seems to be ignoring the shebang altogether. FYI, I'm running the script with the popular "script" atom package.
I've tried the permutation, #!/usr/bin python3, but this doesn't work either.
I've tried permutations
I'm still interested in how shebangs work within the Atom environment, but as far as getting python3 up and running, you dont need a shebang. You can simply change a config file (python.coffee) from within Atom, then relaunch. See Daniel Chamorro's excellent answer here: How to setup Atom's script to run Python 3.x scripts? May the combination with Windows 7 Pro x64 be the issue?
Well, i wrote a simple "hello world" in julia, but i cannot figure out on how to run the code. I've tried to run by ./nameOfMyFile.jl and the terminal returned to me that I have syntax errors.
My code is just:
println("hello world")
Wich works perfectly if i run julia on the terminal and write the code after that...
The error is something like( I am translating it from portuguese):
./hello_world.jl: line 1:syntax error close to the unexpected token `"hello world"
./hello_world.jl: line 1: `println("hello world")'
I'm using vim, debian 8 and julia 0.3.2
If you want to execute it directly from the terminal you can add a shebang to the beggining of your script i.e.
#!/usr/bin/env julia
println("hello world")
and then make it executable using chmod
[user#computer]$ chmod +x hello
then it should run as expected :)
./hello
will print "hello world" to your terminal :)
Two ways I can think of to achieve what you want
Open a terminal and do either one of the following
Inside the julia relp, that is, if you run julia in the terminal by running
julia
and when you're in, do
include("nameoffile.jl")
if you simple want to run the file, in the terminal do
julia nameoffile.jl
Based on discussions on GitHub like this one it sounds like this issue is more due to the shell than to Julia. Nevertheless, I would strongly recommend upgrading to the latest version of Julia, 0.4.6. The version that you are using is quite old and lacks a lot of improvements, including ones addressing issues at least similar to what you are experiencing.
Just got emacs24.4 compiled and try to run it in daemon mode.
OS: Ubuntu 14.04
In terminal:
When I run it with "emacs -Q --daemon" everything works fine. But when I run it with "emacs --daemon", it doesn't return to shell (emacs24.3 works fine).
Is there any easy way to debug what's wrong in the init file which works fine for 24.3 but not 24.4?
Recursively bisect your init file, to find out what the culprit code is. You can do this by commenting out 1/2 of it, then 3/4 of it, then 7/8, then 15/16,... IOW, a binary search - it is very quick.
You can use command comment-region to comment or (with C-u) to uncomment the region. (I bind it to C-x C-;.)
Then remember this answer. It applies to any problem introduced by your init file.
Everything in your question that has to do with "Emacs 24.4" and "daemon" and "shell" only becomes relevant (if it is) after you have narrowed things down to find just what code is responsible for introducing the bad behavior.Once you do that, if the solution to what remains is not obvious, then please post another (new) question here that covers the relevant info, whether it be Emacs 24.4, shell, daemon, or whatever.
I have an escript file which runs fine from the command line, i.e.:
./escript_file
It is meant to be cron friendly and all paths are explicit but when I run it, it fails to compile saying that there are bad attributes.
The bad attributes in question are macro definitions:
-define(COOKIE, 'somecookie').
The Answer
Thanks to Geoff Ready's suggestion I investigated which version of Erlang was running by printing out init:script_id() which prints out a string like {"OPT APN 181 O1", "R13B"} and, sure enough the command line and cron versions were picking up different versions.
The script had an initial line:
#!/usr/bin/env escript
and the operating system was 'finding' Erlang for me. The different environment variables of cron meant that a different erlang was being picked up (Geoff's first answer, and one I kinda knew but couldn't see how it would affect things).
The solution is then to force the version with a starting line of:
#!/usr/local/lib/erlang/erts-5.7.3/bin/escript
Postscript
There was also a different Ubuntu apt-get install of an earlier version of Erlang (in a different location to the source install) and an errant 64-bit install...
The cron environment just kept falling back to older and more obscure installs, failing all the while :(
Perhaps cron is picking up a different version of erlang in the path. Erlang R12B documentation says that escript ignores preprocessor directives besides include_lib. Erlang R13B documentation says that the preprocessor is run on the file. That would definitely explain the difference in behavior.
If it is working fine from the command line, a likely cause is a difference in environment variables for your interactive shell versus when cron runs the script.
Changing #!/usr/bin/env escript to #!/usr/local/bin/escript at the top of the file will work if the Erlang versions are the same.