I find it very useful, in general, for my R history to be saved. I refer to it weekly, or more. Exploratory work in the console gradually gets refined and added to a file.
Occasionally a command will have a secret in it like an API key or searching a dataframe with confidential info, in which case I would like to be able to disable history being saved just for that one command and re-enable it immediately after. Something as much like bash's ignorespace option as possible.
I would be happy for a solution that worked in either R or RStudio, both would be even better. I know history can be manually disabled by going to Tools > Options > General > Always save history but I'm looking for either a command (or keyboard shortcut) so it can be turned on or off quickly.
Edit: something I thought might work but seemed not to help at all was settling "R_HISTFILE" to FALSE or a non-existent file. It doesn't to help the RStudio history at least. My examination of what it actually did has not been very thorough yet.
As i stated in the comment, there are ways to avoid having an API key stored in the history file. As the comment seemed to have collected some upvotes it might be worth the effort to expand it in an answer.
Occasionally a command will have a secret in it like an API key or searching a dataframe with confidential info, in which case I would like to be able to disable history being saved just for that one command and re-enable it immediately after.
I think right now, it is only possible to find a sultion for the "API key issue" with the current version of RStudio, see the comments in the links of paragraph: "Concerning the confidential info:"
However, while waiting for a soultion this page could be of interest for you: https://cran.r-project.org/web/packages/httr/vignettes/secrets.html.
Avoid having the API key stored is easier than the confidential info of a data.frame i think.
Concerning the confidential info:
Longer to introduce, but "clean":
I think its worth to add it as a feature request for the great rstudioapi package or adding up here:
https://support.rstudio.com/hc/en-us/community/posts/115000932128-RStudio-Config-Files
Related: https://github.com/rstudio/rstudio/issues/1607 (would enable user to write their own addin)
Related: https://community.rstudio.com/t/configure-rstudio-global-options-on-install/14881 (would enable user to write their own addin)
Fast to introduce, but dirty:
- a hacky dirty workaround would be to introduce an add-in to delete the last insert in the history file.
Information storage
Here is described where the settings are stored: https://support.rstudio.com/hc/en-us/articles/200534577-Resetting-RStudio-Desktop-s-State.
You can navigate to the Rstudio-desktop folder. E.g. on windows enter: %localappdata%\RStudio-Desktop in the explorer.
The global options you are looking for can be found here: ..\monitored\user-settings\user-settings.
The flag "always save history,..." in Rstudio - Tools - Global Options - General is the first value in ..\monitored\user-settings\user-settings.
Unfortunately, RStudio won´t listen on changes in that file, so you would have to restart RStudio to make changes be visible. So for now it is not an option for temporarily stopping Rstudio from recording the history.
Concerning the API key, let me summarize a few approaches of that page:
Add a "popup" to ask for the secret: rstudioapi::askForPassword()
use environmental variables. You avoid the popup, but i think it just moves the logging of the confidential info from the "history" to the envar.
finally see the keyring package for storing the data in the secret store of your OS.
Related
Is there a way to look back at previous code in a file? For instance maybe be able to revert to an earlier saved version or somehow see changes the file code went through?
Short answer: no.
Unless your changes are tracked in some sort of source control (like git) or you keep backups of your files, there is no way to see previous version of a script file. A .R script is just plain text files. They do not store their own history just like other documents or images on your computer don't either. Sorry.
If that's something you want to do in the future, Rstduio makes it easy to integrate with git. Check out this guide to Connect RStudio to Git and GitHub
I'd like to create an R package that, upon installation, displays contact information for the maintainer and ask the user for permission to count them in our list of installations. It would also be acceptable to have the code run the first time the user calls one of our functions, instead of immediately on installation. Either way, this message should only appear once ever (unless the user reinstalls / updates the package).
What I've considered:
I know how to include a dataset for internal use, but I don't know how to change that data permanently.
We could set an environment variable / app setting, but I don't know if there's a way to make that persist after the end of the session.
Using an external service / server would be excessively heavyweight, and wouldn't allow users who don't want to be tracked to turn off the message.
Is there a good way to do this?
This can run more than once but only within a limited time window so perhaps it is good enough.
Add this code to your package and it will issue the message any time the package is loaded within 7 days of installation and thereafter it will not issue the message again until the package is updated.
It works by comparing the time the install files were created to the current time. It does not require write permissions to any directory, only read, so it should work generally.
.onLoad <- function(libname, pkgname) {
ctime <- file.info(find.package(pkgname, libname))$ctime
if (difftime(Sys.time(), ctime, unit = "day") < 7)
packageStartupMessage("This msg will go away one week after installing this package")
}
You may have to bite the bullet and store state information across sessions to show it once and only once.
Some packages which may help:
settings which retrieves user configuration settings
config which retrieves configuration information
httr which access config info
registry which offers a registry
pkgconfig offers private configuration.
but I am not sure which one reads and writes. Maybe the last one fits the bill.
Edit: Turns out that even pkgconfig does not persist values across sessions. I have solved this problem with company-local code when I had control over directories or databases to write. For public and portable code it is a little harder. I still think there is a package out there that stores user-level config on all major OSs but I cannot for now remember the name.
Edit 2: With a nod to Gabor Csardi to refresh my memory, the rappdirs solves the problem of portably supplying a config location per-user (with other tricks too, a port of a corresponding Python library). Combine this with a simple cvs or rds file to store when (at all) you last showed the message and you can now show it once and exactly once. Not even again after a package upgrade.
The following code allows you to create a file in the package library:
activate_file = paste(system.file('extdata', package = 'your_package'), 'activated.txt', sep = '/')
file.exists(activate_file)
# FALSE
file.create(activate_file)
file.exists(activate_file)
# TRUE
Now you can check in .onLoad whether or not the activated.txt file exists. The first time you show the message, and then you create activated.txt, and in the next time the package is used the onload function sees the file and can skip the message.
Advantages:
Persistent over sessions.
Platform independent way that ensures the user has write privileges to create the file.
Disadvantages:
Reinstall/upgrade wipes the activated file, thus showing the message again.
If this is not acceptable, you could try and find a persistent location, e.g. in the home drive to do this (e.g. ~/.your_package/activated.txt). Then the challenge is to make this platform independent. Maybe look at path.expand(~) to get the current users home drive, not sure if this works on Windows.
So I am a noob. Looking back I don't know what I was thinking. But I just realized I have uploaded my wp-config file for WordPress to GitHub. Which means my access keys and database login is out for the world to see. In the short term I have converted the repository to private. But I need to figure out how to remove the file from all of the repositories commits. I found this, https://help.github.com/articles/remove-sensitive-data/ but I am afraid that I don't quite understand it and I am not sure how to use it. I have Git Shell but I have only really used the GitHub software. Can anyone walk me through the steps to take? Or am I better off deleting the entire repository and starting over?
Even if you converted it to private, it was online for a while. Check their red mean danger text:
Danger: Once you have pushed a commit to GitHub, you should consider
any data it contains to be compromised. If you committed a password,
change it!
Change the password, then try this repo cleaner:
https://rtyley.github.io/bfg-repo-cleaner/
You'll need java. If you consider it too much work just delete and recreate the repo, but change the exposed password anyway.
I have a question. Accidentally I removed my .vimrc file but macvim is still open and all the settings are stored. Is there a way to load it?
I've never used it myself, but you could give the mkexrc command a try.
:mk :mkexrc
:mk[exrc] [file] Write current key mappings and changed options to
[file] (default ".exrc" in the current directory),
unless it already exists.
If you use plugins, you might want to look at your plugin manager's documentation to see if you can get a list of loaded plugin, which would get you halfway to recreating your plugin list.
If your question is how to restore perfect copy of .vimrc only using running vim, I do not know the answer. If your question is how to restore most of your lost .vimrc, please consider following options:
But, firstly, look at the trash :-) (quite obvious, it is not the case, is it?)
There should be also .gvimrc in your home directory. Usually people share the same settings between terminal and graphic versions of macvim, with maybe some minor exceptions, like the size of the window etc. So, if you have .gvimrc you can most probably restore your .vimrc.
The other option can be examining your command history using q: command. If you tried commands before you put them to .vimrc and the history is long enough, you can copy&paste them and thus restore .vimrc.
Suppose I have a file, urls.txt, that contains a list of URLs I'm monitoring. My monitoring script edits that file occasionally, say, to indicate whether each URL is reachable. I'd like to also manually edit that file, to add to or change the list of URLs. How can I allow that such that I don't have to think about it when manually editing?
Here are some possible answers. What would you do?
Engage in hackery like having the program check for the lockfiles that vim or emacs create. Since this is just for me, this would actually work.
If the human edits always take precedence, just always have the human clobber the program's changes (eg, ignore the editor's warning that the file has changed on disk). The program can then just redo its changes on its next loop. Still, changing the file while the user edits it is not so nice.
Never let a human touch a file that a program makes ongoing modifications to. Rethink the design and have one file that only the human edits and another file that only the program edits.
Give the human a custom tool to edit the file that does the appropriate file locking. That could be as crude as locking the file and then launching an editor, or a custom interface (perhaps a simple command line interface) for inserting/changing/deleting entries from the file.
Use a database instead of a flat file and then the locking is all taken care of automatically.
(Note that I concocted the URL monitoring example to make this more concrete and because what I actually have in mind is perhaps too weird and distracting -- this question is strictly about how to let humans and programs both modify the same state file.)
I'd use a database since that's basically what you're going to have to build to achieve what you want. Why re-invent the wheel?
If a full-blown DBMS is too much of a load, separate the files into two and synchronize them periodically. Whether the URL is reachable doesn't sound like something the user would be changing, so should not be editable by them.
During the synchronize process (which would have to lock out the monitor and the user although it could be a sub-function of the monitor), remove entries in the monitor file that aren't in the user full. Also, add to the monitor file those that have been added to the user file (and start monitoring them).
But, I'd go the database method with a special front-end for the user, since you can get relatively good light-weight databases nowadays.
Use a sensible version control system!
(Git would work well here).
That said, the nature of the problem implies that a real database would be best - and they will generally have either database-level, table-level, or row-level locking - but then put any scripts you need into version control.
I would go with option 3. In fact, I would have the program read the human-edited input file, and append the results of each query to a log file. In this way, you can also analyse the reachability of sites over time. You can also have the program maintain a file that indicates the current reachability state of each site in the input file, as a snapshot of the current state.
One other option is using two files, one for automated access and one for manual. You'd need a way in the user file to indicate modifications or deletions but you'd have similar problems in some of the other solutions as well.