After upgrading to Catalina from High Sierra, I can not longer do simple things in my home direction (e.g., ls, etc.) under XQuartz, getting an error: Operation not permitted.
I recognize that this is due to the new access controls introduced in the previous version. There are many articles available online describing how to fix this for Terminal, by adding Full Disk access under the Security section of System Preferences. However, although it seems like an obvious variation, I don't see anything about making this work for XQuartz. And in fact, giving XQuartz and Xterm full disk access doesn't seem to solve the problem.
Has anyone understood what is going on here?
The solution, as pointed out by #dmr195 in the comments, is to add /bin/bash (or whatever shell) to the Full Disk Access list under the Security area of System Preferences.
The selector window that opens when you click the + button in that window does not allow you to navigate to /bin. However, by going there in a regular Finder window, you can drag and drop bash into the Full Disk Access list.
I was unable to get Finder to see /bin in order to drag it to the Full Disk Access (FDA) list. Solution was to create dynamic link to /bin directory from my Desktop, which finder could see.
Also helpful was using Mac's Hypterm to launch an xterm with full permissions, for example to create above link. Launch Hypterm, then update the locate database (the command is: updatedb). This will prompt you to give FDA to Hyperterm for every directory that /bin/bash also cannot see. After that, run xterm and voila, FDA.
Adding full disk access for bash will not work.
The solution is to open the Terminal app and type xterm in Terminal to open up the XQuartz, then you will have full disk access with XQuartz.
Related
Hello all,
Can anyone tell me how to clear the 'Recent items' list in Preview application of Mac OS X through code? Is there a terminal command that can do this?
Or is there any way to click on 'Clear Menu' in 'Open Recent' of the 'File' menu in Preview?
Alternatively, does someone know where Preview stores this information and how do to remove it?
Check out this image to see what I mean.
Ok, so none of the described methods on the websites I could find actually succeeded in getting rid of all the 'recent document' lists in all of my apps.
I feel the most common sense approach would be (for OSX 10.12 / Sierra):
First go to system settings > general and choose "none" in the recent file dropdown menu (my OSX is in another language so the exact terms might be different, but you should be able to see what I mean). / This will get rid of most, but not all recent-items in different apps.
Get familiar with Apple's 'defaults' command in terminal. Now, hunt for any lists you might still want to get rid off, e.g. none of the options mentioned in the answers already listed here helped to get rid of the recent-items list in Finders "GO" menu. I played around with the defaults command and found that: "write com.apple.finder "FXRecentFolders" '({})' && killall Finder" does the trick for me. Playing around I found similar solutions for many of the other apps that where still able to maintain a list of recent items.
Create a shell script containing the commands you found during step 2.
Schedule the script to be run automatically on a preset interval or action (e.g. log out). AND/OR create an alias in your shell's profile (or directly apply the script as a function inside it) so you can call it with a single command from your terminal. (for instance: I have created an alias to it, so when I now type "killrecent" in terminal, it empties all the recent-items lists I've been able to find.
Hope this will be of some help to others. Good luck!
open Preview ->- go to File ->- Open Recent ->- Clear Menu
You may try the approach outlined here, which is to run
defaults delete com.apple.Preview.LSSharedFileList RecentDocuments
in the Terminal (manually or through your app). However I tried this and it didn't work for me (OSX 10.11), since the Preview defaults file doesn't contain this entry.
You can use
defaults write com.apple.Preview NSRecentDocumentsLimit 0
which will hide all recently used items, but as soon as you set that number to anything greater than 0, they will show up again.
I also checked the ScriptingBridge Interface for Preview, but couldn't find anything useful. So unfortunately it looks like this is not possible.
with 10.11, there are at
~/Library/Application\ Support/com.apple.sharedfilelist/com.apple.LSSharedFileList.ApplicationRecentDocuments/com.apple.preview.sfl
On OS X 10.10 (Yosemite), the keyboard shortcut to paste the clipboard Command ⌘+V behaves like Page Up.
Right now I'm able to reproduce this issue only in Mail and Evernote.
Pressing Super+v, Super+v does pageup, paste though.
I use Karabiner to remap some keys, but never Command ⌘ keys.
If I close Karabiner it doesn't change anything.
I have at some point used vim, the pbcopy terminal command, and some OS configuration from https://github.com/mathiasbynens/dotfiles/blob/master/.osx
But I don't see why this could be a problem.
Does anyone know how to fix this or why it happens?
Are you able to replicate this issue in multiple users on your machine? If so, then the issue is likely to have something to do with the modifications you outlined above (such as Karabiner or Vim), or some larger operating system related issue.
If you're not able to replicate the problem in multiple users, it could be related to a problematic preference file. If you open a Finder window and navigate to ~/Library/Preferences, you could try moving the com.apple.HIToolbox.plist to your Desktop, logging out, then logging back in and testing again.
Let us know if either of those suggestions help!
I'm just meddling with OSX after a few years on Linux. There's a lot that I'm liking, but one thing that's slowing me down is that if I run the 'terminal' command via shortcut/spotlight/quicksilver, it whisks me off to any existing terminal in whatever space already has a terminal instance open.
I regularly like to pop up a terminal, run a quick command and then close it again, all the while staying in whatever desktop space I happen to be on.
...So, how do I do that on Mac?
Cheers...
Go to System Preferences -> Exposé & Spaces -> Spaces and check When switching to an application, switch to...
Download this tool called Visor
It lets you quickly get a tabbed drop down terminal using a hotkey like Ctrl-`.
Insanely convenient for working in the shell.
Try this tool: https://github.com/nmadhok/OpenInTerminal
This is a really handy tool for programmers on Mac as it lets you open the folder directly in Terminal. You can select multiple folders to open them in multiple terminal windows. You can also select files to open the parent directory in Terminal. This application works with Finder as well as without Finder which is a plus!
I use xcode 3.2.4 on snow leopard. Today when I tried to save a file on my project I get an error message saying: The document "nameOfFile.m" could not be saved. I tried reinstalling xcode but no luck. The file can be edited with other editors and I see the same behavior on all my projects as well as newly created projects. Any ideas?
Simply by rebooting the computer the issue was fixed.
We were having this problem in a lab environment where user files are mounted via NFS.
The client machines are running OS X 10.6.7 and the file server is running Debian Linux.
After much grief and reading /var/log/syslog on the client machine I discovered it was a subtle file locking / race condition issue with the file system. Evidently, when editing files in a "bundle" (e.g. as in an Xcode project), the OS is using some form of "safe writes" which involves writing transient data atomically to ~/Library/Caches/TemporaryItems/ (which of course is on the NFS mounted system) -- there is a race here that requires proper file locking. We hope we have fixed the problem by changing the nfs_mount options
as described in Mounting NFS volumes in OS X
Not sure why but the temp files ended in a odd state. In "/private/var/folders" I simply removed all the folders and it cleared up the problem
cd /private/var/folders
sudo rm -fR *
Note: never do a "sudo rm" unless you really know what you are doing. It can cause irrecoverable damage
I restarted XCode (by a force-quit, not just closing it) and that fixed it for me.
Make sure you have you mouse focused on the code area and not the file in the file list.
Cleaning the project (Product > Clean), then force quitting Xcode (Command + Option + Escape, select Xcode, click Force Quit) solved the issue for me. I'm not sure if the clean was necessary, but that was what I did. Upon re-opening the project, I let Xcode index the project before doing anything, then did a Build, and all is well.
Force quiting Xcode for me worked. I would recommend the same.
Hey........... even i faced the same problem..... But got the answer......
steps:
reveal in folder the project.
select the file that is locked
select 'GEt Info'
deselect ie uncheck the label 'LOCKED' in the Info.
I just ran into the same problem, then I noticed I ran out of disk space. You can disable the warning that pops up when you run low on disk space (perhaps not a wise thing to do). I did that a few days ago and was puzzled for a moment when this message appeared. They could've just said "Disk full" or something instead of "cannot save". Anyway if anyone ever runs into this just free up some disk space.
You might be able to save in an external editor because its not also building your app which might use up the little remaining space. It might also be why it worked after rebooting (if OS X cleaned up some cached stuff on reboot) so it seems plausible.
Either that or your HDD might have just crashed.
tic....tic....tic.....
In my Case, the File which was saying document could not be saved was basically Shortcut/Allies of the file present at another place.
I don't know why it was not able to save if it was opened by shortcut/allies in xcode but by overwriting(Copy and Paste) the orignal files to that shortcut my problem was solved.
Regards
Umair Bhatti
1.Right click on that file
2.Go to Show in Finder .
3.Click on get info .
4.Goto Sharing & Permission
Everyone,username,Fetching & selection ----You can choose appropriate read write option.
I have face this issue many times. I followed below steps to fixed this.
1. Select file->Show in Finder
2. Copy those file and past different destination.
3. Remove those file from xCode (to selecting show in finder)
4. Then again add those files from other destination to actual location
5. Clean code and run the code.
Another possible reason is that the file you are trying to modify is an alias (i.e. a soft link).
You will have to modify the source file directly in this case.
Thanks #Wayne Cochran,
When I use Xcode to save it, I rebooted the machine several times, and all failed.
So I changed to Visual Studio Code to edit and save. Then it's OK.
Just change the file editor
This can happen when you are working with a network hard drive (or are on a cloud) and not connected to the network (connection lost)
On my computer at work, any time I open a file located on a network share, GVim becomes completely unusable. Scrolling through the document can take 15 seconds to go one "page". Even using the movement keys to go from one word to another can take 2 to 3 seconds. This seems to be a new behavior, but for the life of me I can't remember changing anything that would cause it. I'm under the impression that Vim doesn't actually access a file except on open and on save. Is that right?
There are a few factors which may affect this.
First, make sure you have Vim setup to prefer storing the swapfile locally. If your $HOME is on a local drive, I tend to put this in my vimrc (which will either be at $HOME\_vimrc or $VIM\_vimrc). Make sure you create that directory, otherwise Vim will continue to use one of the other directories in the list.
set directory^=$HOME/tmp
This prepends the $HOME/tmp directory to the start of the list that Vim checks for where to place swapfiles.
Second, do the same for the backup file that Vim creates. Same situation as above but the option you'll be changing is backupdir instead of directory.
Third, make sure you disable the matchparen plugin. This plugin is new to Vim 7, so you may be used to using an older version of Vim. This causes frequent scanning of the file for matching parens, braces, etc. which can drastically slow Vim down when the file is on a network share. Again, this should go in your vimrc.
let g:loaded_matchparen = 1
If you only want to disable the plugin temporarily, you can use the command :NoMatchParen and then :DoMatchParen to re-enable it later in that Vim session.
Finally, if none of those help you can always copy the file locally and edit it.
Swap file has nothing to do with it. I have my swap file local and still have the problem. I use Process Monitor from SysInternals.com and it revealed bad behavior when attempting to open "\server\TestTool\foo\ReadMe.TXT"
It first attempts a CreateFile (aka, Directory open) on "\serve\". Notice the last character is missing. This will cause 4 seconds to time out with "OBJECT PATH INVALID".
Then it tries CreateFile on "\server\TestToo\". Server name is correct by the last letter of "TestTool" is clipped. Again, a 3 second time out with "BAD NETWORK NAME".
Finally it gets it right and calls CreateFile on "\server\TestTool\" which works right away.
Then CreateFile on "\server\TestTool\foo" which works right away.
Then CreateFile on "\server\TestTool\foo\ReadMe.TXT" which works right away.
WHY is it trying bad names for the server and the root directory??? What madness is this?
I fixed this issue after setting HOME path by force in advanced system settings.
(Your current HOME path would be a network directory.)
Control Panel > All Control Panel Items > System > Advanced system settings > Environment variables
Press "New..."
Variable name: HOME
Variable value: c:\Home\ **<-- Type your home directory**
A follow up on jamessan's answer: to disable the plugin automatically when you edit files on a share, put this line in you _vimrc
autocmd BufReadPre //* :NoMatchParen
You could consider installing LargeFile plugin. It disables a couple of features impacting the performance.
Having a similar issue as David Anderson, but no solution yet.
When loading \\ServerName\A$\B\C\File.txt Vim will do:
Open \ServerName\A$\B\C\File.txt
Then it does many loops like:
CreateFile \ServerName\A$ <-- Each taking roughly 1 sec
QueryDirectory \ServerName\A$\B
QueryDirectory \ServerName\A$
QueryDirectory \ServerName\A$\B\C
QueryDirectory \ServerName\A$\B
To compare with Notepad++ which loads files almost instantaneously there are more lines and Notepad++ never queries \\ServerName\A$.
Also the duration (Duration column) written in Process Monitor is low, but the time taken by Vim seem quiet high (Time of Day column) for the CreateFile \\ServerName\A$.
I've no plugins installed as far as I know and followed other tips to speed up network shares loading.
Note: The dollar is in the path. More weird is that Vim will load very fast on more recent Windows Server (2008 instead of 2003) with the same folder structure.
I had the same problem (slow gvim editing over network drive) and have fixed it. It was for me -- no kidding -- the titlestring.
Background: I use a vertically arranged taskbar with Windows 10. This has the advantage that my open windows behave like a growing stack from top to bottom. For example, see here some currently open windows with how-to-run.txt as a network file:
With that it makes sense, that the filename is going first in the window title of gvim and the path goes after that. So I used exactly the titlestring in my vimrc, which is still officially recommended in the help file vim81/doc/options.txt, line 8202:
set titlestring=%t%(\ %M%)%(\ (%{expand(\"%:~:.:h\")})%)%(\ %a%)
For local files that's ok, but for network files this is way too slow.
Now my fix:
set titlestring=
Same effect (filename first), but now gvim runs very fast for remote files as well!
BTW, I also tried all the above mentioned recommendations (directory, backupdir, matchparen, disabled all the plugins, tried the LargeFile plugin although I observed the slow gvim also for small files, etc.). I also changed my statusline to something really simple.
It all had no effect for me. But the funny titlestring...