VIM [new file] message appears when file already exists - vim

I'm trying to view the following node logs on my server:
However, when I run vim 2020-10-11T00_31_14_122Z-debug.log - It's creating a new file rather than acknowledging the existing one:
Am I missing something blatantly trivial?

Please be sure you are running the code from the correct folder or the path leads you to the file you want, once the path is correct you might use auto-complete which will give you the file easier and faster.

Related

Check if file has been changed and which line in file

I am looking some solutions which help me to track any changes which have been made on files. I am working on Linux system where a lot of people have access to the same files. Sometimes it is happened, that someone changed something in file and don't notify other users. So I would like to write some script to check if provide file path or files have been changed, if so then write in file let's say "controlfile_File1.txt" something like that "File changed %date, line XXX". I know that I can use md5checksum for that, but I will get only info if file changed but I would like to know which line is changed. I also think about solution to make copy of this file to some place and make some diff between copied file and current file?
Any ideas?
thanks for support.
Your question goes above the possibilities of Linux as a platform: Linux can show you the last modification date of a file, and the last time a file has been accessed (even without modifying the file), but that's it.
What are you are looking for, as already mentioned in the comments, is a version control system. As mentioned indeed, Git is one of them, but there are also others (SourceTree, SourceSafe, Clearcase, ...) each of them having their (dis)advantages.
One thing they all have in common is that modifying such a file does not go that simply anymore: at every time somebody has modified such a file (a file under the version control system), (s)he will be asked why (s)he has done this, this will also be recorded for later reference.

Could someone explain why cmd's 'where' does not find this file please?

Boiled down issue:
Background:
I am trying to get opencv4nodejs to install and am running into errors like opencv2/core.hpp file not found.
Digging into this, knowing full well that I have installed the appropriate files in C:\tools, and added all the required paths and refreshed my cmd.exe to reflect this, I am still getting hit with errors.
Question:
Could someone please describe why the above commands would lead to cmd.exe being unable to find the file I need?
The first dir %OPENCV_INCLUDE_DIR%opencv2\core.hpp command clearly shows that it exists within the environment of the console. Note: This variable has been appended to PATH as %OPENCV_INCLUDE_DIR%
The where opencv2\core.hpp cannot find it, much like my other program cannot find it. I am a bit of a cmd noob, so I may be missing something obvious here, but how can this be the case?
Thanks!

PyCharm project path different from interactive session path

