I have installed urlwatch and I am trying to do the configuration. I am very, very new to python and the command line. I am having issues with urlwatch --edit which returns
Parsing failed:
[WinError 2] El sistema no puede encontrar el archivo especificado
The file C:\Users\HP\AppData\Local\urlwatch\urlwatch\urls.edit.yaml was NOT updated.
Checking the specific path, I cannot find the file urls.edit.yaml. In its place is urlwatch.edit.yaml and in the same folder, urlwatch.yaml. Both seem to be identical.
Running C:\Users\HP\AppData\Local\urlwatch\urlwatch>urlwatch --list, returns
You need to create C:\Users\HP\AppData\Local\urlwatch\urlwatch\urls.yaml in order to use urlwatch.
Use "urlwatch --edit" to open the file with your editor.
So I am moving in circles and not quite understanding what's going on. Any help is appreciated.
To clear any confusion regarding the urlwatch yaml files: There are two main configuration files used by urlwatch. General (non-job-specific) and reporter settings are established within urlwatch.yaml [1]. Jobs themselves are defined within urls.yaml [2].
As far as editing goes: urlwatch --edit will attempt to create/modify the urls.yaml file using the editor specified by the $VISUAL or $EDITOR environment variables [3]. If neither of these are set, that may be part of your problem, and you may want to try setting one of these. For example, if you would like to edit your configurations using Notepad on Windows, you might set the EDITOR environment variable to notepad before running the urlwatch --edit command, after which a new Notepad instance should pop up for you to enter your job configuration(s) into.
If you're having issues using --edit, or finding it cumbersome to mess with environment variables, it may be easier to manually create and populate the file yourself. In your case, it seems your urlwatch configuration should be located within C:\Users\HP\AppData\Local\urlwatch\urlwatch\. You should be able to create a new file called urls.yaml within this folder and edit it yourself using your preferred text editor.
Related
Like I said in the title I don't get what os.getenv("HOME") does in this code. I am following a course on an online site and the tutor was coding an interface with PyQt5 similar to notepad. I searched for an answer but they are a bit too advanced I guess. Also I have no idea what an environment variable is. By the way this is my first question on stack so excuse me for any possible mistakes and insufficient information.
def open_file(self):
file_name=QFileDialog.getOpenFileName(self,"Open File",os.getenv("HOME"))
with open(file_name[0],"r") as file:
self.writing_ar.setText(file.read())
The function above is connected to a button self.open such as self.open.clicked.connect(self.open_file)
And self.writing_ar is a QTextEdit object
In the case of os.getenv('HOME'), it's a UNIX-centric way to get the current user's home directory, which is stored as an environment variable per POSIX specification. A typical home directory location is /Users/yourname on MacOS, or /home/yourname on Linux, or c:\Users\Your Name on Windows -- so that's what this code is trying to look up.
The set of environment variables is effectively a key/value store, mapping strings to other strings, that is copied from any program to other processes it starts; they're thus a way to share configuration and other information between programs (though it only shares information down the tree, propagated only on process creation; changes made by a child process are not seen by its parent; and changes to a parent's environment after a child is started are not seen by the child).
If you want something that works reliably even on Windows, consider os.path.expanduser("~") instead. Thus, your code might become:
file_name = QFileDialog.getOpenFileName(self,
"Open File",
os.path.expanduser("~"))
See also What is the correct cross-platform way to get the home directory in Python?
It basically gets an environment variable for you and cast that onto a python variable.
From the code you shared, there should be a variable defined at the operating system level named HOME.
In Linux, that can be done with
export HOME="something_here"
You can check that this variable has actually been defined by typing
echo "$HOME"
in the terminal.
You can think of the os.getenv() method like it "echoes" the value of that argument onto some variable.
I was thinking of how you execute code only once in Python. What I mean is setup code like when you set-up software; it only happens once and remembers you have already set up the software when you start the program again.
So in a sense I only want Python to execute a function once and not execute the function again even if the program is restarted.
you could create a file once set up is complete for example an empty .txt file and then check if it exists when program runs and if not runs setup
to check weather a file exists you can use os.pathlike so
import os.path
if not os.path.exists(file_path):
#run start up script
file = open (same_name_as_file_path, "w") #creates our file to say startup is complete you could write to this if you wanted as well
file.close
In addition to the method already proposed you may use pickle to save boolean variables representing whether some functions were executed (useful if you have multiple checks to carry out)
import pickle
f1_executed=True
f2_executed=False
pickle.dump([f1_executed,f2_executed],open("executed.pkl",mode='wb'))
##### Program Restarted #####
pickle.load(open("executed.pkl",mode='rb'))
If you need a kind of Setup-Script to install a program or to setup your operating system's environment, then I would go even further. Imagine that your setup became inconsistent in the mean-time and the program does not work properly anymore. Then it would be good to provide the user a script to repair that.
If you execute the script the second time, then you can:
either check, if the setup was correct and print an error message to the user, if the setup became inconsistent in the mean-time
or check the setup and repair it automatically, if inconsistent
Just reading a text file or something similar (f.e. storing a key in the registry of windows) may bring you into the situation that the setup became inconsistent, but your setup-script will say that everything is fine, because the text file (or the registry key) has been found.
Furthermore, if doing so, this facilitates also to "uninstall" your program. Since you know exactly what has been changed for installation, you can revert it by an uninstall script.
I have tried to add a permanent directory from here but i didn't understand how to do it.
The answer states that:
You need to add your new directory to the environment variable PYTHONPATH, separated by a colon from previous contents thereof.
However I pressed the Windows_Start Button and the Pause/Break Button and in Advanced System Settings I went to Environment Variables
AND HERE'S THE PROBLEM
There is no Variable named PYTHONPATH to set-up a value there!!! It must be a bug!
These are the values that exist in my System variables
ComSpec
FP_NO_HOST_CHECK
NUMBER_OF_PROCESSORS
OS
Path
PATHEXT
PROCESSOR_ARCHITECTURE
PROCESSOR_IDENTIFIER
PROCESSOR_LEVER
PROCESSOR_REVISION
PSModulePath
TEMP
TMP
USERNAME
windir
windows_tracing_flags
windows_tracing_logfile
See my problem is that i use sys.path.append() to add the directory but once i restart the GUI i must re-input the command.
The solution aforementioned and linked states that i must find the PYTHONPATH and add the directory there but i have no Environment Variable named PYTHONPATH
How can i run around this problem?
EDIT
Create a file start-my-app.cmd using a text editor (Notepad is good, Word/Wordpad is bad). Copy the code above and replace the parts between ... with what you need. Double click start-my-app.cmd or type start-my-app.cmd in a command prompt (you need to be in the same folder as start-my-app.cmd for this to work). – Aaron Digulla
-->Like this
THIS IS HOW I DID IT. IS IT CORRECT? PLZ TELL ME
Go to Environment Variables
Click the New Button in System Variables
Fill in the variable details
It looks suspiciously easy to me in contrast to the answers i have received but it works and every time i open the GUI i dont have to append the path. If there is anything wrong with this solution plz tell me.
Thank you
You can create a new one; the comment above only means: "If there already is one, don't just overwrote the current value".
That said, I don't like changing global environment variables much. First of all, you must not forget to restart all command prompts because existing ones don't get new variables.
My preferred solution is to create a .cmd/.bat file which contains:
set PYTHONPATH=...whatever your code needs...
python ...and start your Python code here...
That way the variable will be there when you expect it, no matter when and from where you start the script and it will not interfere with other stuff that you might also have.
I need to modify a text file at runtime but restore its original state later (even if the computer crash).
My program runs in regular sessions. Once a session ended, the original state of that file can be changed, but the original state won't change at runtime.
There are several instances of this text file with the same name in several directories. My program runs in each directory (but not in parallel), but depending on the directory content's it does different things. The order of choosing a working directory like this is completely arbitrary.
Since the file's name is the same in each directory, it seems a good idea to store the backed up file in slightly different places (ie. the parent directory name could be appended to the backup target path).
What I do now is backup and restore the file with a self-written class, and also check at startup if the previous backup for the current directory was properly restored.
But my implementation needs serious refactoring, and now I'm interested if there are libraries already implemented for this kind of task.
edit
version control seems like a good idea, but actually it's a bit overkill since it requires network connection and often a server. Other VCS need clients to be installed. I would be happier with a pure-python solution, but at least it should be cross-platform, portable and small enough (<10mb for example).
Why not just do what every unix , mac , window file has done for years -- create a lockfile/working file concept.
When a file is selected for edit:
Check to see if there is an active lock or a crashed backup.
If the file is locked or crashed, give a "recover" option
Otherwise, begin editing the file...
The editing tends to do one or more of a few things:
Copy the original file into a ".%(filename)s.backup"
Create a ".%(filename)s.lock" to prevent others from working on it
When editing is achieved, the lock goes away and the .backup is removed
Sometimes things are slightly reversed, and the original stays in place while a .backup is the active edit; on success the .backup replaces the original
If you crash vi or some other text programs on a linux box, you'll see these files created . note that they usually have a dot(.) prefix so they're normally hidden on the command line. Word/Powerpoint/etc all do similar things.
Implement Version control ... like svn (see pysvn) it should be fast as long as the repo is on the same server... and allows rollbacks to any version of the file... maybe overkill but that will make everything reversible
http://pysvn.tigris.org/docs/pysvn_prog_guide.html
You dont need a server ... you can have local version control and it should be fine...
Git, Subversion or Mercurial is your friend.
I have a Python test suite that creates and deletes many temporary files. Under Windows 7, the shutil.rmtree operations sometimes fail (<1% of the time). The failure is apparently random, not always on the same files, not always in the same way, but it's always on rmtree operations. It seems to be some kind of timing issue. It is also reminiscent of Windows 7's increased vigilance about permissions and administrator rights, but there are no permission issues here (since the code had just created the files), and there are no administrator rights in the mix.
It also looks like a timing issue between two threads or processes, but there is no concurrency here either.
Two examples of (partial) stack traces:
File "C:\ned\coverage\trunk\test\test_farm.py", line 298, in clean
shutil.rmtree(cleandir)
File "c:\python23\lib\shutil.py", line 142, in rmtree
raise exc[0], (exc[1][0], exc[1][1] + ' removing '+arg)
WindowsError: [Errno 5] Access is denied removing xml_1
File "C:\ned\coverage\trunk\test\test_farm.py", line 298, in clean
shutil.rmtree(cleandir)
File "c:\python23\lib\shutil.py", line 142, in rmtree
raise exc[0], (exc[1][0], exc[1][1] + ' removing '+arg)
WindowsError: [Errno 3] The system cannot find the path specified removing out
On Windows XP, it never failed. On Windows 7, it fails like this, across a few different Python versions (2.3-2.6, not sure about 3.1).
Anyone seen anything like this and have a solution? The code itself is on bitbucket for the truly industrious.
It's a long shot, but are you running anything that scans directories in the background? I'm thinking antivirus/backup (maybe Windows 7 has something like that built in? I don't know). I have experienced occasional glitches when deleting/moving files from the TSVNCache.exe process that TortoiseSVN starts -- seems it watches directories for changes, then presumably opens them for scanning the files.
We had similar problems with shutil.rmtree on Windows, particularly looking like your first stack trace. We solved it by using an exception handler with rmtree. See this answer for details.
Just a thought, but if the test behavior (creating and deleting lots of temp files) isn't typical of what the app actually does, maybe you could move those test file operations to (c)StringIO, and keep a suite of function tests that exercises your app's actual file creation/deletion behavior.
That way, you can make sure that your app behaves correctly, without introducing extra complexity not related to the app.
My guess is that you should check up on the code that creates the file, and make SURE they are closed explicitly before moving on to delete it. If nothing is obvious there in the code, download a copy of Process Monitor and watch what's happening on the file system there. This tool will give you the exact error code coming from Windows, and should shed some light on the situation.
That "The system cannot find the path specified:" error will appear intermittently if the path is too long for Windows (260 chars). Automated tasks often create folder hierarchies using relative references that produce fully qualified paths longer than 260 characters. Any script that attempts to delete those folders using fully qualified paths will fail.
I built a quick workaround that used relative path references, but don't have generic code solution to offer, just a warning that the excellent answers provided might not help you.
I met same problem with shutil.rmtree command and this issue maybe cause by special file name.(Ex:Other country language:леме / Ö)
Please use the following format to delete the directory which you want:
import shutil
shutil.rmtree(os.path.join("<folder_name>").decode('ascii'))
Enjoy it !