Created attachment 372928 [details, diff] lddtree-sh.patch Attatched is a patch that makes lddtree.sh to work with busybox shell instead of /bin/bash. I think it is fairly close to work with any POSIX shell.
why is this needed?
(In reply to Rick Farina (Zero_Chaos) from comment #1) > why is this needed? It is needed for distros that don't want pull in /bin/bash to be able to use lddtree. Alpine Linux is planning to use it for generating initramfs images but does not have (and want to avoid) /bin/bash installed by default. Please point me to the pax-utils' upstream if this is not it. Thanks!
(In reply to Natanael Copa from comment #2) > (In reply to Rick Farina (Zero_Chaos) from comment #1) > > why is this needed? > > It is needed for distros that don't want pull in /bin/bash to be able to use > lddtree. > > Alpine Linux is planning to use it for generating initramfs images but does > not have (and want to avoid) /bin/bash installed by default. > > Please point me to the pax-utils' upstream if this is not it. > > Thanks! Upstream is vapier@gentoo.org. But I'm confused here. pax-utils hasn't shipped with lddtree.sh in ages. It currently ships with lddtree written in python.
(In reply to Anthony Basile from comment #3) > pax-utils hasn't shipped with lddtree.sh in ages. > It currently ships with lddtree written in python. pax-utils supports USE=python. I guess both versions are shipped and the Makefile decides according to the setting of USE_PYTHON which version to install.
(In reply to Martin Väth from comment #4) > (In reply to Anthony Basile from comment #3) > > pax-utils hasn't shipped with lddtree.sh in ages. > > It currently ships with lddtree written in python. > > pax-utils supports USE=python. I guess both versions are shipped and the > Makefile decides according to the setting of USE_PYTHON which version to > install. Ah yes, I see that now.
yes, i don't see much value in lddtree.sh anymore. the python version is the future (it does a lot more useful stuff, and is way faster). unfortunately, this change is not entirely correct. the point of using arrays is so that files get properly quoted. by converting to strings, you lose that. in fact, the stated use case (generating standalone images) is exactly what the python lddtree is designed to handle. if you're writing your own tooling on top of lddtree.sh, then honestly, you're doing it wrong for no good reason and you're wasting your time. $ lddtree --copy-to-tree /tmp/initramfs --bin /bin /bin/sh /bin/ls $ tree /tmp/initramfs/ /tmp/initramfs/ |-- bin | |-- ls | `-- sh `-- lib64 |-- ld-linux-x86-64.so.2 |-- libacl.so.1 |-- libattr.so.1 |-- libcap.so.2 `-- libc.so.6 see the announcement on gentoo-dev@ a while ago on the topic.
(In reply to SpanKY from comment #6) > yes, i don't see much value in lddtree.sh anymore. the python version is > the future (it does a lot more useful stuff, and is way faster). > > unfortunately, this change is not entirely correct. the point of using > arrays is so that files get properly quoted. by converting to strings, you > lose that. > > in fact, the stated use case (generating standalone images) is exactly what > the python lddtree is designed to handle. if you're writing your own > tooling on top of lddtree.sh, then honestly, you're doing it wrong for no > good reason and you're wasting your time. > > $ lddtree --copy-to-tree /tmp/initramfs --bin /bin /bin/sh /bin/ls > $ tree /tmp/initramfs/ > /tmp/initramfs/ > |-- bin > | |-- ls > | `-- sh > `-- lib64 > |-- ld-linux-x86-64.so.2 > |-- libacl.so.1 > |-- libattr.so.1 > |-- libcap.so.2 > `-- libc.so.6 > > see the announcement on gentoo-dev@ a while ago on the topic. thats exactly the thing i need, except that the tool need to be *way* smaller and cannot depend on python.
(In reply to Natanael Copa from comment #7) a stripped down python install can be easily under ~20MB, but i'm guessing that's too big and you don't want to try to strip it down further. i'm not wasting any more real time on extending the functionality of lddtree.sh. it makes no sense to write it twice. the python version is way faster and more maintainable (to understand, update, fix, extend, etc...), and can be imported into other python projects (which i do). a C version doesn't make sense as it has really none of those features. the shell version sticks around since it's already been written and provides some useful minimal functionality. i didn't pick python because i'm super in love with the language. if that were the case, i wouldn't be maintaining portage-utils & pax-utils (which are pure C). i picked python because it makes hell of a lot of sense and my experience with the languages shows that it's a clear winner. maybe you can find a python compiler that'll produce a standalone binary.
(In reply to SpanKY from comment #8) > (In reply to Natanael Copa from comment #7) > > a stripped down python install can be easily under ~20MB, but i'm guessing > that's too big and you don't want to try to strip it down further. Correct. It can be done in 80k (shell + scanelf) which is approx 0.4% the 20MB python thingy. I know most ppl don't care about that. A few does. > i'm not wasting any more real time on extending the functionality of > lddtree.sh. it makes no sense to write it twice. the python version is way > faster and more maintainable (to understand, update, fix, extend, etc...), > and can be imported into other python projects (which i do). a C version > doesn't make sense as it has really none of those features. the shell > version sticks around since it's already been written and provides some > useful minimal functionality. I'm glad you kept it. The minimal functionality does the job for me (with a few modifications). I created this bug after asking in #gentoo-hardened if there was any interest in porting it to posix shell (or actually busybox ash). > i didn't pick python because i'm super in love with the language. if that > were the case, i wouldn't be maintaining portage-utils & pax-utils (which > are pure C). i picked python because it makes hell of a lot of sense and my > experience with the languages shows that it's a clear winner. It makes sense yes. specially in gentoo context because you will hardly find any gentoo install without python. I also looked at implementing it in C too, so I have no problem understand why you didn't. Lua would be small enough for me though... yeah no worries, I understand why you picked python. > maybe you can find a python compiler that'll produce a standalone binary. Or I can fork it. https://github.com/ncopa/lddtree (the space in filename/path problem should be fixed too now) Thanks!
