#std..fs..rename only taking 2 arguements
57 messages · Page 1 of 1 (latest)
It may also be a good idea to use PathBuf instead of normal strings
https://doc.rust-lang.org/stable/std/path/struct.PathBuf.html it lets you build/edit paths element by element
An owned, mutable path (akin to [String]).
The path probably doesn't have a \ at the end (if it's saying it can't find the file)
You don't use PathBuf with format!
Use .push("")
Oh also put a .unwrap() (or actually error handling code) at the end of that line to see the errors
That gives you a PathBuf
Well you have format!("{} ...", path) where path is a PathBuf right?
?eval ```rust
let mut path = std::env::current_dir().unwrap();
dbg!(&path);
path.push("some_file.txt");
dbg!(&path);
[src/main.rs:3] &path = "/playground"
[src/main.rs:5] &path = "/playground/some_file.txt"
()
This is how you should add to the path ^
?eval ```rust
let mut path = std::env::current_dir().unwrap();
dbg!(&path);
path.push("some_file.txt");
dbg!(&path);
std::fs::rename(path, "/other").unwrap();
[src/main.rs:3] &path = "/playground"
[src/main.rs:5] &path = "/playground/some_file.txt"
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:6:33
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
And then you can use it in the rename operation ^
Yeah, Rust handles paths different than a lot of languages because platforms are very different in how they support paths
Plus the whole paths are not always utf-8 thing
What did the panic say?
Oh wait rename doesn't allow moving directories
It works within the same directory
Without extra crates (with platform integrations), a copy + delete
Use fs::copy
I went to the docs to check it that's how I know now https://doc.rust-lang.org/stable/std/fs/fn.rename.html
Rename a file or directory to a new name, replacing the original file if to already exists.
Important part: "This will not work if the new name is on a different mount point."
%username% is literal
Go look in the users/ folder
That's because your shell automatically replaces it
Instead of that use the directories crate to get the user's home as configured
UserDirs provides paths of user-facing standard directories, following the conventions of the operating system the library is running on.
Well preferably for this case https://docs.rs/directories/latest/directories/struct.UserDirs.html#method.document_dir
UserDirs provides paths of user-facing standard directories, following the conventions of the operating system the library is running on.
This will give you the proper behavior if the user has a different documents folder configured
Why is there a use?
use directories::UserDirs;
let dir = UserDirs::new().unwrap().home_dir();
You can see use function calls syntax (i.e (..) in a use statement. That's what it's complaining about here
Oh yeah I forgot to add that part it needs a .to_path_buf() at the end because the home_dir gives you a borrow
You can also do it without any use statements
let dir = directories::UserDirs::new().unwrap().home_dir().to_path_buf();
Use the .push() syntax
home_dir.push("randomstuff/file.txt");
If you want to print out a path for debugging it's usually easiest to use dbg!(&path);
PathBuf knows how to convert to platform specific separators
Also \ don't need to be \ \
Rust strings don't need them escaped
It shouldn't, it just adds a very tiny extra work for PathBuf when parsing the path
Removes a file from the filesystem.
Just give it the path you already have
It's okay
, working all the way through is a good exercise
I have done 200 line code examples on my phone
now that is painful
Especially with discord only showing 3 lines at a time
You don't need the format!()
remove_file(path)
I expect you to get a borrow error here
Because you already used path once
Yep, add a borrow to path on the first one copy(&path, ...)
The copy function is generic so it will take ownership of whatever you give it so we will just give it a borrow instead of full ownership
Yep
You need it one the copy because it happens first
You can also put it on the remove, but it's not really needed as you don't use path after it