On 9/7/18 8:59 PM, Eric Blake wrote:
On 09/07/2018 09:44 AM, Eric Blake wrote:
Adding gnulib:
On 09/06/2018 11:37 PM, Barath Aron wrote:
On 9/7/18 4:54 AM, Dale R. Worley wrote:
Couldn't you change the w.d. to the correct target, spawn, and then
change the w.d. back?
Yes, one could do
On 9/7/18 7:19 AM, Bernhard Voelker wrote:
On 09/07/18 06:37, Barath Aron wrote:
Alternatively, one could direct the spawned process to run a program
that would set the working directory to, say, the first argument, and
then use the remaining arguments to run/fork/spawn the target program.
Do
On 9/7/18 4:54 AM, Dale R. Worley wrote:
Couldn't you change the w.d. to the correct target, spawn, and then
change the w.d. back?
Yes, one could do this.
Alternatively, one could direct the spawned process to run a program
that would set the working directory to, say, the first argument, and
Hello again,
I intended to introduce the use of the posix_spawn to the findutils. The
Threos OS ( https://threos.io ), as you might know, does not support
fork, but it has posix_spawn. My plan is the following: I write the code
that implement the process spawning with the posix_spawn, and
On 08/08/2018 03:31 PM, Bernhard Voelker wrote:
ah, right. That's a different motivation, so I changed the commit message
in the attached. Okay to push?
Thanks & have a nice day,
Berny
It is good to go.
Thanks,
Aron
On 08/08/2018 01:11 PM, Bernhard Voelker wrote:
On 08/08/2018 09:39 AM, Aron Barath wrote:
* lib/fdleak.c (get_max_fd): add guard around the fd_limit variable
Thanks for the patch.
I'd favor to give that variable a better scope instead of adding another
#if/#endif block. I'll push the
Hello,
I successfully cross-compiled the findutils 4.6.0 to Threos ( see:
https://threos.io ). Sadly, I had to apply some patches, namely:
additional guard around an unused stack variable (see the submitted
patch), and two fork-related patches (replacing "fork()" with "-1",
because Threos
On 07/18/2018 08:33 AM, Barath Aron wrote:
In order to test things, I'll install a NetBSD and (probably) a
FreeBSD. Despite I have ideas, I want to install these systems before
changing/suggesting anything.
I didn't have enough time to install them, but I looked into the gnulib
itself.
I
On 07/17/2018 09:05 PM, Barath Aron wrote:
Thanks, I'll let you know about my findings.
As a start, I got all the headers from a NetBSD 4.0 with gcc installed.
After looking into those headers, I noticed the following:
a) There is no getfsstat(), but there is getvfsstat(), and its argument
On 07/17/2018 08:49 PM, Paul Eggert wrote:
Barath Aron wrote:
Does gnulib support BSD's getmntinfo()? Since it looks not, what can
we do?
Gnulib ports to the operating systems (including BSD operating
systems) available at the time Gnulib was written, and it still ports
to the current
I don't want to flood the mailing lists, so let me merge Bruno's mail again.
On 07/17/2018 05:49 PM, Paul Eggert wrote:
On 07/16/2018 10:41 PM, Barath Aron wrote:
I guess it is more like a hack than a solution.
Quite true. We need a real solution here, not a hack. But that will
need
Hi,
Thank you all for the answers.
Let me merge Bruno's mail first:
On 07/17/2018 12:02 AM, Bruno Haible wrote:
The configuration of the gnulib 'mountlist' module (used by findutils
and coreutils, among others) is written in such a way that on OpenBSD
it uses the getmntinfo() function
Hello,
Sorry for the self-reply.
I have an additional suggestion for an alternate method:
getdtablesize(2) returns the current limit on the number of open files
per process. This also can be used in get_max_fd function.
Aron
On 07/16/2018 11:24 AM, Barath Aron wrote:
Hello,
I made
Hello,
I made a patch that fixes (at least to me) the declaration of an unused
variable if HAVE_GETRLIMIT is false. The OS I use does not have getrlimit().
Is sysconf(3) mandatory? Because it is not guarded (HAVE_SYSCONF ?). It
is a few lines below where my patch applies.
And a quick
Hello,
I have a little issue around the detection of the getfsstat() function.
According to multiple manuals from different BSD versions [1,2], the
signature of the BSD's getfsstat() is this:
int getfsstat(struct statfs *buf, long bufsize, int mode);
Note, it refers to 'struct statfs'. The
15 matches
Mail list logo
