When using the latest ZSH and RVM on Mac OS X 10.7.4 ZSH complains about this:
__rvm_cleanse_variables: function definition file not found
Running the following solved the problem:
rm ~/.zcompdump*
Note: The * is incase there are multiple .zcompdump files.
Sometime there is also ~/.zcompdump-<COMPUTER NAME>-<VERSION> file, so use:
rm -f ~/.zcompdump*
To disable the .zcompdump* file(s), you could look in your .zshrc (or /etc/zsh/* files) for compinit and add the -D flag.
This might be better than creating the files and deleting them at every login.
(source: http://www.csse.uwa.edu.au/programming/linux/zsh-doc/zsh_23.html)
My problem persisted even after the compinit -D and rm -f ~/.zcompdump*. I found this github issue and checked my .zplug directory and sure enough found some non-hidden zcompdump files (no preceding '.'). Deleted those and I was good to go. If you're using a zsh plugin manager like zgen or zplug, check their directories.
Add rm -f ~/.zcompdump{,.zwc} to .zlogin to automate it
Related
I have exuberant tags in my mac. Since, yesterday i am getting this error
ctags: illegal option -- R
usage: ctags [-BFadtuwvx] [-f tagsfile] file ...
I have followed the steps mentoned in this
After following the steps mentioned here i can run ctags -R from command line(iterm)
But when i execute the same command from a .sh (i have a shell script where i run the cscope and ctags command using it) file i get the above error again but not when i run ctags -R from iterm directly.
Any pointers on solving this issue will be really helpfull.
Thanks in advance
So, the above issue seems to be fixed. The issue being that inside the ~/.bash_profile PATH variable should be set correctly. Even though my PATH variable was pointing to /usr/local/bin but /usr/bin appeared ahead of /usr/local/bin , hence somehow the ctags (when run from shell script) was picking up /usr/bin and not /usr/local/bin (which i have set alias to). Just move /usr/local/bin ahead of /usr/bin and it worked fine.
Solution
Type this in terminal:
export PATH="/usr/local/bin:/usr/bin:$PATH"
Along with Neil answer you can simply add alias ctags='/usr/local/bin/ctags' to your .bashrc file.
I work on c code base in Linux. I use perforce as source code repository. I had been using ctags and it was working fine. But recently when press ctrl ] in some symbol then I get below error. I removed tags file and recreated the tags file but the problem didn't solve. Any idea on how to resolve this issue?
E431: Format error in tags file "tags"
Before byte 53035586
If you are just using the ctags -R then try specifying the c language in the command like below. I had the same problem and when I specified the c language while generating the tags, the problem got resolved.
ctags -R --languages=C
There may be tags with large names in your repo. If you can live without those included in your ctags file, you can avoid this error and use rest of the ctags.
To avoid the files/folders, use this syntax
**ctags -R -V --exclude=#/path/to/ctags_ignore_file ./ **
ctags_ignore_file has the list of Folders to be excluded. You can use wildcard entries too.
This solved my problem.
TLDR; add export CSCOPE_EDITOR=vim to ~/.bashrc and close your terminal window.
In my case, setting vim as the default editor for cscope fixed the issue:
echo "export CSCOPE_EDITOR=vim" >> ~/.bashrc # Append to .bashrc
source ~/.bashrc # Load .bashrc into the current shell
After this, you may also use the following commands in your project directory for a quick reconfiguration of cscope and ctags:
ctags -R
cscope -R
I am on OS X El Capitan. I have 2 directories SourceDir & DestDir with the following structures.
ParentDir/SourceDir |-s_dir1/ss_dir1
|-s_dir2
ParentDir/DestDir |-s_dir1/ss_dir2
|-ddir1
|-ddir2
|-ddir3
I want to do a copy command in such a way that s_dir1 in ParentDir/SourceDir gets merged with s_dir1 in ParentDir/DestDir and additionally, s_dir2 gets placed into ParentDir/DestDir. So, after the copy ParentDir/DestDir should look like this:
ParentDir/DestDir |-s_dir1/ss_dir1
|-s_dir1/ss_dir2
|-s_dir2
|-ddir1
|-ddir2
|-ddir3
I use the following command to copy:
cp -f -R ParentDir/SourceDir/ ParentDir/DestDir/
It works all fine on MacOS Sierra. But strangely it doesn't work on an OS X machine with MacOS El Capitan. Again, I tried it with a MacOS El Capitan on my colleague's machine. It worked fine!!!
What is wrong?
Do different versions of MacOS El Capitan behave differently to cp command?
Or, do I need to change the copy command syntax on El Capitan?
How can I do a copy command on my MacOS El Capitan machine to ensure the correct recursive copy at least on all OSX machines?
Please do not suggest to upgrade the El Capitan machine to Sierra. That is not an option for me. Hence posted this question to get some other syntax options of copy command.
It appears that the standard cp command is being overridden by something else. You can force it to use the standard cp command by explicitly specifying /bin/cp. You could also try to override the current override by using something like an alias, but it'd really be better to find out what the current override is, where it's coming from, and (maybe) getting rid of it.
The first thing to do is run type cp its output tells you what cp is currently doing:
If it prints something like "cp is /usr/local/bin/cp", then you've got a custom-installed version of cp that's overriding the standard one... and is apparently causing problems. Your best option here is to find out what's installed the nonstandard cp command (maybe homebrew?) and remove it.
If it prints something like "cp is aliased to <some command string>", then you have an alias defined in one of your shell initialization files (or one of the files they run, etc). Check your ~/.profile, ~/.bash_profile, ~/.bash_login, and ~/.bashrc for the source of the alias definition.
If it prints "cp is a function", then you have a function defined in one of your shell init files. Check as you would for an alias definition.
The trick for me was having to do the cp command recursively as super user.
Not sure why
sudo /bin/cp -R -v -p source destination
the -v shows you the progress as each file is copied.
Cheers
Greg
I found a file in my terminal named ~$E THINKERS.docx, I tried to removed it using the rm command but it keeps telling me no such file found. I think its a rootkit, since my antivirus doesn't detect it. Anyone can help me remove it?
Your question is lacking details...
I suppose you are working in Unix-like terminal and typing: rm ~$E THINKERS.docx and the expansion fail (look for "Tilde Expansion" in bash(1)).
Could you try: rm '~$E THINKERS.docx'?
If it were a rootkit, you most probably wouldn't see it...
After I upgraded to Mavericks, PostgreSQL started playing up, giving this error message whenever I call pg_restore without calling the full path:
pg_restore: command not found
If I specify the full path it works, but that's obvious not optimal:
/Applications/Postgres93.app/Contents/MacOS/bin/pg_restore --verbose --clean --no-acl --no-owner -h localhost -U steven -d db/testivate_development $file_path
To fix this problem, I have tried removing all versions of PostgreSQL (with Homebrew) and then installed Postgres.app. You can confirm this has worked like this:
$ sudo find / -name pg_restore
/Applications/Postgres93.app/Contents/MacOS/bin/pg_restore
find: /dev/fd/3: Not a directory
find: /dev/fd/4: Not a directory
To add PostgreSQL to my path, I've tried adding each of the following lines to ~/.bash_profile, ~/bashrc and ~/.zshrc, restarting after each attempt:
export PATH="/Applications/Postgres.app/Contents/MacOS/bin:$PATH"
...as per the postgresapp.com documentation, and then...
export PATH="/Applications/Postgres93.app/Contents/MacOS/bin:$PATH"
...as per the comments below.
None of this has solved my problem.
Try adding this line to your .bash_profile:
export PATH="/Applications/Postgres93.app/Contents/MacOS/bin:$PATH"
and remove or comment out the previous reference.
I had this problem too, so instead of adding this to my path in .bash_profile:
export PATH="/Applications/Postgres93.app/Contents/MacOS/bin:$PATH"
which is what had been recommended, I added
export PATH="/Applications/Postgres.app/Contents/Versions/9.3/bin:$PATH"
instead. The '9.3' is replaced by your own version.
I verified it afterwards using
which psql
And it found my version, whereas before it reported nothing.
I then then created a test database with
createdb test
This worked like a charm.
If you are using zsh, try this line in your .zshrc and then restart the terminal
export PATH=$PATH:/Applications/Postgres.app/Contents/Versions/9.4/bin
The examples others are giving that do export PATH=... should be the solution to your problem. Since it's not working, you're going to have to debug a problem with your shell that has nothing to do with PostgreSQL.
Firstly, do which pg_restore to see if there is another file called pg_restore in your path that is confusing things. which will usually give no output rather than a helpful error if nothing is found, otherwise it will print the path of what it did found. You may find an old broken install of PostgreSQL in /usr/local/bin, for example.
If that didn't work, try echo $PATH from a new shell. Do you see the path to the PostgreSQL binary directory in there? If not, $PATH is not being set in your shell dot-rc files. This would be the case if you added it to a file called ~/bashrc since bash(1) actually read ~/.bashrc. Note the extra dot! I suspect this is your actual problem.
If that turns out to not be the problem, you can (re)read the rc file into your current session with source ~/.bashrc. Again, echo $PATH If it still doesn't contain the path, the dot-rc file contains a bug and is not being executed as far as the part that updates $PATH. You can do bash --verbose ~/.bashrc to run it, and you'll see each command as it's being executed. The failing command should be the last one displayed. (Note that when you run a script with bash, it will not set variables in your current shell.)
You need to add the path in your bash_profile
nano ~/.bash_profile
Add this line (my postgres version is 9.1):
export PATH=$PATH:/Library/PostgreSQL/9.1/bin/
On macOS Sierra 10.12.1 with PostgreSQL 9.6.0.0
/Applications/Postgres.app/Contents/MacOS/Postgres
Postgres is binary file.
On my macOS, Postgre 9.6 is installed in
/Library/PostgreSQL/9.6
on macOS High Sierra 10.13.2 and PostgreSQL 9.6 it works for me:
export PATH=$PATH:/Library/PostgreSQL/9.6/bin:$PATH