| Summary: | libtool.eclass depends on GNU chown - not available on all platforms | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Christian Bricart <christian> |
| Component: | FreeBSD | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | bsd+disabled, douglas.miller, prokennexusa |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | FreeBSD | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | proposed implementation of estat | ||
|
Description
Christian Bricart
2013-05-07 21:57:07 UTC
@base system, I can't think of anything better atm but what about:
local perms="$(find ${file} -maxdepth 0 -printf '%m')"
...
chmod ${perms} ${file}
its not very satisfactory but since we require gnu find, stat is rarely portable and not required to be gnu, it should work on every system; it also saves using a temp file.
(In reply to comment #1) i'd add a function to portability.eclass called "chmod_reference" and once that's in place, we can cut libtool.eclass over to it (In reply to comment #2) > (In reply to comment #1) > > i'd add a function to portability.eclass called "chmod_reference" and once > that's in place, we can cut libtool.eclass over to it do you really want this or rather some push perms / pop perms mechanism ? cp -p for saving the perms isn't terribly beautiful either (In reply to comment #3) a generic stack doesn't make sense. i would have used `stat -c %a`, but i know BSD's stat program is utterly worthless and doesn't support that either. probably a stat helper where you can give it the format as expected by GNU stat would be sufficient: estat %a <files> (In reply to comment #4) and then the above find command does precisely this, with the advantage of not needing a wrapper, esp. a wrapper that needs to convert printf format strings... *** Bug 469128 has been marked as a duplicate of this bug. *** (In reply to comment #5) i don't want to inline BSD workarounds everywhere. hence my suggestion to write something for portability.eclass. (In reply to comment #7) fair enough, but please explain me how you would write this estat function because I have no clue how to write a parser for the format specifiers. OTOH, its not really a "workaround" but rather a fix to use what we are guaranteed to have and not something system dependent (we require gnu find, I couldn't find a posix manpage for stat and while most stat(1) will have equivalent basic features the syntax differs a lot between systems) (In reply to comment #8) `stat` isn't covered by POSIX. BSD's stat has a format specification similar to GNU's stat, just the format specifiers are completely different. i would start simple and accept just 1 field rather than a whole format string (`estat %a`). then do a case statement to map the GNU form. local fmt=$1; shift if <gnu stat>; then stat -c "${fmt}" "$@" else case ${fmt} in %a) ...find... *) die "unhandled form";; esac fi are all $USE variables available in eclasses? so may be something practical to switch for GNU tools available?: use userland_GNU && do_something_in_GNU_tools_syntax || do_something_in_BSD_syntax second, would be parsing output from `ls -l` be more portable..? *** Bug 469250 has been marked as a duplicate of this bug. *** (In reply to comment #10) nah, its better to do sth like 'stat --help | grep -q GNU' to determine it so that we don't need to declare userland in IUSE. also, if you want something reliable you don't want to parse ls output (In reply to comment #9) sounds sane enough for one format specifier; I'd like to have some kind of spec for this function though, so that'd be: format specifiers are the one from gnu stat; format specifiers are more limited but estat can be extended at will. Then I don't really see how to handle more complex format specifiers (which was what my question was about actually): how to parse formats like '%a%A%b' or '%a foo %b'? I tend to think we'll need to restrict it to only one format specifier. Do you have any workaround or patch until you are able to deply a fix? I am unable to emerge any software at the moment, so in essance I am 'system down'. (In reply to comment #13) I committed the find workaround; it's technically better than cp -p and the estat idea is nice but I still don't have a precise idea of how to do it. We can add the estat function and use it later without breaking users systems anyway. (In reply to comment #14) > (In reply to comment #13) > > I committed the find workaround; it's technically better than cp -p and the > estat idea is nice but I still don't have a precise idea of how to do it. We > can add the estat function and use it later without breaking users systems > anyway. Alexis Ballier, Thank you for the quick fix, I will sync my Portage tree now. (In reply to comment #14) your code has wrong quoting, the maxdepth makes no sense, and i'm still not interested in inlining BSD workarounds in code. implement the estat idea before i punt this crap. (In reply to comment #16) I understood that, but there is no point in completely breaking users' system meanwhile. If an estat function with only one format specifier allowed is fine by you, then this can be done quickly. Otherwise, my questions from comment #12 still stand: such a function can be easily extended to more format specifiers, but it seems much harder to extend it to a whole printf format ('%a foo %a'). Created attachment 348154 [details, diff]
proposed implementation of estat
.
(In reply to comment #18) > Created attachment 348154 [details, diff] [details, diff] > proposed implementation of estat note: this implementation is done as such on purpose to guarantee the same output and behavior regardless of the underlying system; yours wasnt portable in that sense. *-fbsd is gone. |
