Bundled installs fail with coreutils cp
#27
Comments
|
ah yikes. Could you post the results of I mostly use |
|
This is affecting me as well. whence cp
/opt/homebrew/opt/coreutils/libexec/gnubin/cpcp --version
cp (GNU coreutils) 9.3
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering. |
|
^^ Ditto. @kr3cj and I are on the same version. Here's the last line of manpage ( The manpage has this to say about
Here is the relevant parts of the brew installation info for I'm on the latest available version. |
|
Can you try with The coreutils changelog looks like it has some macos specific implementation (e.g., https://github.com/coreutils/coreutils/blob/master/NEWS#L407-L410) but I'm not sure exactly where the difference is. |
|
I tried the new branch but it didn't work. I dug in a bit deeper and found the real problem! It's the symlink that's no good... I added @@ -1,4 +1,5 @@
#!/usr/bin/env bash
+set -x
set -euo pipefail
@@ -112,6 +113,8 @@ install_v2_macos_bundled_installer() {
cp -r "${download_path}/tmp-awscliv2/aws-cli.pkg/Payload/aws-cli/" "${install_path}"
ln -snf "${install_path}/aws" "${install_path}/bin/aws"
ln -snf "${install_path}/aws_completer" "${install_path}/bin/aws_completer"
+ ls -l "${install_path}/bin/aws"
+ file "${install_path}/bin/aws"
rm -rf "${download_path}/tmp-awscliv2"
}With this we can see: Edit: Striking this as I realized after posting that the Below are some logs with more context... |
|
I didn't have time to do much more during the day. But I've been looking tonight. I did reproduce the original report which is that But, that said, this isn't the only tool that I've used (or built) that has issues with one over the other. It might be best to force the plugin to use the OSX default It's worth pointing out that coreutils comes with lots of "duplicate" binaries. Any of which may act differently than the system version. So, why does When the target directory already exists, GNU This is what causes the symlink to be bad. |
|
That is unexpected behavior. Seems like a simple fix would be to just replace |
|
I disagree with the notion that it's unexpected behavior. The docs for macOS's /bin/cp are quite clear - it's not unexpected so much as unstandard behavior. Given that macos has been steadily removing their BSD internals, I'm very uncomfortable hardcoding behavior to their system /bin/cp, when that may drastically change with macOS15. I have zero visibility into when or why macos will touch /bin/cp and that's not a topic I want to tackle. If that's not something you/your company are in favor of, I hope this is easy enough to fork against and I welcome PRs that make that easier going forward! Avoiding darwin-specific behavior is going to be my favored response given how weird macOS is lately and the prohibitive cost of testing the various flavors. It is extraordinarily frustrating having to deal with edge cases from a platform I can't test without spending $50 dollars a day on a test instance with AWS because I don't happen to own a macbook. I'm happy to expand my dev/testing if you and/or your company is willing to sponsor this repo. There's also no guarantee that this behavior won't hit Linux-based OSes (both Fedora and Debian upstream have coreutils 9, and while the current tests don't show it, I wouldn't be surprised if a similar error showed up next year on a CentOS/RockyLinux/Ubuntu). One of the most compelling arguments to me on the main asdf repo for POSIX compatibility is that it's just wildly hard to try to maintain compatibility across consumer systems that have no incentive to maintain that same compatibility and it's a folly to try, so the only sensible action is to target the POSIX standard. That macOS explicitly breaks POSIX compatibility because /bin/cp has been frozen since 2003 isn't reasonable for me to defend against. The most recent GH-Action runs suggest that coreutils-9 isn't the actual cause, so versionlocking wouldn't help either. |
|
To be clear, I'm still working on this and hope to have a solution soon |
Fair point. I suggested the opposite because I've been bitten by a lack of consistency with regard to Mac users having coreutils installed. Personally, I prefer the coreutils versions for the very reasons you state but, as they aren't always available, I've chosen to use the Mac versions.
Thanks for sharing your thoughts on what you'd prefer in the repository. Knowing this can help ease contributions. |
|
What about The following works locally (tested both with and without coreutils): diff --git a/bin/install b/bin/install
index 3966c98..956aed4 100755
--- a/bin/install
+++ b/bin/install
@@ -109,9 +109,9 @@ install_v2_macos_bundled_installer() {
mkdir -p "${install_path}/bin"
pkgutil --expand-full "${download_path}/AWSCLIV2.pkg" "${download_path}/tmp-awscliv2"
- cp -a "${download_path}/tmp-awscliv2/aws-cli.pkg/Payload/aws-cli/" "${install_path}"
- ln -snf "${install_path}/aws" "${install_path}/bin/aws"
- ln -snf "${install_path}/aws_completer" "${install_path}/bin/aws_completer"
+ mv "${download_path}/tmp-awscliv2/aws-cli.pkg/Payload/aws-cli" "${install_path}"
+ ln -snf "${install_path}/aws-cli/aws" "${install_path}/bin/aws"
+ ln -snf "${install_path}/aws-cli/aws_completer" "${install_path}/bin/aws_completer"
rm -rf "${download_path}/tmp-awscliv2"
} |
Describe the bug
If coreutils
cphas been set up as the preferred command forcp, asdf installs fail. This maybe is the problem of the user who chose to do this, but possibly there's an agnostic use ofcpthat could work for both cases, or the script added in #21 could try to detect whichcpis in use.Steps to reproduce
Expected behavior
Expected this to work.
Additional context
The issue is with different behaviour of
cp -a. With coreutils, the directoryb/is preserved in the destination when doing acp -a a/b/ c, with the systemcpon MacOS, it is not. Example.The text was updated successfully, but these errors were encountered: