On (my) Interix, TEMP and TMP contain something like 'C:\Windows\Blah'. Portage concatenates these with colon separators, passes this to the bash printf builtin, which interprets the backslashes as god-knows-what, and then pipes the mangled output to something like: tr ':' '\0' | sort -x -u | tr '\0' ':' results: GIGO, obv. So I've enclosed a patch to stop this. Also, maybe this is a quirk of my system, somehow, but I have always had lots of problems with commands like: find ${foo} | xargs grep ${bar} Somehow, grep seems to run out of memory handling the larger lists that xargs might feed it. To prevent these problems, I have gotten into the habit of doing find ${foo} | xargs -s 4000 grep ${bar} I should really figure out what's wrong with grep -- but in the meanwhile I patch my portage to do -s 4000.
Created attachment 218613 [details, diff] apply interix-temp patch and gentler xargs usage on interix
Created attachment 218615 [details, diff] apply interix-temp patch and gentler xargs usage on interix oops, wrong patch.
Created attachment 218617 [details, diff] Don't mess with TEMP/TMP on Interix as they are non-standard and wackyness will ensue
have you bootstrapped yourself on interix, or are you using the system from the install DVD images? because those contain propper .profile's, installed for each user you instructed setup to set up ;p. those $HOME/.profile's fixup some things, mostly regarding the (at our company) later building of windows binaries. but there are also things like translating TEMP. etc to interix paths...
(In reply to comment #4) > have you bootstrapped yourself on interix, or are you using the system from the > install DVD images? because those contain propper .profile's, installed for > each user you instructed setup to set up ;p. those $HOME/.profile's fixup some > things, mostly regarding the (at our company) later building of windows > binaries. but there are also things like translating TEMP. etc to interix > paths... I used the DVD and I haven't touched the .profile. At a glance, it seems to explicitly set them to be /windows/ paths: export TMP="$(unixpath2win $TMPDIR)" export TEMP="$(unixpath2win $TMPDIR)" Maybe the reason it does this, despite it being very non-unixy, is that if win32 processes inherit, i.e., TEMP=/tmp from Interix (for example, due to manual command-line execution), bad things will probably happen.
ah - of course i was wrong - TEMP needs to be windows-ish for cl.exe (the windows compiler) to be executable... damn :] why am i not having problems then? hmm...
What's the output of xargs --show-limits on Interix? If that output is wrong, we better patch xargs than random code that uses xargs (and relies on it doing the right thing).
(In reply to comment #7) > What's the output of xargs --show-limits on Interix? If that output is wrong, > we better patch xargs than random code that uses xargs (and relies on it doing > the right thing). I get: Your environment variables take up 3575 bytes POSIX upper limit on argument length (this system): 1042953 POSIX smallest allowable upper limit on argument length (all systems): 4096 Maximum length of command we could actually use: 1039378 Size of command buffer we are actually using: 131072 I just tried doing find /usr -print0 | xargs -0 echo and sure enough it gave me "xargs: echo: Cannot allocate memory" So, I was blaming this on grep but clearly that is wrong. Chasing down the highest -s argument that works here in typical O(log n) style, -s54597 works but -s54598 runs out of memory. If you know how to fix xargs that would be awesome.
(In reply to comment #8) > (In reply to comment #7) > -s54597 works but -s54598 runs out of memory. One more note on this: the number autotools derives for "maximum length of command line arguments" is 24577.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > -s54597 works but -s54598 runs out of memory. > One more note on this: the number autotools derives for "maximum length of > command line arguments" is 24577. If this is going to be a findutils bug (which, to be clear, I agree it should be), should I make a new one for the TEMP/TMP handling issue in portage?
If you want it to be addressed, I'd say yes, otherwise it'll get lost.
(In reply to comment #11) > If you want it to be addressed, I'd say yes, otherwise it'll get lost. My thoughts exactly. It's #307729.
in now came back to this bug after a while. tracing a little through xargs, i found out that execvp itself issues the cannot allocate memory error. thus it seams that exec*() cannot handle whatever is returned from sysconf(_SC_ARG_MAX). guess thats a bug ;p however, i can work around this by using the static defined ARG_MAX, which is far less than _SC_ARG_MAX, and makes it work fine. just need to get the patch upstream, or some sort of other solution, they'll accept.
i have a patch for this now, that is accepted and pushed upstream already - last build test in the makes, and i'll commit it to the tree after that :)
