On 16/10/2025 23:00, Collin Funk wrote:
I was having a look at having 'cp' handle very long file names (see bug 70586 [1]):$ mkdir -p `python3 -c 'print("./" + "a/" * 32768)'` $ cp -r a b cp: cannot stat '[long file name snipped]': File name too long $ rm -rf a b The first step seemed to be changing this prototype from copy.h: bool copy (char const *src_name, char const *dst_name, int dst_dirfd, char const *dst_relname, int nonexistent_dst, const struct cp_options *options, bool *copy_into_self, bool *rename_succeeded) _GL_ATTRIBUTE_NONNULL ((1, 2, 4, 6, 7)); to also have a SRC_DIRFD and and SRC_RELNAME parameter. While changing all the invocations of this function, I noticed it was used to handle the --target-directory directory option. I couldn't find the thread where this was added to check if this was discussed, but was wondering if it makes sense to also add the --source-directory option to those programs. In the case of 'cp' this would allow you to copy files from paths that are too long for the 'open' or: open (AT_FDCWD, src_name, flags); WDYT? Collin [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70586
One use of --target is to simplify use with xargs. I.e.: find source/ | xargs cp --target=dest/ Going the other way and supporting copying a file to multiple destinations is much less required, so we probably don't need a --source-directory option. cheers, Padraig
