-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
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
FileIO usage tweaks [DEVINFRA-640] #429
Conversation
|
||
/// The destination when transfering files | ||
dest: Option<Target>, | ||
|
||
/// List a directory | ||
#[clap(long, short, conflicts_with_all = &["dest", "delete"])] | ||
list: bool, | ||
#[clap(long, short, value_name="TARGET", conflicts_with_all = &["dest", "delete"])] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Slight change, this will mean you won't be able to do swift-files 192.168.0.222:/data --list
any longer but IMO makes reading the code slightly easier.
} | ||
} | ||
} | ||
|
||
self.link.unregister(key); | ||
Ok(()) | ||
|
||
if total_bytes_read == 0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's possible to differentiate between whether the file attempting to be read is actually a 0 byte file or if the file read failed here (because the file didn't exist or because the user isn't allowed to read the file).
Thinking about this some more, maybe the error message should be more descriptive? Something like "File {} read was 0 bytes long. This could indicate that the file doesn't exist or is not accessible."
We should also potentially delete the file locally, as the user will see a 0 bytes file after running this at the moment.
What do others think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the more informative message, IMO leaving the file is fine if we have the warning since the remote file could be a zero byte file.
console_backend/src/bin/files.rs
Outdated
.into_remote() | ||
.context("--delete flag requires <SRC> to be a remote target")?; | ||
let remote = target.into_remote().context( | ||
"--delete flag requires <TARGET> to be a remote target of the form <HOST>:<PATH>", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's change to FILE_PATH here too
This could either mean the file actually is 0 bytes, the file doesn't exist, or the file isn't allowed to be accessed
Changed "Piksi" to "Swift device" and separated to the "cp to" and "cp from" examples
This gets clap-rs/clap#3421 which enables the help to show when no arguments are given and there are defaults.
console_backend/Cargo.toml
Outdated
@@ -31,7 +31,7 @@ serialport = { git = "https://github.com/swift-nav/serialport-rs.git", default-f | |||
directories = "4" | |||
anyhow = { version = "1", features = ["backtrace"] } | |||
serde_yaml = "0.8.23" | |||
clap = { version = "3.0.14", features = ["derive"] } | |||
clap = { git = "https://github.com/clap-rs/clap", rev="73847b32ff1245167a6d39ddd4fa90b93d1305ce", features = ["derive"] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upgraded to Clap on master in order to get this fix clap-rs/clap#3421 which was making the help not appear when no arguments were given (as all are now optional and some have defaults). It hasn't been included in a Clap release yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fortuitously 3.1.0 was released overnight, so have upgraded to that now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sheesh just in the nick of time 😄
Was also thinking that maybe we could take this opportunity before the tool is released to slightly rethink how the arguments work. Maybe a subcommand approach might work better? Something like
Or maybe It feels slightly odd (to me) that |
Yeah I was trying to make the tool more like scp and there was no clear analog there. I think subcommands for consistency make sense. I think you can alias subcommands so maybe
probably would want to run that by stefan first |
If we do this we should probably mirror Linux, but alias with Windows equivalents. So rm/del, ls/dir, and cp/copy. The problem we had with subcommands last time was they weren't discoverable and as Steve mentioned, Stefan has already approved the current scheme so we'll need to get his sign off again. |
Ah I forgot about the subcommand discovery problem. I'll avoid rocking the boat then, seeing as Stefan is already happy and we need to deliver soon. |
Addresses some feedback from Stefan:
list
anddelete
to not mentionSRC
192.168.222.0:
)The one bug I couldn't replicate was "Upload non existing file hangs" which does throw an error rather than hanging for me on Linux, so might be a Windows bug? Does seem a bit weird though given
File::Open
should return an error if the file doesn't exist. Will see if I can try on Windows and report back.