bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28082: bash: /bin/rm: Argument list too long


From: Jonny Grant
Subject: bug#28082: bash: /bin/rm: Argument list too long
Date: Fri, 8 Sep 2017 13:04:13 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1



On 08/09/17 06:12, R0b0t1 wrote:
On Wed, Sep 6, 2017 at 7:54 AM, Jonny Grant <address@hidden> wrote:


On 15/08/17 12:45, Dmitry V. Levin wrote:

On Tue, Aug 15, 2017 at 08:19:13AM +0100, Jonny Grant wrote:

On 15/08/17 00:50, Paul Eggert wrote:

Jonny Grant wrote:

do you know which kernel API has this limitation?


All kernels have a limitation there to some extent, except perhaps the
Hurd. Sorry, I don't know what the limits are.


Ok thank you.

I imagine kernels just need a dynamic API, so it doesn't need to be a
fixed buffer.


It's a security limit rather than a fixed buffer, see e.g.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da029c11e6b12f321f36dac8771e833b65cec962


Thank you for your reply.

My Ubuntu 16.04 limit is 2MB it seems:
$ getconf ARG_MAX
2097152


This laptop has 16GB RAM, so it is a shame it isn't much bigger, or dynamic
so can be expanded when needed somehow. Those mapped pages of RAM wouldn't
be wasted, as just VM right?

I imagine a lot of people may have 60,000 files in a directory like me these
days. Latest Linux kernel just added support for billions of files per
directory I read.


If this is a strict requirement, you could switch to Hurd. I checked
with a Hurd developer(?) some time ago and one of their design
philosophies is no artificial limits.

I wasn't able to find an actual citation for this behavior, sadly.

R0b0t1.

Thank you for your reply.
Yes, probably Linux kernel / Glibc should include this improvement. I don't know who to ask there though.

Saves us each from needing to modularise/batch our commands in bash scripts.

Jonny





reply via email to

[Prev in Thread] Current Thread [Next in Thread]