When running an interactive session, PyCharm thinks of os.getcwd() as my project's directory. However, when I run my script from the command line, PyCharm thinks of os.getcwd() as the directory of the script.
Is there a good workaround for this? Here is what I tried and did not like:
going to Run/Edit Configurations and changing the working directory manually. I did not like this solution, because I will have to do it for every script that I run.
having one line in my code that "fixes" the path for the purposes of interactive sessions and commenting it out before running from command line. This works, but feels wrong.
Is there a way to do this or is it just the way it is supposed to be? Maybe I shouldn't be trying to run random scripts within my project?
Any insight would be greatly appreciated.
Clarification:
By "interactive session" I mean being able to run each line individually in a Python/IPython Console
By "running from command line" I mean creating a script my_script.py and running python path_to_myscript/my_script.py (I actually press the Run button at PyCharm, but I think it's the same).
Other facts that might prove worth mentioning:
I have created a PyCharm project. This contains (among other things) the package Graphs, which contains the module Graph and some .txt files. When I do something within my Graph module (e.g. read a graph from a file), I like to test that things worked as expected. I do this by running a selection of lines (interactively). To read a .txt file, I have to go (using os.path.join()) from the current working directory (the project directory, ...\\project_name) to the module's directory ...\\project_name\\Graphs, where the file is located. However, when I run the whole script via the command line, the command reading the .txt file raises an Error, complaining that no file was found. By looking on the name of the file that was not found, I see that the full file name is something like this:
...\\project_name\\Graphs\\Graphs\\graph1.txt
It seems that this time the current working directory is ...\\project_name\\Graphs\\, and my os.path.join() command actually spoils it.
I user various methods in my python scripts.
set the working directory as first step of your code using os.chdir(some_existing_path)
This would mean all your other paths should be referenced to this, as you hard set the path. You just need to make sure it works from any location and your specifically in your IDE. Obviously, another os.chdir() would change the working directory and os.getcwd() would return the new working directory
set the working directory to __file__ by using os.chdir(os.path.dirname(__file__))
This is actually what I use most, as it is quite reliable, and then I reference all further paths or file operations to this. Or you can simply refer to as os.path.dirname(__file__) in your code without actually changing the working directory
get the working directory using os.getcwd()
And reference all path and file operations to this, knowing it will change based on how the script is launched. Note: do NOT assume that this returns the location of your script, it returns the working directory of the shell !!
[EDIT based on new information]
By "interactive session" I mean being able to run each line
individually in a Python/IPython Console
By running interactively line-by-line in a Python console, the __file__ is not defined, afterall: you are not executing a file. Hence you cannot use os.path.dirname(__file__) you will have to use something like os.chdir(some_known_existing_dir) to reference a path. As a programmer you need to be very aware of working directory and changes to this, your code should reflect that.
By "running from command line" I mean creating a script my_script.py
and running python path_to_myscript/my_script.py (I actually press the
Run button at PyCharm, but I think it's the same).
This, both executing a .py from command line as well as running in your IDE, will populate the __file__, hence you can use os.path.dirname(__file__)
HTH
I am purposely adding another answer to this post, in regards the following:
Other facts that might prove worth mentioning:
I have created a PyCharm project. This contains (among other things)
the package Graphs, which contains the module Graph and some .txt
files. When I do something within my Graph module (e.g. read a graph
from a file), I like to test that things worked as expected. I do this
by running a selection of lines (interactively). To read a .txt file,
I have to go (using os.path.join()) from the current working directory
(the project directory, ...\project_name) to the module's directory
...\project_name\Graphs, where the file is located. However, when I
run the whole script via the command line, the command reading the
.txt file raises an Error, complaining that no file was found. By
looking on the name of the file that was not found, I see that the
full file name is something like this:
...\project_name\Graphs\Graphs\graph1.txt It seems that this time
the current working directory is ...\project_name\Graphs\, and my
os.path.join() command actually spoils it.
I strongly believe that if a python script takes input from any file, that the author of the script needs to cater for this in the script.
What I mean is you as the author need to make sure you know the following regardless of how your script is executed:
What is the working directory
What is the script directory
These two you have no control over when you hand off your script to others, or run it on other peoples machines. The working directory is dependent on how the script is launched. It seems that you run on Windows, so here is an example:
C:\> c:\python\python your_script.py
The working directory is now C:\ if your_script.py is in C:\
C:\some_dir\another_dir\> c:\python\python.exe c:\your_script_dir\your_script.py
The working directory is now C:\some_dir\another_dir
And the above example may even give different results if the SYSTEM PATH variable is set to the path of the location of your_script.py
You need to ensure that your script works even if the user(s) of your script are placing this in various locations on their machines. Some people (and I don't know why) tend to put everything on the Desktop. You need to ensure your script can cope with this, including any spaces in the path name.
Furthermore, if your script is taking input from a file, the you as the author need to ensure that you can cope with changes in working directory, and changes of script directory. There are a few things you may consider:
Have your script input from a known (static) directory, something like C:\python_input\
Have your script input from a known (configurable) directory, use ConfigParser, you can search here on stackoverflow on many posts
Have your script input from a known directory related to the location of the script (using os.path.dirname(__file__))
any other method you may employ to ensure your script can get to the input
Ultimately this is all in your control, and you need to code to ensure it is working.
HTH,
Edwin.

_vimrc getting renamed to _vimrc.2014

I noticed that for whatever reason, my _vimrc wasn't being loaded this morning. I keep my entire vim directory saved to my Google Drive to the location I specify in my _vimrc. I didn't worry about it since I'd recently backed it up, but now when I dump it into my vim folder, whenever I start up gVim, it looks like it renames it to _vimrc.2014.
I can't find anything about this behavior, is it normal? It doesn't really affect me too much since it still gets source, but I just want to know why it's doing that.
Vim certainly is not doing this. I'm not certain it's causing YOUR problem, but Google Drive has problems replacing files with a new file of the same name. Under the hood, that is exactly what Vim is doing when it writes a file with default settings. See https://groups.google.com/d/topic/vim_use/jkw_nnHz9cE/discussion : you can use either the 'backupskip' or 'writebackup' options to force Vim to write the file directly instead of replacing it with a new file when editing inside your Google Drive folder. I'm using this line in my .vimrc to accomplish the task:
let &backupskip.=','.expand('$HOME/Google\ Drive/').'*'

Find: Parameter format not correct

I keep hearing this is a path issue with cygwin. It is prevent emacs from working within my cygwin. When I execute find on the cli (not bash/cygwin) I get the same error not matter what I type. I've read this is a problem with path creation within cygwin and that it should be prepending itself to the path. As you can see it is doing that.
Here is my /etc/profile
PATH=/usr/local/bin:/usr/bin:/bin:$PATH
export PATH
Problem is that as everyone else stated, emacs is using find.exe provided by windows. To change this, you need to change your %userprofile%.emacs file.
As nobody else states (even faq!), this file is not created automatically anymore. Go into Options > Save options the mini-buffer (one line at the bottom of emacs) will tell you where the file is being written to.
Go in there and add this line (You've installed cygwin at c:\cygwin, right?):
(setq find-program "C:\\cygwin\\bin\\find.exe")
You may need to restart Emacs for this to take effect.
Just add this line to you .profile
alias find='/cygdrive/c/cygwin/bin/find.exe'
Oddly-enough, I needed to use
(setq find-program "/bin/find.exe")
instead.
But thanks for the suggestion Drew.
Adding a setq find-program [msys2 or git path] in my init file, as suggested (I tried different forms), didn't work for me. "C:\Windows\System32\find.exe" is first in the path if I type where find in eshell and I didn't find how to remove it, only how to add others, which doesn't solve the problem.
So I share here the more radical, but working (also in Powershell), solution I used: replacing the find.exe in "C:\Windows\System32" with the one from "C:\msys64\usr\bin". I kept the old file in case, but so far so good. You need to change the permissions for this operation (see here how to gain full control, but I suggest only applying this to the file, not the whole folder, and putting things back after ;)).

Resources