I have gone through a lot of google results. Let me explain what I have tried first. I am currently working on a corporate laptop. Mac OS Mojave 10.14.6.
Error that I get:
sudo: /etc/sudoers is world writable
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin
ls -le /etc
-rwxrwxrwx 1 root wheel 179 Aug 18 2018 shells
drwxrwxrwx 4 root wheel 128 Aug 18 2018 snmp
drwxrwxrwx 5 root wheel 160 Nov 11 2019 ssh
drwxrwxrwx 6 root wheel 192 Nov 11 2019 ssl
-rwxrwxrwx 1 root wheel 257 Aug 18 2018 sudo_lecture
-rwxrwxrwx 1 root wheel 1630 Mar 11 11:51 sudoers
drwxrwxrwx 2 root wheel 64 Aug 18 2018 sudoers.d
drwxrwxrwx 4 root admin 128 Dec 25 2018 symantec
-rw-rw-rw-# 1 01244861 wheel 47 Feb 2 18:13 sysctl.conf
-rwxrwxrwx 1 root wheel 96 Aug 21 2018 syslog.conf
-rwxrwxrwx 1 root wheel 1316 Aug 18 2018 ttys
drwxrwxrwx 6 root wheel 192 Aug 18 2018 wfs
-rwxrwxrwx 1 root wheel 0 Aug 18 2018 xtab
-rwxrwxrwx 1 root wheel 126 Aug 18 2018 zprofile
-rwxrwxrwx 1 root wheel 207 Aug 18 2018 zshrc
I have changed permission using chmod 440 /etc/sudoers and chmod 777 /etc/sudoers and also using info and manually updating from the file properties.
I am using iTerm2 as my terminal.
echo $PATH
/Users/01244861/.yarn/bin:/Users/01244861/.nvm/versions/node/v10.13.0/bin:/usr/local/opt/node#10/bin:/usr/local/opt/node#10/bin:/usr/local/opt/node#10/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/go/bin
echo $SHELL
/bin/zsh
My user permissions:
Is there anything else that I can do to fix this?
Thanks
I am completely new to Linux and want to write a website in Yekyll. therefore I have to install Ruby first. Unfortunately this does not work properly. As far as I can see, I do not have the correct rights for Ruby. but I already set the rights to rwx. So I cannot see what else I can do. Can anybody help me please?
Here is what I did and received:
raphael#raphael-ThinkCentre-M58:~$ gem install jekyll bundler
ERROR: While executing gem ... (Gem::FilePermissionError)
You don't have write permissions for the /var/lib/gems/2.5.0 directory.
raphael#raphael-ThinkCentre-M58:~$
raphael#raphael-ThinkCentre-M58:~$ sudo ls -al /var/lib/gems/2.5.0
[sudo] password for raphael:
total 32
drwxr-xr-x 8 root root 4096 Nov 17 10:08 .
drwxr-xr-x 3 root root 4096 Nov 17 09:51 ..
drwxr-xr-x 2 root root 4096 Nov 17 10:08 build_info
drwxr-xr-x 2 root root 4096 Nov 17 10:25 cache
drwxr-xr-x 3 root root 4096 Nov 17 10:08 doc
drwxr-xr-x 3 root root 4096 Nov 17 10:25 extensions
drwxr-xr-x 7 root root 4096 Nov 17 14:48 gems
drwxr-xr-x 2 root root 4096 Nov 17 10:25 specifications
This is much to small to give it to a professional, but never the less it stops my working since two days. :(
Any ideas? Thanks!
I maintain some legacy code that runs on RH Linux that sends inserts over the network to a client's Sybase. We were using Sybase 12.5 libraries and have just migrated to use Sybase 15.0 client libraries.
My application logs the time at which it sends the insert over the network and also the time it get the acknowledgment back from the target Sybase. When using 12.5 libraries the time was ~5 ms, now with the 15.5 libraries it's roughly 50 ms.
The only change I've made on the application side is to specify the location of the interfaces file on the command line. Previously the file was located in the default location - the location of the Sybase installation. Now it's located where the application is deployed, hence the need to specify the location explicitly.
Would anyone have any idea what is causing the dramatic change in speed, or have hints on where I could look or ideas on how to trace the root cause?
Please forgive the lack of technical details. I'm not a DB admin but a developer using a compiled library to connect to Sybase and don't have access to the nitty-gritty internals. That being said, I'm using the same internal library in both cases, it's only the Sybase librairies that are different.
My Sybase 12.5 and 15 installations look like this:
$ ls -l /opt/sybase/
total 48
-rw-r--r-- 1 root root 555 Jul 2 2019 ASE150.csh
-rw-r--r-- 1 root root 259 Jul 2 2019 ASE150.env
-rw-r--r-- 1 root root 388 Jul 2 2019 ASE150.sh
drwxr-xr-x 10 root root 4096 Feb 2 2017 OCS-15_0
-rw-r--r-- 1 root root 555 Jul 2 2019 SYBASE.csh
-rw-r--r-- 1 root root 259 Jul 2 2019 SYBASE.env
-rw-r--r-- 1 root root 388 Jul 2 2019 SYBASE.sh
drwxr-xr-x 58 root root 4096 Jul 2 2019 charsets
drwxr-xr-x 3 root root 4096 Jul 2 2019 collate
drwxr-xr-x 2 root root 4096 Nov 23 20:55 config
-rw-r--r-- 1 root root 1239 Jul 2 2019 interfaces
drwxr-xr-x 5 root root 4096 Nov 23 20:55 locales
$ ls -l ~/12_5/sybase/
total 28
drwxrwxr-x 4 oadc oadc 4096 Nov 29 2017 OCS-12_5
drwxrwxr-x 58 oadc oadc 4096 Nov 29 2017 charsets
drwxrwxr-x 2 oadc oadc 4096 Mar 16 09:45 config
drwxrwxr-x 2 oadc oadc 4096 Mar 16 09:45 include
-r-xr-xr-x 1 oadc oadc 1184 Mar 16 09:45 interfaces
drwxrwxr-x 2 oadc oadc 4096 Mar 16 09:45 lib
drwxrwxr-x 5 oadc oadc 4096 Mar 16 09:45 locales
EDIT
After some more digging it looks like the libraries under OCS-12-5 are not actually for 12_5 but for 15_5!
$ strings sybase/OCS-12_5lib/libsybct*.a | grep "Sybase Client-Library"
Sybase Client-Library/15.5/P/DRV.15.5.0/Linux x86_64/Linux 2.6.9-55.ELsmp x86_64/BUILD1550-003/64bit/OPT/Mon Oct 5 23:16:48 2009
Sybase Client-Library/15.5/P/DRV.15.5.0/Linux x86_64/Linux 2.6.9-55.ELsmp x86_64 Native Threads/BUILD1550-003/64bit/OPT/Tue Oct 6 00:06:57 2009
Which means that my assumption that 12.5 was faster than 15.0 is wrong. What is actually happening is that 15.5 is faster than 15.0. Which makes more sense.
I'm not going to go hunt down the idiot that submitted these files into a directory labelled OCS-12-5 ...
After some more digging it looks like the libraries under OCS-12-5 are not actually for 12_5 but for 15_5!
$ strings sybase/OCS-12_5lib/libsybct*.a | grep "Sybase Client-Library" Sybase Client-Library/15.5/P/DRV.15.5.0/Linux x86_64/Linux 2.6.9-55.ELsmp x86_64/BUILD1550-003/64bit/OPT/Mon Oct 5 23:16:48 2009 Sybase Client-Library/15.5/P/DRV.15.5.0/Linux x86_64/Linux 2.6.9-55.ELsmp x86_64 Native Threads/BUILD1550-003/64bit/OPT/Tue Oct 6 00:06:57 2009
Which means that my assumption that 12.5 was faster than 15.0 is wrong. What is actually happening is that 15.5 is faster than 15.0. Which makes more sense.
I've updated the question with this new information.
What is the location of all .vbox files that are created in virtual box in a mac. And how can we delete it?
I mistakenly deleted virtualbox.app file from Applications and now I want to delete all the remains of all virtual box files.
I tried following things:
drwxr-xr-x# 3 user admin 102 Dec 19 19:57 vagrant
-rw-r--r-- 1 root wheel 1824496 Feb 21 17:17 com.vagrant.vagrant.bom
-rw-r--r-- 1 root wheel 240 Feb 21 17:17 com.vagrant.vagrant.plist
drwx------ 5 root wheel 170 Feb 21 16:59 ubuntu-cloudimg-precise-vagrant-amd64_1487725164672_27815
./private/var/root/VirtualBox VMs/ubuntu-cloudimg-precise-vagrant-amd64_1487725164672_27815:
-rw------- 1 root wheel 3036 Feb 21 16:59 ubuntu-cloudimg-precise-vagrant-amd64_1487725164672_27815.vbox
-rw------- 1 root wheel 3036 Feb 21 16:59 ubuntu-cloudimg-precise-vagrant-amd64_1487725164672_27815.vbox-prev
lrwxr-xr-x 1 root wheel 24 Feb 21 17:17 vagrant -> /opt/vagrant/bin/vagrant
But I could not find the location of .vbox files to manually delete them.
By default the .vbox files normally go into your users' home directory:
pwd
/Users/Astro58/VirtualBox VMs
total 264
drwx------# 6 lance staff 204 Feb 22 19:03 ./
drwxr-xr-x+ 88 lance staff 2992 Feb 22 16:11 ../
drwx------ 6 lance staff 204 Feb 22 19:50 Laravel_default_1487808229046_76286/
drwx------ 7 lance staff 238 Feb 20 12:53 legacy_default_1487457532080_39585/
You should be able to delete the "VirtualBox VMs" directory via the rm command or via the Mac Finder.
I get this error:
xcrun: error: invalid active developer path (/Applications/Xcode.app), missing xcrun at: /Applications/Xcode.app/usr/bin/xcrun
This solution works, but the error occurs again after closing my terminal and reopening it; I then have to run the same commands every time I open a new terminal window.
How can I apply these changes such that they will save after closing the terminal window out?
I started getting the same error after updating to OS X El Capitan.
In my case, all I did was to install it:
sudo xcode-select --install
And it works fine for me.
The steps below are for OS X 10.10 (Yosemite). Those experiencing this because of an upgrade to 10.11 (El Capitan) seem need to only run sudo xcode-select --install as described in the accepted answer.
I found a suggestion here which indicated
sudo xcode-select -switch /
as the fix. However, this threw an error that the developer path was invalid.
Instead, for me, I modified this to
sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer/
(which is a mixture of the two referenced link solutions) and this worked.
Try using
xcode-select --print-path
to find your developer path if /Applications/Xcode.app/Contents/Developer/ is still invalid for you.
I know this is quite old but I got the same issue and then I fixed it by doing couple more extra steps. Problem came when Terminal could not find the actual path of the Command Line Tools.
If you had Xcode and then removed it, then Terminal is referring to
the Command Line Tools inside the Xcode folder. Try using this
command and check what your path is, xcode-select --print-path. This would most likely print /Applications/Xcode.app/Contents/Developer.
Now to fix this, reinstall the command line tools for xcode. Initially remove any previous installations using sudo rm -rf /Library/Developer/CommandLineTools.
Then install the command line tools sudo xcode-select --install
Now the final step, change the path for the CLT to the actual path using sudo xcode-select -switch /Library/Developer/CommandLineTools/ this will fix it.
I resolved the issue with the below steps.
Xcode -> Preferences -> Locations -> Command Line Tools -> Select the command tool matching your Xcode version.
I started getting the same error after i update macOS Mojave to macOS Catalina.
I just installed few command lines in Terminal,
$ sudo gem install cocoapods
$ sudo xcode-select --install
$ chsh -s /bin/zsh
Then, goto Xcode -> Preferences -> Locations -> Command Line Tools and confirm you have current Xcode version selected there.
For me the solution was as easy as reinstalling Xcode.
It was pointed out here: https://superuser.com/a/981126
You can (re)install Xcode via command line like the answer above suggest, or directly from the App Store.
I too had the same issue after upgrading to OS X EI Captian. I just installed xcode-select using sudo xcode-select --install
sudo xcode-select -switch / works for me.
Partial diagnosis: https://github.com/microsoft/vcpkg/issues/8781#issuecomment-547248760
It seems that upgrading from one MacOS version to another either uninstalls some dev tools or it moves them to another path, and this breaks compatibility with any tool using the environment variable that points to the old location where the tools were located.
sudo xcode-select --install
Using the install command worked for me, but it is not clear whether this simply downloaded and unpacked files and then skipped installation and simply updated an environment variable or whether it physically installed the files at the expected path. (Or it could have made links to the new folder path).
Testing my theory, I probe the folder structure with ls (I should have done this before using the install command):
rej#Ryans-MacBook-Air:~$ ls /Library/Developer/CommandLineTools/usr/bin/
rej#Ryans-MacBook-Air:~$ ls -la /Library/Developer/CommandLineTools/usr/bin/
total 243776
drwxr-xr-x 124 root wheel 3.9K Oct 28 23:03 ./
drwxr-xr-x 7 root admin 224B Oct 28 23:05 ../
lrwxr-xr-x 1 root wheel 64B Oct 28 23:03 2to3# -> ../../Library/Frameworks/Python3.framework/Versions/3.7/bin/2to3
lrwxr-xr-x 1 root wheel 68B Oct 28 23:03 2to3-3.7# -> ../../Library/Frameworks/Python3.framework/Versions/3.7/bin/2to3-3.7
-rwxr-xr-x 1 root wheel 116K Sep 5 22:51 DeRez*
-rwxr-xr-x 1 root wheel 31K Sep 5 22:51 GetFileInfo*
-rwxr-xr-x 1 root wheel 33K Sep 5 22:51 ResMerger*
-rwxr-xr-x 1 root wheel 126K Sep 5 22:51 Rez*
-rwxr-xr-x 1 root wheel 31K Sep 5 22:51 SetFile*
-rwxr-xr-x 1 root wheel 32K Sep 5 22:51 SplitForks*
-rwxr-xr-x 1 root wheel 41K Sep 5 22:51 ar*
-rwxr-xr-x 1 root wheel 40K Sep 5 22:51 as*
-rwxr-xr-x 1 root wheel 27K Sep 5 22:51 asa*
-rwxr-xr-x 1 root wheel 216K Sep 5 22:51 bison*
-rwxr-xr-x 1 root wheel 159K Sep 5 22:51 bitcode_strip*
lrwxr-xr-x 1 root wheel 5B Oct 28 23:03 c++# -> clang
-rwxr-xr-x 1 root admin 31K Sep 5 22:51 c89*
-rwxr-xr-x 1 root admin 31K Sep 5 22:51 c99*
lrwxr-xr-x 1 root wheel 5B Oct 28 23:03 cc# -> clang
-rwxr-xr-x 1 root wheel 80M Sep 5 22:51 clang*
lrwxr-xr-x 1 root wheel 5B Oct 28 23:03 clang++# -> clang
-rwxr-xr-x 1 root wheel 125K Sep 5 22:51 cmpdylib*
-rwxr-xr-x 1 root wheel 154K Sep 5 22:51 codesign_allocate*
lrwxr-xr-x 1 root wheel 17B Oct 28 23:03 codesign_allocate-p# -> codesign_allocate
-rwxr-xr-x 1 root admin 3.3K Aug 16 06:55 cpp*
-rwxr-xr-x 1 root wheel 36K Sep 5 22:51 ctags*
-rwxr-xr-x 1 root wheel 150K Sep 5 22:51 ctf_insert*
-rwxr-xr-x 1 root wheel 30M Sep 5 22:51 dsymutil*
lrwxr-xr-x 1 root wheel 14B Oct 28 23:03 dwarfdump# -> llvm-dwarfdump
-rwxr-xr-x 1 root wheel 477K Sep 5 22:51 dwarfdump-classic*
-rwxr-xr-x 1 root wheel 211K Sep 5 22:51 dyldinfo*
-rwxr-xr-x 1 root wheel 239B Sep 5 19:18 easy_install-3.7*
-rwxr-xr-x 1 root wheel 572K Sep 5 22:51 flex*
-rwxr-xr-x 1 root wheel 572K Sep 5 22:51 flex++*
lrwxr-xr-x 1 root wheel 3B Oct 28 23:03 g++# -> gcc
-rwxr-xr-x 1 root wheel 101K Aug 16 07:31 gatherheaderdoc*
-rwxr-xr-x 1 root admin 27K Sep 5 22:51 gcc*
lrwxr-xr-x 1 root wheel 8B Oct 28 23:03 gcov# -> llvm-cov
-rwxr-xr-x 1 root wheel 2.4M Sep 5 22:51 git*
lrwxr-xr-x 1 root wheel 3B Oct 28 23:03 git-receive-pack# -> git
-rwxr-xr-x 1 root wheel 1.4M Sep 5 22:51 git-shell*
lrwxr-xr-x 1 root wheel 3B Oct 28 23:03 git-upload-archive# -> git
lrwxr-xr-x 1 root wheel 3B Oct 28 23:03 git-upload-pack# -> git
-rwxr-xr-x 1 root wheel 148K Sep 5 22:51 gm4*
-rwxr-xr-x 1 root wheel 166K Sep 5 22:51 gnumake*
-rwxr-xr-x 1 root wheel 98K Sep 5 22:51 gperf*
-rwxr-xr-x 1 root wheel 33K Sep 5 22:51 hdxml2manxml*
-rwxr-xr-x 1 root wheel 158K Aug 16 07:31 headerdoc2html*
-rwxr-xr-x 1 root wheel 73K Sep 5 22:51 indent*
-rwxr-xr-x 1 root wheel 142K Sep 5 22:51 install_name_tool*
-rwxr-xr-x 1 root wheel 2.5M Sep 5 22:51 ld*
-rwxr-xr-x 1 root wheel 230B Aug 16 07:13 lex*
-rwxr-xr-x 1 root wheel 163K Sep 5 22:51 libtool*
-rwxr-xr-x 1 root wheel 73K Sep 5 22:51 lipo*
-rwxr-xr-x 1 root wheel 332K Sep 5 22:51 lldb*
-rwxr-xr-x 1 root wheel 3.6M Sep 5 22:51 llvm-cov*
-rwxr-xr-x 1 root wheel 7.9M Sep 5 22:51 llvm-dwarfdump*
-rwxr-xr-x 1 root wheel 9.8M Sep 5 22:51 llvm-nm*
-rwxr-xr-x 1 root wheel 11M Sep 5 22:51 llvm-objdump*
-rwxr-xr-x 1 root wheel 40K Sep 5 22:51 llvm-otool*
-rwxr-xr-x 1 root wheel 1.6M Sep 5 22:51 llvm-profdata*
-rwxr-xr-x 1 root wheel 2.9M Sep 5 22:51 llvm-size*
-rwxr-xr-x 1 root wheel 3.5K Aug 16 07:19 lorder*
-rwxr-xr-x 1 root wheel 148K Sep 5 22:51 m4*
-rwxr-xr-x 1 root wheel 166K Sep 5 22:51 make*
-rwxr-xr-x 1 root wheel 7.7K Aug 16 07:16 mig*
lrwxr-xr-x 1 root wheel 7B Oct 28 23:03 nm# -> llvm-nm
-rwxr-xr-x 1 root wheel 142K Sep 5 22:51 nm-classic*
-rwxr-xr-x 1 root wheel 171K Sep 5 22:51 nmedit*
lrwxr-xr-x 1 root wheel 12B Oct 28 23:03 objdump# -> llvm-objdump
lrwxr-xr-x 1 root wheel 10B Oct 28 23:03 otool# -> llvm-otool
-rwxr-xr-x 1 root wheel 644K Sep 5 22:51 otool-classic*
-rwxr-xr-x 1 root wheel 138K Sep 5 22:51 pagestuff*
-rwxr-xr-x 1 root wheel 221B Sep 5 19:18 pip3*
-rwxr-xr-x 1 root wheel 221B Sep 5 19:18 pip3.7*
-rwxr-xr-x 1 root wheel 32K Sep 5 22:51 projectInfo*
lrwxr-xr-x 1 root wheel 66B Oct 28 23:03 pydoc3# -> ../../Library/Frameworks/Python3.framework/Versions/3.7/bin/pydoc3
lrwxr-xr-x 1 root wheel 68B Oct 28 23:03 pydoc3.7# -> ../../Library/Frameworks/Python3.framework/Versions/3.7/bin/pydoc3.7
lrwxr-xr-x 1 root wheel 67B Oct 28 23:03 python3# -> ../../Library/Frameworks/Python3.framework/Versions/3.7/bin/python3
lrwxr-xr-x 1 root wheel 74B Oct 28 23:03 python3-config# -> ../../Library/Frameworks/Python3.framework/Versions/3.7/bin/python3-config
lrwxr-xr-x 1 root wheel 69B Oct 28 23:03 python3.7# -> ../../Library/Frameworks/Python3.framework/Versions/3.7/bin/python3.7
lrwxr-xr-x 1 root wheel 76B Oct 28 23:03 python3.7-config# -> ../../Library/Frameworks/Python3.framework/Versions/3.7/bin/python3.7-config
lrwxr-xr-x 1 root wheel 70B Oct 28 23:03 python3.7m# -> ../../Library/Frameworks/Python3.framework/Versions/3.7/bin/python3.7m
lrwxr-xr-x 1 root wheel 77B Oct 28 23:03 python3.7m-config# -> ../../Library/Frameworks/Python3.framework/Versions/3.7/bin/python3.7m-config
lrwxr-xr-x 1 root wheel 66B Oct 28 23:03 pyvenv# -> ../../Library/Frameworks/Python3.framework/Versions/3.7/bin/pyvenv
lrwxr-xr-x 1 root wheel 70B Oct 28 23:03 pyvenv-3.7# -> ../../Library/Frameworks/Python3.framework/Versions/3.7/bin/pyvenv-3.7
lrwxr-xr-x 1 root wheel 7B Oct 28 23:03 ranlib# -> libtool
-rwxr-xr-x 1 root wheel 70K Sep 5 22:51 resolveLinks*
-rwxr-xr-x 1 root wheel 85K Sep 5 22:51 rpcgen*
-rwxr-xr-x 1 root wheel 56K Sep 5 22:51 segedit*
lrwxr-xr-x 1 root wheel 12B Oct 28 23:03 size# -> size-classic
-rwxr-xr-x 1 root wheel 125K Sep 5 22:51 size-classic*
-rwxr-xr-x 1 root admin 138K Sep 5 22:51 stapler*
-rwxr-xr-x 1 root wheel 126K Sep 5 22:51 strings*
-rwxr-xr-x 1 root wheel 179K Sep 5 22:51 strip*
-rwxr-xr-x 1 root wheel 330K Sep 5 22:51 svn*
-rwxr-xr-x 1 root wheel 118K Sep 5 22:51 svnadmin*
-rwxr-xr-x 1 root wheel 105K Sep 5 22:51 svnbench*
-rwxr-xr-x 1 root wheel 64K Sep 5 22:51 svndumpfilter*
-rwxr-xr-x 1 root wheel 71K Sep 5 22:51 svnfsfs*
-rwxr-xr-x 1 root wheel 98K Sep 5 22:51 svnlook*
-rwxr-xr-x 1 root wheel 70K Sep 5 22:51 svnmucc*
-rwxr-xr-x 1 root wheel 89K Sep 5 22:51 svnrdump*
-rwxr-xr-x 1 root wheel 122K Sep 5 22:51 svnserve*
-rwxr-xr-x 1 root wheel 90K Sep 5 22:51 svnsync*
-rwxr-xr-x 1 root wheel 44K Sep 5 22:51 svnversion*
-rwxr-xr-x 1 root wheel 90M Sep 5 22:51 swift*
lrwxr-xr-x 1 root wheel 5B Oct 28 23:03 swift-autolink-extract# -> swift
-rwxr-xr-x 1 root admin 6.1M Sep 5 22:51 swift-build*
-rwxr-xr-x 1 root admin 734K Sep 5 22:51 swift-build-tool*
-rwxr-xr-x 1 root wheel 687K Sep 5 22:51 swift-demangle*
lrwxr-xr-x 1 root wheel 5B Oct 28 23:03 swift-format# -> swift
-rwxr-xr-x 1 root admin 6.1M Sep 5 22:51 swift-package*
-rwxr-xr-x 1 root admin 6.1M Sep 5 22:51 swift-run*
-rwxr-xr-x 1 root wheel 61K Sep 5 22:51 swift-stdlib-tool*
-rwxr-xr-x 1 root admin 6.1M Sep 5 22:51 swift-test*
lrwxr-xr-x 1 root wheel 5B Oct 28 23:03 swiftc# -> swift
-rwxr-xr-x 1 root wheel 12M Sep 5 22:51 tapi*
-rwxr-xr-x 1 root wheel 41K Sep 5 22:51 unifdef*
-rwxr-xr-x 1 root wheel 2.9K Aug 16 07:19 unifdefall*
-rwxr-xr-x 1 root wheel 63K Sep 5 22:51 unwinddump*
-rwxr-xr-x 1 root wheel 49K Sep 5 22:51 vtool*
-rwxr-xr-x 1 root wheel 45K Sep 5 22:51 xml2man*
-rwxr-xr-x 1 root wheel 135B Aug 16 07:22 yacc*
It is apparent that the files are physically located at that folder location and the installer installed missing components. The fact that MacOS's upgrade process uninstalls my development environment is unfriendly and Apple should be reprimanded.
I had faced the same issue when i removed one of the two Xcode installed.
I have solve this issue by Switching the path using terminal like below
$ sudo xcode-select --switch (drag Xcode here to get a path)
e.g sudo xcode-select --switch /Applications/Xcode\ 10.1.app
I got a similar error running Homebrew for the first time after upgrading from macOS Mojave v10.14 to Catalina v10.15.
It's never a good idea to run commands without understanding what's wrong with your installation of Homebrew and what the commands actually do. Your first and best option is to run brew doctor. This command will not only tell you if something is wrong but also how to fix the problem. In my case it showed:
Warning: Your Xcode is configured with an invalid path.
You should change it to the correct path:
sudo xcode-select -switch /Applications/Xcode.app
Once you fix the problem(s), run brew doctor again. Basically, repeat the process until you get the all clear message.
In some cases, you get something like:
Unbrewed dylibs/header files/static libraries were found in /usr/local/....
This will happen if you've installed software outside Homebrew that also use the same location to store their files. In many cases, it's safe to ignore these warnings.