Date: Sat, 17 Mar 2001 16:27:28 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: stable@freebsd.org Subject: Re: Not only ftpd's problem with ls */../*..... Message-ID: <200103180027.f2I0RSn96769@earth.backplane.com> References: <local.mail.freebsd-stable/200103172107.f2HL7Ea02611@cwsys.cwsent.com> <200103172253.f2HMrZ008412@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Yes, I'm considering the following:
:
: gl_flags |= GLOB_MAXFILES
: gl_match = filemax
:
:Since gl_match is only used as an input parameter at the moment.
:Another approach is to limit the number of bytes returned to ARG_MAX,
:but I somewhat dislike that; it makes more sense to me to specify the
:number of paths instead.
:--
:Jonathan
Hmm. Well, I like the idea of adding a flag to glob_t->flags but I
would prefer not to add another element to the glob_t structure
that would make it incompatible with existing programs. Remember the
mess changing FILE caused.
How about a combination of glob_t->flags and a global limit that can
be set with a new api call, setgloblimit()? Or perhaps even just
have the setgloblimit() API call and don't even bother with a new flag.
int setgloblimit(int)
Set the maximum number of (bytes? entries?) that will be allocated
to fullfill a globing call. The previous setting is returned. A
value of -1 indicates unlimited. The default is unlimited.
Just having a plain old setgloblimit() call with nothing else (no flags,
etc...) would be the most compatible solution.
Remember when csh had an arbitrarily limit on command line length?
Things like 'foreach i ( `find . -type f` )' would fail arbitrarily.
Tcsh fixed that problem. Whatever we do, we do not want to reintroduce
this same sort of problem in other programs (whether shells do their own
globing or not).
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103180027.f2I0RSn96769>