I'm currently starting to learn Python on Windows 10 and to do so I've installed Geany 1.34.1 and Python 3.7.2 (with the PATH option) as instructed in my book.
I then created a new file and tried to save it in some folder on my C: disk where both softwares are.
Unfortunately, I get the following error
The translaton (original partly in french):
"Error in saving the file. Failure to open the file "C:\Users\XXX\Documents\python_work\test.py" for writing: fopen() has failed: No such file or directory. The file on the disk may be truncated"
I've tried with the Python IDLE as well and get the same problem where I can't save my file.
I've read that it could be due to the fact that in WIN we use \ and in Unix / but I really don't know why Geany can't do alone the translation.
After few hours of hit and miss, does anyone could explain the reason of this behaviour ?
Edit1: Transcription and translation of the error
I think that's because, in python and in other programming languages the "\" is used for some special character.
For ex. '\n' = new line
I'm not really sure, but I think it is for this reason, i had similiar problems at the begin.
Found the problem.
Make sure that the following is deactivated:
Windows Defender > Virus & Threat protection > Virus & Threat protection settings option > Controlled folder access > Disabled
Related
I have made a small (8 MB) program into a MAC executable (.app?)
It works great if I share it using a thumbstick, but if I try to upload it to google drive and then download it it doesn't work. By this I mean It first tells me that It is an unidentified source (this seems reasonable)
But then if I click "open"
It opens as a text file with junk data:
If I try to force it to open on the terminal, how the other program opens, it just shows the heartbeat thing that MACs do when opening a file, but never opens anything.
It is certifiably the same exact file. Same size, same name, same goobldygoop if I open both of them as text files instead of executables.
I am really confused, the only thing I can think of is the "signature" that apple uses is lost when it is compressed into a zip, but I'm probably totally off base.
The code uses python 3.7, pyinstaller, pynput, and selenium.
I am using MAC OS Catalina to write and make into an EXE, then another Catalina to try to run the program.
EDIT: Clarify what doesn't work means
Please help.
I found the answer, simply zip the file from my mac and send it that way!
Yay!
This is such a basic question I am surprised I could not easily find an answer to it:
I use Notepad++ to write my scripts in. Someone sent me some code for a shell script (.sh) that I could modify to suit my needs. I simply changed a small bit of text using Notepad++ (on Windows) and used FileZilla (SFTP) to upload it to my server (Debian Linux).
There were a few problems with this that it took my server admin an hour to find, namely:
FileZilla, for whatever reason, defaults to ASCII rather than binary! (changed it to binary and removed the .sh association with ASCII)
The permissions were wrong, chmod took care of this
Problem is it STILL did not work. To fix it my server admin simply copied the text right on the server (using vim or nano) into a new shell script file and saved that. Before he kept saying the problem was Windows (which he loves to hate on) but it seems it is the encoding that text-editors are using that is corrupting the files.
He said my text-editor encoding needs to be said to "None". However, that is not an option - only ANSI, UTF and UTS variants are options!
How can I create a shell script on Windows with no encoding whatsoever so that it doesn't get corrupted?
I need to be able to simply transfer the file to the server, I can't mess around with modifying it once on the server which is wholly impractical.
To fix it EndOfLine and encoding on Notepad++ :
On the bottom right of Notepad++ you can right click on the left of the encoding "UTF-8" and click on Convert UNIX(LF) format. Be sure to change encoding to UTF-8 if it is not the case.
In Filezilla :
Transfert mode : auto
I have a number of python files with .py extensions that I was working on, closed, and tried to come back to later. When I tried to open them by right clicking and selecting “Edit with IDLE,” instead of opening a pycache folder was created.
I have a work around in which I go to edit the file with Notepad++, copy the text into a new python editor, delete the old file, and resave the new file with the same name. My research has turned up questions related to pycache and IDLE, but none specifically addressing the issue. Has anyone encountered a similar problem/know how to solve it? I’m running Python 3.5.2 on Windows 7.
What did you name the .py file as? If you named it something like "string.py", Python might interpret the file as one of those in the "Lib" folder. Why you can resave it with the same name and have it working afterwards is anyone's guess. I suggest just renaming the python file to something else.
I developed the bad habit of writing/editing python files with IDLE from watching intro videos when I was still relatively new to programming. I have since learned that file editors like Sublime or IDE's like PyCharm are a significantly better way to go and would highly recommend anyone reading this.
I had a similar issue. When I clicked "Edit with IDLE 3.6", it would create a "pycache" folder and not open the python file on IDLE.
I found a Reddit thread that gives an explanation here.
The reason the pycache folder is created is as follows:
When you import a module, Python stores the compiled bytecode in that
directory so that future imports can use it directly, rather than
having to parse and compile the source again. It does not do that for
merely running a script, only when a file is imported.
No such folder is created for the standard library, as the standard
library is pre-cached when you install Python
I was importing Python's "random" library, in another python file (placed in the same directory). So the issue was solved once I deleted that file.
This is related to debugging the issue mentioned in: Plugin (vim-latex) crashing gVim on startup
After installing latex-suite, every time I open a .tex file, whether it's from gVim or terminal vim, whether it contains a \begin statement or not, Vim immediately crashes.
After repeatedly making it crash I was able to read a Python Traceback string in the status line, which mentioned line 530 in C:\Python27\lib\site.py (which only contains known_paths = addusersitepackages(known_paths)), but the rest of the traceback is not viewable since the statusline display truncates it and this only appears for a moment anyway before automatically crashing.
Is there a way I could capture this Traceback output in a more permanent and complete way, along with how things go from this plugin to Python, etc.?
(I tried the -V15filename.log option but it's (as usual) useless, containing some partial log upto an ancient point in the vim startup process.)
Edit: Apologies for not mentioning the OS previously (other than indirectly through the C:\ path), this problem is on Windows. And from the other linked question it seems like almost everyone who tries latex-suite on Windows runs into this problem.
Update: Just a FTR - setting verbosefile doesn't help (presumably because the writes are buffered per the doc), and :redir doesn't capture this either, ends with whatever operation happened before this error and crash.
OK, I put here as an answer.
This answer could be kind of work around for solving your latex plugin problem in windows vim. However if your question sticks to "getting error message before crashing" , it may not give you help. I don't have much experience with windows OS.
Latex Suite plugin uses python to generate some formatted text. It could bring better performance. However the plugin provides no-python ways for that as well, to let user without installing python runtime or with very old python version use the plugin too.
Since you mentioned that your problem was in python codes. You can try disabling python in that plugin, and test if the performance was acceptable.
The plugin provided a variable for that, you could add this line in your vimrc
let g:Tex_UsePython=0
Nice to see it helped.
Did you try to run with redirected stderr?
vim file.tex &> errors.log
or
vim file.tex 2> errors.log
1) If you are able to compile Vim from the source (using MinGW as you are on Windows), you could run it with gdb. Then you could set some breakpoints/check the stack trace until you detect a line near the crash. The instructions to run Vim with the gdb and read the stack traces are found in :help debug-gcc.
At the end of that help file (:help get-ms-debuggers) you can find instructions on how to obtain some debug tools for Windows.
These tools can be used on the following alternatives, explained in detail on :help debug-win32:
2) In case you didn't compile Vim, obtain the debug symbols (PDB), which should be available from the same place that you obtained the executable. Attach Visual Studio to the Vim process, reproduce the crash, then read the stack trace through Visual Studio's dialog reporting the crash.
3) Same as 2) but using WinDbg instead of Visual Studio.
4) Inspect the Minidump file, in case your crash generate one. In addition to the referenced help section, you may find useful information on the following links:
Where to find mini dmp files in windows 7
How to read the small memory dump file
In case you are on a computer running linux, did you try saving the strace output in a file?
strace gvim -V9log.txt file.tex > stdout.txt 2> stderr.txt
And then having a closer look at the output files, especially the last 10-100 lines? I am not sure if it will capture the system calls of the plugins though, but it could be a starting point.
I have built Basic MSI in InstallShield 2011. I have .NET Installer class in my project. When I install the .msi I am getting Error 1001 and rolls back. A temp file "TBD8BEA.tmp" is created in ProgramFiles folder. Temp file has binary content but has a sentence "This program cannot be run in DOS mode." What is the reason for this error and what is the solution. Pls Help me.
The text "This program cannot be run in DOS mode" is the string that is displayed when you try to run a Windows executable in, you guessed it, DOS mode. I would guess that your .tmp file is probably executable. The message is not an error message; rather, it's part of the executable program's data. You can verify this by opening various other executables in a hex editor; that's where I recognized it from.
Other than that, you should probably give some more information and/or examples of what you tried - the question is somewhat on the unspecific side for people to be able to help you.