I want gnuplot to load an initialization file on startup. According to the manual, in Windows systems, it is called GNUPLOT.INI. (It shouldn't matter if I call it gnuplot.ini, right? I tried both, though.)
According to answers like here: gnuplot configuration file
I'm supposed to put a file called gnuplot.ini in my HOME directory, and then everything should work. (Alternatively, see the manual at http://www.gnuplot.info/docs_4.6/gnuplot.pdf, page 38.)
1) What is a "HOME" directory in Windows? Where is it in Windows 7?
2) The manual mentions that I could change this default directory by changing the environment variable GNUPLOT. But it doesn't explain how to change environment variables in gnuplot, or even really what they are.
Basically, everyone refers me to the section in the manual, which I don't understand.
Furthermore, also from the manual: "When gnuplot is run, it first looks for a system-wide initialization fi le named gnuplotrc. The location of this fi le is determined when the program is built and is reported by show loadpath."
If I run "show loadpath" in gnuplot, it says:
"loadpath from GNUPLOT_LIB is "C:\Program Files (x86)\gnuplot\demo"
gnuplotrc is read from share"
1) There is no file called gnuplotrc in that folder.
2) No file ending is specified. Does the manual refer to x.gnuplotrc or gnuplotrc.x or something else?
3) Also, what does "read from share" mean?
I appreciate your help.
I finally managed to solve the problem above. Maybe this solution can help someone else. So:
1) The HOME directory of your OS can be found here: http://en.wikipedia.org/wiki/Home_directory.
2) Even after putting a file called gnuplot.ini into my HOME directory, gnuplot didn't consistently initialize with it. In fact, it only did it once, and I still don't know why.
3) The cryptic message "gnuplotrc is read from share" actually means that gnuplot searches for the initialization file "gnuplotrc" (without file ending) in the folder (install directory of gnuplot) \ share .
4) Placing the file called "gnuplotrc" into the folder (install directory of gnuplot) \share\ finally worked. Now gnuplot initializes from this file every time I restart gnuplot.
An update:
Other non-Linux users may be as unaware of what the "home directory" of an OS is as myself. Wikipedia finally gave me the answer here: http://en.wikipedia.org/wiki/Home_directory
So the Home directory in Windows 7 was (root) \Users\ (username).
Then I placed my gnuplot.ini in that folder, and when I started wgnuplot.exe and typed "plot sin(x)", it finally had the settings I wanted.
I thought I had finally solved my problem. I closed gnuplot. Then I changed a line in gnuplot.ini, saved it, and afterwards started gnuplot again. gnuplot was wholly unaffected by my change in gnuplot.ini. (I verified this with the option "show all".)
So as far as I can tell, I managed to correctly initialize gnuplot ONCE, but it doesn't properly intialize via gnuplot.ini every time?! What gives?
On windows, add the following line at the end of gnuplotrc:
load "C:\\Users\\username\\GNUPLOT.INI"
(replacing "username" with your user name, and with doubled backslashes !)
then you can put your GNUPLOT.INI file in your home directory
Related
I am trying to setup gnuplot so that at startup I always have the comma as datafile separator, with the following command:
set datafile separator ","
Unfortunately, it looks like there's no concept of a .gnuplotrc in gnuplot. At least I didn't find anything in the man page, and I don't have strace on this machine so I cannot see by myself. I am tired of typing the command every time I fire up gnuplot. Does anybody have a good solution for this? Note that using load does not solve my issue: I would still have to type the load command.
In fact, there is a gnuplot startup file: it's called .gnuplot, and should do exactly what you want. For details, try running help startup within an interactive gnuplot session.
18 Start-up
When gnuplot is run, it looks for an initialization file to load. This file is called .gnuplot on Unix and AmigaOS systems, and GNUPLOT.INI on other systems. If this file is not found in the current directory, the program will look for it in the HOME directory (under AmigaOS, Atari(single)TOS, MS-DOS, Windows and OS/2, the environment variable GNUPLOT should contain the name of this directory; on Windows NT, it will use USERPROFILE if GNUPLOT isn’t defined). Note: if NOCWDRC is defined during the installation, gnuplot will not read from the current directory.
If the initialization file is found, gnuplot executes the commands in it. These may be any legal gnuplot commands, but typically they are limited to setting the terminal and defining frequently-used functions or variables.
http://www.gnuplot.info/docs_4.2/gnuplot.html#x1-6900018
For the new version of gnuplot try this:
See the path of the gnuplotrc file using the command within gnuplot:
show loadpath
Then just open the file and add the commands you want.
Here is more info from the the [documentation][1] of the latest version(**4.6**):
When gnuplot is run, it first looks for a system-wide initialization file named gnuplotrc. The location of this file is determined when the program is built and is reported by show loadpath. The program then looks in the user’s HOME directory for a file called .gnuplot on Unix-like systems or GNUPLOT.INI on other systems. (Windows and OS/2 will look for it in the directory named in the environment variable GNUPLOT; Windows will use USERPROFILE if GNUPLOT is not defined). Note: The program can be configured to look first in the current directory, but this is not recommended because it is bad security practice.
Generally on windows, the main configuration file GNUPLOT.INI is loaded by a command in gnuplotrc. This way you can change the location of GNUPLOT.INI
But in addition to GNUPLOT.INI, there is also a separate configuration file for the widows terminal. It is called wgnuplot.ini and it can be found in the %APPDATA% directory. You can create it manually if it does not exist.
This file is updated automatically when you select "update .." at the bottom of the right-click menu of the terminal console. This way, you can change e.g. the font size of that terminal.
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.
I am trying to edit the corflags file so that I can run 32bit applications on a 64 bit pc but everytime I try to edit the file using something like corflags.exe assembly /32bit+ it comes up with the error message cf001 could not open file for writing.
Now I have tried a lot of different options such as:
Running in administrator mode;
Finding the file using a search and checking read only is not ticked
Checking that user full control is ticked
Tried to set the whole folder to non read only
When trying the whole folder, it goes through looking like it has set read-only, but then I click OK and re-right click on the whole folder, the box is filled in (not ticked) does this mean that part of the folder is read only and why does it reset to read only?
I just faced the same problem and have tried the same things.
Run cornflags from an elevated ("Run as administrator") Visual Studio Command Prompt. I did the same for a copy of the original .exe just to make sure no other process was using the program.
Create a copy of the file you intend to target with CorFlags.
(e.g. "WcfServiceHost.exe" --creates--> "WcfServiceHost - Copy.exe")
Rename the original file to something else:
(e.g. "WcfServiceHost.exe" --> "WcfServiceHose_Original.exe")
Rename to copy to the original file name
(e.g. "WcfServiceHose - Copy.exe" --> "WcfServiceHost.exe"
For my purposes, I created copies and named them describing their configuration:
Example:
WCFServiceHost_With32BitOn.exe
WCFServiceHost_With32BitOff.exe
Now I can destroy the WCFServiceHost.exe files and create them from these pre-modified copies. No more CorFlags operations necessary.
Note: this is basically a more verbose version of #RMalke answer and that answer should be marked as the answer.
I realise this is years later, but for anyone else looking, I found that the quickest way was to copy cmd and corflags.exe into the same folder as the one you want to edit. Then run cmd as admin from there.
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 ;)).
When I load GVim from the Cygwin command line or when I'm not connected to the office network (mapped to U:/) it loads instantaneously. It takes a good minute or so to open when I'm on the network. What is going on here?
You probably need to set your $HOME directory to something other than U:/. Create a $HOME environment variable for Windows that points to My Documents or whatever and it won't try and use U:/. You may need to log-off/log-in to pick up the changes.
You should check what your $HOME directory is mapped to in each case. I bet that it is different depending on if you are connected to the network or not.
Do you have any custom .vimrc or other config files read at startup? If nothing else, vim will query your $HOME directory to look for such files. If your network is slow, it could cause your problem.
See ":help startup" inside vim for more details on the startup process.
It might also be a good idea to set the directory and backupdir options so they prefer a local directory. Something along the lines of
set backupdir^=C:/Temp
set directory^=C:/Temp//
The ^= syntax puts the directory at the start of the list of directories for each option. The trailing // for directory tells Vim to encode the full path to the file being edited in the swapfile's name. This allows for swapfiles to be created in one directory when editing multiple files with the same name, but different paths.