I managed to get a really long command in my command history. Is there a way to get rid of it so that the history command does not go wild?
According to documentation I am seeing, you can find out where your history is stored by looking in the file:
/usr/share/init/tcsh/tcsh.defaults
For the line:
set histfile = ~/.tcsh_history # History file
Then (hopefully) you should be able to edit ~/.tcsh_history (or whatever your actual history file comes out to be) and delete the long command.
Reference
Related
Currently, my .zshrc file maintains not only a laundry list of aliases i like to keep track, but also a few secrets/tokens that get sourced whenever i start up a new terminal, e.g
# Artifactory Config
export CREDENTIALS_USR=***
export CREDENTIALS_PSW=***
I am working on setting up a remote repository where I can store my .zshrc, mainly so that I can keep my aliases checked into source control, so if my laptop were to break, that's one less thing I'd have to start over with when i get a new computer.
I originally had an alias, cpzsh, which did the following:
alias cpzsh='cp ~/.zshrc .'
and when i execute it from the root of my git repo, copies my zshconfig to the current directory (in this case my local git repo). After this I need to manually go in and scrub my secrets prior to pushing to my remote repo.
This is really easy to screw up if I were to forget, so I tried putting together a better cpzsh command using sed that could edit my file inline, and then pipe the scrubbed .zshrc to my local repo:
alias cpzsh='sed "/CREDENTIALS_/d" ~/.zshrc > .zshrc'
However, this led to some adverse effects, because the above line also got scrubbed from my .zshrc! This is because it's traversing the file for the substring CREDENTIALS_ in a line, which it deletes. So it not only deletes my artifactory credentials (which it should do), but it also deletes the line that contains the substring to delete (which it should not do!)
I am aware that sed also allows you to hard-code the lines to delete, but I'd rather not run the risk of assigning my secrets in certain lines, only for those lines to suddenly change for whatever reason and i unsuspectingly push my secrets to github.
Is there a better way to accomplish this?
How about you scrub the values but leave the export CREDENTIALS_... lines in the file?
alias cpzsh="sed 's/\(CREDENTIALS_[^=]*=\).*/\1REDACTED/;' ~/.zschrc ."
To list dir in my GIT BASH Terminal I use the following command
ls -al | less (to show one page at a time).
However upon exiting from the listing using ZZ or Q, the display on the terminal is getting refreshed and I am losing all the content just listed, and I am going back to the command line.
What would be nice is to use CTL-C key combination out of the ls listing at the point where I want it, and to keep that content displayed on the terminal so I can copy the file name or whatever. Any suggestions how to solve this problem?
My .bashrc file is pretty minimal and I don't have much going on there.
Reproduced here.
alias 'll=ls -al|less'
PS1="\$PWD:\d\n\$"
Thanks for any pointers.
I have been using the gvim command :w to save and it works fine saving it to the desktop. However with the vim program, when I use the command :w, I cannot find where the saved file is located.
It should save to whatever directory you started writing it in (you can see that in the command line). You can also use your computer's file search to locate it and then inspect for the file path.
As said by others: by default it saves in the directory where you started it. But if you aren't aware in which directory you started, then a way to find out is to use the :pwdcom in vim. This will output the current directory. That's where vim will store the file.
C:\Users\"windows user"\AppData\Local\Packages\KaliLinux.54290C8133FEE_ey8k8hqnwqnmg\LocalState\rootfs\home\"WSL user"
Adding another answer to get the filename as well.
As mentioned by Cary and Jeen, vim saves your file to the directory from where it is started. You can get the directory where it is saved using :pwd.
If you are interested to get name of the file, it can be done by ctrl + g when your laststatus=1, which is the default value.
I usually set laststatus=2 which always show the filename.
I'm trying to install the Google SDK
I type:
export PYTHONPATH=$PYTHONPATH:/Users/morganallen/Dropbox/google_appengine
then:
echo $PATH
And I see:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/morganallen/Dropbox/google_appengine
But when I quit terminal and re-open it and type echo $PATH I only see:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Why isn't it saving?
I've seen other answers mentioning a .bashrc file, but I can't find mine? Not sure what to do.
If you type that into the command line, it only applies for the current session (until you close the bash window). Instead, save that line of code into your .bash_profile and it should work for every single session.
A file whose name begins with a period (.) is a hidden file. Depending on the file manager/browser which you may be using, hidden files may not be shown by default. You will need to enable viewing hidden files in the preferences/options as the case may be.
If you are using a command line to list the contents, you can use ls -a instead of plain ls.
And of course, if you need to modify the hidden file using a text editor at the command line itself, (say, using vim/nano etc.) then you can always supply the full name of the file as an argument (including the period).
Sometimes when I create a file using vim some/path/newfile, vim lets me edit it, only to complain when I attempt to save my changes.
E212 Can't open file for writing.
This appears to happen only when the new file is located in a system directory.
:w! does not override this error.
How can I write the current buffer, without having to save it to a temporary location, exit, then rename it using sudo?
This will ask you for the root password, then save your changes as you requested:
:w !sudo tee %
Then type (L)oad at the prompt, to re-load the file after it is saved.
You can mkdir first, then save it.
Add this line to your .vimrc:
cmap w!! %!sudo tee > /dev/null
and then you can do
:w!!
when you get into this position, and it will write the file using sudo. Very handy.
You can avoid this problem by using "sudo" to start the editing session.
sudo vi name-of-file
If you want a robust, easy-to-remember solution and don't mind installing a plugin, try SudoEdit.vim - Edit Files using sudo or su or any other tool.
If this is the case in Windows 7 or later editions, run the VI editor as Administrator. Right Click of the application and select "Run as Administrator". This issue will be resolved. Moreover, the error is due to Administrative Privileges.
vim some/path/newfile
you can try to do it in two steps,first create the folder 'some' and 'path' by use mkdir ~ ;second you go into the 'path' folder,use the command:sudo vim newfile.then save it
Make sure the directory where you are trying to save the file exists and that you have permission to edit the file.
You can type :help message in Vim to get more information on this and other error messages. Try searching by typing /E212 once the docs come up. You can also view the documentation online at http://vimdoc.sourceforge.net/htmldoc/message.html and CTRL-F to find it.
For what it's worth, you may also want to ensure you have sufficient storage in the partition where you're attempting to save the file. I had to free up some space in my /home drive and that resolved the issue.
I know this is an old question, but this is what fixed it for me. Your file might be set to immutable meaning that you can't edit it.
You can check this with lsattr /path/to/file.txt
If it is use
chattr -i /etc/resolv.conf to make it no longer immutable.
Just had this issue outside of system directory.
When I tried to open a file vim src/help/tips.c. Turns out help directory did not exist, the directory was named differently and it was one of those very rare occasions that I did not auto-complete with Tab.
So, in conclusion, if this happens for a file that is not at a place where you may have permission issues, look if the path leading up to the file is a valid one.
I have experienced this in Kali!! The default account requires escalation to root with "sudo" in order for the file to be editable.
e.g: sudo vim / at this point all standard expectations appear to follow.