I have a button in my Preference Bundle for my iOS tweak and I'm trying to have it delete a cache file so that the tweak will work properly.
The function for the button is here
- (void)respring {
system("cd /var/mobile/Library/Caches/com.apple.keyboards");
system("rm -R images");
system("rm version");
}
When I go into iFile afterwords the file is still there and hasn't deleted. Is there a way around this?
I haven't tested this, but my guess is that you are running three separate commands, with system().
So, you run one command to change directory, and then nothing else.
The second command to rm -R images is then run by itself, and not performed with /var/mobile/Library/Caches as the current directory.
You might try simply combining all three commands into one:
system("cd /var/mobile/Library/Caches/com.apple.keyboards; rm -R images; rm version");
If that doesn't work, report back and maybe there's another problem.
Related
I'm following this tutorial and when I get to the part where I call:
cp /tf_files/stripped_retrained_graph.pb bazel-bin/tensorflow/examples/android/assets/stripped_output_graph.pb
and
cp /tf_files/retrained_labels.txt bin/tensorflow/examples/android/assets/imagenet_comp_graph_label_strings.txt
They both say "No such file or directory".
As you can see in this image I can cd to the tf_files folder and see that the files are there.
I can also cd to /tensorflow/tensorflow/examples/android/assets and call ls which shows there's just a BUILD file there.
In the cp command is there supposed to already be a stripped_output_graph.pb file in the destination which gets replaced? Or is it meant to just be creating a new file there?
Is there some way of doing cp [source] [current directory] rather than specifying the destination as a path?
I've tried removing the file path part in hope that it just uses the source filename but that doesn't work.
Calling
cp /tf_files/stripped_retrained_graph.pb /tensorflow/tensorflow/examples/android/assets/stripped_output_graph.pb
and
cp /tf_files/retrained_labels.txt /tensorflow/tensorflow/examples/android/assets/imagenet_comp_graph_label_strings.txt
finally worked, wasn’t at all obvious that I’d have to change the destination path or what it should be though.
Also I accidentally saved a file as .p rather than .pb but managed to remove it using $ docker exec <container> rm -rf /tensorflow/tensorflow/examples/android/asset
s/stripped_output_graph.p
Now I managed to copy the files in correctly, but then when I installed the app it was still just running the regular demo app.
Not sure why it didn’t work, so frustrating.
When I rebuilt it after copying the files in I got these conflict messages
Are these normal to have?
It looks like maybe a different labels file is taking priority over mine, how can I reach the external/inception5h/imagenet_comp_graph_label_strings.txt file to delete it so my file is used instead?
Does the “external” part mean that I can’t actually access it?
I create centos with docker and After I start the container, I would remove a directory where there are other two directories.
and I do :
rm -f -r ./folder
and I obtain:
cannot remove 'folder': Device or resource busy
Anyone can help me?
Another pretty much simple answer is following:
1. Close all your terminal windows (bash, shell, etc...)
2. Start a new terminal
3. Execute your command again e.g.:
rm -f -r ./folder
4. done
Hopefully it helps others!
if you use windows, it's com.docker.backend.exe , terminate it, everything will ok.
If you know the reason why backend cause this problem, tell me.
This happened to me, until I closed the code editor VS-Code. Somehow VS code had the folder open so it could not close until the editor was closed.
Maybe you have that folder opened up somewhere. Try lsof to find the opened folder and then sudo kill <pid>. Afterwards, I believe you can remove the folder from there.
1- ps aux | grep docker.
From there you can get all processes containing "docker" word
2- #kill <process_id>
3- #rm -rf <thedir>
This folder exists.
I've tried moving it to the trash (it reappears and then this message pops up).
I've reset all permission to all enclosed folders to R+W.
I've repaired permissions on my drive.
Plugging in a real phone works fine (probably not relevant).
Just finished solving this problem. I think the main issue is that you are looking in the wrong place. These are the steps I took:
Make hidden folders visible by going to terminal and executing these two commands:
defaults write com.apple.finder AppleShowAllFiles TRUE
killall Finder
Go to /Users/myUsername/Library now it should be visible ( instead of myUsername you should have yours)
The Logs folder has no access permission, so change it. In case you can't do it manually, go to 3b.
3b. Open terminal. Write this command
sudo chmod 777 ~/Library/Logs
Be happy
P.S. In case you don't want to see hidden folder and files anymore,
execute this two lines in terminal:
defaults write com.apple.finder AppleShowAllFiles FALSE
killall Finder
So your permissions are invalid. You should look in ~/Library/Logs/CoreSimulator and check what the ownership and permissions are set to and fix them.
If that doesn't work, update your question with explanation of what you tried and show the current ownership and permissions on the relevant paths.
Turns out the actual folder for the log file didn't exist.
When looking in Console.app, filtering on CoreSimulator, I saw this:
3/15/15 9:50:52.840 AM iOS Simulator[7291]: Error opening
/Users//Library/Logs/CoreSimulator/iOS Simulator.log
When I went to the Logs directory, CoreSimulator wasn't there, so I:
sudo mkdir CoreSimulator
sudo chown <user>:staff CoreSimulator
touch CoreSimulator/iOS\ Simulator.log
sudo killall -9 com.apple.CoreSimulator.CoreSimulatorService
run this command in terminal before code building.
Cheers!
I have a rails app that I inherited. In deploy.rb, it performs the following commands:
run "mv #{shared_path}/log/#{rails_env}.log #{shared_path}/log/#{rails_env}_old"
run "touch #{shared_path}/log/#{rails_env}.log && chmod -R 777 #{shared_path}/log"
So you can see it's moving the existing log file to one called _old and then creating a new one.
This causes a problem when in some situations, the first deploy fails. When I deploy again, it overwrites the _old file a second time and now the previously existing logs are gone.
The thing is, that I don't understand why the deploy script is doing this. I don't understand why it was written like this in the first place. I believe everybody would be fine if we just left the log files alone during the deploy.
Does anybody have any clues for me?
Remove it, and use log rotate.
What the deploy script is doing is good because log files get big really soon and writing to big file is costly. You should use log rotate or some other utility. But if you want to keep it simple, give unique file names by appending timestamps
run "mv #{shared_path}/log/#{rails_env}.log #{shared_path}/log/#{rails_env}_old_#{Time.now.Time.now.to_i}"
run "touch #{shared_path}/log/#{rails_env}.log && chmod -R 777 #{shared_path}/log"
I was trying to set up a bash command in Terminal on a Mac.
The scripts run correctly when I execute them directly.
I set up symlinks in /usr/local/bin/ to the current location of the scripts. When I try to run it off the symlink, it doesn't work. I don't believe the issue is the $PATH, because pip, git, ipython all exist in this location. When I edit the $PATH setting, these fail.
Suggestions?
ls -l /usr/local/bin/foo and see where your symlink is actually pointing. Betcha it's broken.
If not, try running /usr/local/bin/foo. If that works, it was your PATH that's wrong, despite what you said in the OP.
The only other thing that would cause this behavior is if the script is reading $0 (its own name as executed). With a symlink, that will have a different value.
I found my own answer... The symlinks were created by an automated file which was gabbing my pwd. I was also using virtualenv, so to get it to work, I had to activate the virtualenv and be inside the folder that had the script that created the symlinks.
I install my commands in $HOME/bin instead of /usr/local/bin, but it does not matter much. As hinted in the comments, one question is whether the symlinks are set correctly.
Check which command the shell thinks you should execute: which command
Check that the link in /usr/local/bin points to the correct file (and has execute permission, etc):
ls -l /usr/local/bin/command
ls -lL /usr/local/bin/command
Check that the interpreter path in the shebang is correct:
file /usr/local/bin/command
Check that /usr/local/bin is actually on your PATH: echo $PATH
If none of that shows up a problem, show us the results of the commands above.