Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
file put cmd: trailing slash on directories should be optional #259
One thing that is unnatural to me is that the result of
Command 1 (without a trailing slash):
Command 2 (with a trailing slash):
The destination path is /xtest for command 1 and / for command 2. The latter is the correct one because it is the default destination path when none is provided. To define a destination path other than / the user has to provide it explicitly.
Command 3 (with a destination path and a trailing slash on local path):
This method is the correct (and existing) way to include a destination path. In this example it is the same as the directory, but it could be any other path. Here, the result doesn't depend on the presence of the trailing slash, which is a good thing:
Command 4 (with a destination path and no trailing slash on local path):
Note: Consistency with rsync command could be the reason to have implemented
Behavior of rsync command:
Very valid @Thierry61 and to me is still not clear where/how to find the balance for this thing.
When I was discussing this with other folks some time ago, I saw like some arguing against, but as many as those in favor (specially our IT folks back then found it natural), and it wasn’t clear enough to me it should be changed (and higher priorities came up also).
Personally I find it very easy and powerful that I can decide just with a slash if it’s a folder or its content/children that I’m uploading, and the same when I decide where I’m uploading it to. Although, I do understand that can also be easily missed and/or it could confuse others. It sounds to me this is probably related to different background of users which makes it look very strange and unnatural, and for others like a no brainer thing.
E.g. if the slash was ignored in the source how would you like to signal when you want to upload the folder and not only its children? i.e. "i want to upload folder
Then, what if I want only the children of
So what I see with the slashes in the source and destination you have all the flexibility and power for all the combinations of use cases in a very consistent way.
If I'm not mistaken, we are basically discussing the
Personally, I've always preferred
Perhaps we should take a poll. :)
btw, your use cases, using cp behavior:
As I recall,
I think that's basically it as a summary @dan-da , with the exception that I think you wouldn't be able to copy a folder with a diff name in the destination? well...I think you need the
btw, I will just point out something a little bit subtle above. In this command:
The * is actually interpreted by the shell and individual filenames are passed to cp. This is called globbing or shell expansion. There might be issues or inefficiencies if the number of matching files is huge (thousands, millions). Also, exact globbing behavior/syntax may vary from one shell to another.
rsync may be using special
Related to this, and possibly something that should be opened as a separate issue, cp accepts any number of source arguments with the final argument interpreted as dest. This means one can do things like:
Which is what the
Also shell expansion offers an abbreviated way to filter files and send multiple args via ranges and sets:
Examples from rsync man page: