Closed Ambrevar closed 6 years ago
Why not keep the cp syntax and leave destination to the last argument?
When I start with cpd, I thought about how to handle the arguments. cp offers different sorting of sources/destination. I decide to keep it simple and only to support one syntax, this with -t where the target is the first argument and this must be a directory.
Perhaps was this decision to fast and it would be possible to parse the line to support all cp variants and pick where is the destination drive. Maybe later, now I have no mood.
cpd: line 828: ${target@Q}: bad substitution
Oops, no idea yet. I am working on some patch that will affect this too
I'm not a big fan of the DESTFOLDER SOURCES...
syntax.
cp
's default syntax.I suggest using the default syntax which would be less confusing to newcomers
The default syntax rules are quite simple if I'm not wrong:
SOURCE DESTFILE
if DESTFILE
does not exist.SOURCES... DESTFOLDER
otherwise.I agree so far.
Keeping -o would be OK? Or do you have suggestions how to distinguish between enqueue a new job and call some cpd command?
Sorry, I don't understand how -o
is related to this issue.
Why would there be a problem in distinguishing between enqueuing and commands?
I don't quite understand this form: cpd <command> [<argument>...]
. What is <command>
?
What is \<command> ?
You refer to the help info? Well, \<command> looks right now like an option but it works as a command.
I don't understand how -o is related to this issue.
The problem for me is how to distinguish between my own commands/options and these of cp when parsing the input. Often is -- used to mark the end of own options and giving the rest to some other program. But that looks not so nice. Maybe a make a fallacy.
So, encapsulate all cp options into my own -o is right now the solution.
Ok, when I start with cpd I used getopts for laziness, now we have the trouble. Using a usually syntax for commands without a hyphen could solve all questions. I will see...
I don't think there is a point in having two forms.
As it is now, cpd actually has only one form, that is cpd OPTION DEST SOURCES...
.
The -o
switch to pass options to cp
is perfectly fine in my opinion.
It's simple and non-ambiguous.
As it is now, cpd actually has only one form, that is cpd OPTION DEST SOURCES....
I have no clue what make you think that. The help output is pretty clear and tells a different story.
I don't think there is a point in having two forms.
When you look at your initial post at the Arch forum, you use by the way also two forms, cpd and cpc. The first for daemon stuff, the latter to enqueue new jobs.
This solve the trouble how the distinguish between own options and cp options as long as my own do not use the same letters for different things.
OK, now I understand what you meant.
I think the current synopsis is fine.
The copy does not seem to work: there is no file and it takes 6 seconds to copy the README.
(g507937@sst-p1307278fl)[~/projects/cpd/@master]
> ./cpd -P
Start [ 1] [/dev/sda ] ~37/projects/cpd/foo <- README.md
Done [ 1] [/dev/sda ] ~37/projects/cpd/foo <- README.md
All done
#[STATUS] End time 2017-11-27 10:39:20, duration 6.470s
(g507937@sst-p1307278fl)[~/projects/cpd/@master]
> ls foo
(g507937@sst-p1307278fl)[~/projects/cpd/@master]
>
So in the end do you want to keep the -t
option on by default? (I.e. first arg is the dest folder.)
I hope you are still in simulationMode ;-) Sorry, no hint that this is ON when running -P, will change this.
Until I have redesign my command line parsing, yes, first argument is dest folder.
Got it, forgot to disable simulation mode after my last update.
Guess this can closed too click
README.md is in the current directory.
From the help message, destination comes first, then the source. Correct? Why not keep the
cp
syntax and leave destination to the last argument? Either way does not seem to work.