We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rip --unbury myfile1 myfile2 restores the most-recently removed file, and ignores myfile1 myfile2.
rip --unbury myfile1 myfile2
myfile1 myfile2
Demo [excerpt]:
11:23 2600 typhoon:~/rip-demo > rip myFile1 myFile2 11:24 2601 typhoon:~/rip-demo > rip -u myFile1 Returned /var/folders/n0/q8x…3q0/T/graveyard-ibarland/Users/ibarland/rip-demo/myFile2 to /Users/ibarland/rip-demo/myFile2
Demo [full, w/ ]:
11:23 2597 typhoon:~ > mkdir rip-demo 11:23 2598 typhoon:~ > cd rip-demo /Users/ibarland/rip-demo 11:23 2599 typhoon:~/rip-demo > touch myFile1 myFile2 11:23 2600 typhoon:~/rip-demo > rip myFile1 myFile2 11:24 2601 typhoon:~/rip-demo > rip -u myFile1 Returned /var/folders/n0/q8xr07117v9b9smm8f35y6bcm2x3q0/T/graveyard-ibarland/Users/ibarland/rip-demo/myFile2 to /Users/ibarland/rip-demo/myFile2 11:24 2602 typhoon:~/rip-demo > tail -2 `rip graveyard`/.record 2024-12-18T11:22:31.622112-05:00 /Users/ibarland/some-other-old-history-not-part-of-demo /var/folders/n0/q8xr07117v9b9smm8f35y6bcm2x3q0/T/graveyard-ibarland/Users/ibarland/some-other-old-history-not-part-of-demo 2024-12-18T11:24:04.903094-05:00 /Users/ibarland/rip-demo/myFile1 /var/folders/n0/q8xr07117v9b9smm8f35y6bcm2x3q0/T/graveyard-ibarland/Users/ibarland/rip-demo/myFile1 11:24 2603 typhoon:~/rip-demo > rip --version rip 0.9.0 11:24 2604 typhoon:~/rip-demo > which rip /opt/homebrew/bin/rip 11:24 2605 typhoon:~/rip-demo >
The text was updated successfully, but these errors were encountered:
The syntax -u only accepts the graveyard path of the file, rather than the path within the current directory. So this should be instead:
-u
rip -u $(rip graveyard -s)/myFile1
which should fix it.
Maybe we could make the behavior compute the graveyard path automatically though?
Sorry, something went wrong.
I guess we should also make it error if the requested file to unbury is not found.
P.S., part of the reason you need to provide the graveyard path explicitly is because you can have multiple files with the same name:
touch tmp rip tmp touch tmp rip tmp rip -u tmp # Which `tmp` should be unburied?
The explicit interface (current approach) requires you to specify this via
rip -u $(rip graveyard -s)/tmp~1 # returns to `tmp` in current dir
But I can see this isn't as ergonomic. So maybe there's a better way.
No branches or pull requests
rip --unbury myfile1 myfile2
restores the most-recently removed file, and ignoresmyfile1 myfile2
.Demo [excerpt]:
Demo [full, w/ ]:
The text was updated successfully, but these errors were encountered: