if I use globbing in fperms e.g.: src_install() { ... fperms a+x /opt/${PN}/jre/bin/* ... } the globbing is resolved on the final installation path "/opt/${PN}/jre/bin/*", while fperms tries to apply the changes on the files in the sandbox, witch leads to error messages like: chmod: cannot access '/var/tmp/portage/dev-util/smartgit-20.1.0/image/opt/smartgit/jre/bin/*': No such file or directory Reproducible: Always
This has nothing to do with the sandbox. /opt/${PN}/jre/bin/* does not exist on your system, so the glob is not expanded. The files should be staged in ${ED}, so you could apply the glob there instead. For example: pushd "{ED}" || die fperms a+x opt/${PN}/jre/bin/* popd || die
Or alternatively: chmod a+x "${ED}"/opt/${PN}/jre/bin/*
the problem from my perspective is, that fperms adds ${ED} automatically to the path, while globbing does not. If I use fperms a+x /opt/${PN}/jre/bin/* fperms uses the right directory (/${ED}), while globbing uses the wrong (/) If I use fperms a+x ${ED}/opt/${PN}/jre/bin/* fperms uses the wrong directory (/${ED}/${ED}), while globbing uses the right (/${ED}) So I cannot use fperms with globbing at all, and that was unexpected for me. Would you prefer using chmod over fperms in that case?
(In reply to Christian Strahl from comment #3) > If I use > fperms a+x ${ED}/opt/${PN}/jre/bin/* > fperms uses the wrong directory (/${ED}/${ED}) I wonder if we could make this less stupid. Here's what PMS says about fperms: > fperms > Acts as for chmod, but takes paths relative to the image directory. Failure > behaviour is EAPI dependent as per section 12.3.1.
Sorry, your misuse of the term "sandbox" caused me to overlook what your bug report was really about. I don't really see a simple way to improve how fperms works. I would opt to just call chmod || die directly.
(In reply to Zac Medico from comment #4) > (In reply to Christian Strahl from comment #3) > > If I use > > fperms a+x ${ED}/opt/${PN}/jre/bin/* > > fperms uses the wrong directory (/${ED}/${ED}) > > I wonder if we could make this less stupid. Here's what PMS says about > fperms: > > > fperms > > Acts as for chmod, but takes paths relative to the image directory. Failure > > behaviour is EAPI dependent as per section 12.3.1. I think the unfortunate ${ED}/${ED} behavior is required for compliance with PMS.
(In reply to Christian Strahl from comment #3) > the problem from my perspective is, that fperms adds ${ED} automatically to > the path, while globbing does not. This is not Windows. You should know how filename expansion works in bash. > So I cannot use fperms with globbing at all, and that was unexpected for me. > > Would you prefer using chmod over fperms in that case? Yes.
(In reply to Michał Górny from comment #7) > (In reply to Christian Strahl from comment #3) > > the problem from my perspective is, that fperms adds ${ED} automatically to > > the path, while globbing does not. > > This is not Windows. You should know how filename expansion works in bash. > I know how filename expansion works in bash. I jus didn't know that fperms prepends ${ED} to paths. In the same ebuild I use other commands that don't have that behavior. e.g.: java-pkg_regjar ${ED}/opt/${PN}/lib/*.jar Here I can use ${ED} in the path because java-pkg_regjar doesn't prepend ${ED} by itself.
What is the goal here? Add another helper that acts like fperms, but doesn't prefix the path with ${ED}? That would just be chmod with built-in error checking. (IMHO, not worth the effort.) Or, have fperms itself perform globbing relative to the image directory? I'd rather not open that can of worms, because globbing is a feature of the shell.
(In reply to Ulrich Müller from comment #9) > What is the goal here? Add another helper that acts like fperms, but doesn't > prefix the path with ${ED}? That would just be chmod with built-in error > checking. (IMHO, not worth the effort.) > > Or, have fperms itself perform globbing relative to the image directory? I'd > rather not open that can of worms, because globbing is a feature of the > shell. No reply. Closing.
Necrobump...because I just hit this unexpected behaviour while bumping "dev-util/android-ndk". fperms() is just a poor man's "chmod" with no tangible benefit and considerable drawbacks. Let's consider dropping fperms() entirely during the next EAPI push, because it does nothing for us, obfuscates core shell fundamentals, and detracts from meaningful work elsewhere. Let's last-rite fperms() once and for all. The '90s are calling and they want their useless shell wrappers back.
I'm reopening for further discussion. Let's also add fowners since that's probably the same box.
It is the same for all helper commands. They all add ED to the destination path, therefore globbing in the image directory doesn't work for any of them. That is just how the shell works, and I don't see what we could do about it.
(In reply to Cecil Curry from comment #11) > fperms() is just a poor man's "chmod" with no tangible benefit and > considerable drawbacks. Nobody will stop you from using plain chmod as suggested in comment #1, or using fperms on the directory recursively. But let's count how often these commands are used in the tree (simple grep, so the number may include some false positives): fperms: 1180 fowners: 853 chmod: 721 chown: 366 Checking a few ebuilds, most of the chmod and chown calls are in src_prepare where there is no image directory (so the helpers cannot be used). chmod and chown with globbing, in src_install: 'chmod.*\*' matches 30 times 'chown.*\*' matches 3 times So usage of these commands with globbing is a corner case, and is not a good reason to remove the helper commands (which are otherwise used more often than their plain counterparts). Closing again, as discussed in #gentoo-pms.
