Rethink how URLs and the destination path are provided
uncenter opened this issue · 3 comments
I find that cloneit x y z
is more intuitive than cloneit x,y,z
. A destination path would then be provided through a flag instead of as the second argument (--output
or --dest
maybe?).
As I'm writing this, I've actually thought of another possible solution: take the last argument (assuming there are 2 or more arguments provided), check if it is a URL (parse it and check if it has a certain protocol), if it is, download as normal, if not, interpret it as the destination path.
As I'm writing this, I've actually thought of another possible solution: take the last argument (assuming there are 2 or more arguments provided), check if it is a URL (parse it and check if it has a certain protocol), if it is, download as normal, if not, interpret it as the destination path.
This sounds good, I didn't like the --path
or passing any extra flag for cloning the directory. And cloneit <url1> <url2> <directory>
will be more intuitive as you said, so we can go with this approach.
cloneit x y z
makes more sense because other tools like cp
, mv
has the same style..
Hmm.. but then last argument can be a directory or url, it'll get confusing for someone new I think. We can also keep --path
as optional, but again that'll mess up everything.
I really don't know which way is actually better in this situation, but passing directory without a flag seems simple and easy enough.