Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Anonix.

Name: Cudder, HAHAHaruhi, and !w4lolitaKs 2008-05-05 23:42

Readers! Realize a reality rendered repugnant by the repression of reckless relentless regimes. Realize the retrogress of society, a reprehensible rabble of retardation and revolting reluctance. Really? Reevaluate and reconsider. Reexamine the results of today and recall remnants of yesterday. Rise, rebel, and retaliate against regression! A rebirth, redemptive and refreshing. Refuse to react without reason. Rather, rehabilitate the mind and restore knowledge and intelligence. Resurrect progress and never regret. Take the route of restless revival. Reinitiate The Revolution.

ANONIX
http://rapidshare.com/files/112878961/sayanonix.mp3.html

Name: !w4lolitaKs 2008-08-07 14:07

>>699,700
No problem there. Filenames containing spaces would be escaped while being fed into xargs.

Even the POSIX spec gives a solution:
If xargs is used to bundle output of commands like find dir -print or ls into commands to be executed, unexpected results are likely if any filenames contain any blank characters or newline characters. This can be fixed by using find to call a script that converts each file found into a quoted string that is then piped to xargs. Note that the quoting rules used by xargs are not the same as in the shell. They were not made consistent here because existing applications depend on the current rules and the shell syntax is not fully compatible with it. An easy rule that can be used to transform any string into a quoted form that xargs will interpret correctly is to precede each character in the string with a backslash.

But of course, all this is moot since the Anonix kernel will dynamically allocate as much RAM as required to hold the arguments (theoretically you could have up to 4GB of arguments on a 32-bit machine, but that would leave nothing free in the VAS for anything else; still, several hundred MB of arguments should be no problem), and from http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Argument-list-too-long it looks like recent Linux kernels are doing it as well.

Another thing, stuff like char linebuf[LINE_MAX] won't work as for A/x LINE_MAX==UINT_MAX (limited by available memory, of course.)

We're considering doing another release sometime this month.

Newer Posts