Well, overhead or not, it would be nice to at least have *some* solution.
Currently, it just doesn't work.
I am sure that as soon the functionality is there, somebody will step in
to fake it fast.
On 15/08/12 06:25, Donn Cave wrote:
> Quoth Alexander Kjeldaas ,
>
>> See access(2)
>
> ... a cla
Quoth Alexander Kjeldaas ,
> See access(2)
... a classic "code smell" in UNIX programming, for the same reasons.
We can solve this problem in an efficient way that works well, and equally
well, on any POSIX platform that supports F_CLOEXEC on pipes, and I can't
think of anything that doesn't. T
On 14 August 2012 17:22, Niklas Larsson wrote:
> 2012/8/14 Alexander Kjeldaas :
> >
> >
> > On 13 August 2012 23:49, Richard O'Keefe wrote:
> >>
> >>
> >> On 13/08/2012, at 11:26 PM, Alexander Kjeldaas wrote:
> >>
> >> >
> >> > This isn't that hard - a pipe shouldn't be needed anymore. Just
> r
2012/8/14 Alexander Kjeldaas :
>
>
> On 13 August 2012 23:49, Richard O'Keefe wrote:
>>
>>
>> On 13/08/2012, at 11:26 PM, Alexander Kjeldaas wrote:
>>
>> >
>> > This isn't that hard - a pipe shouldn't be needed anymore. Just require
>> > a post-2003 glibc.
>> >
>> > fexecve is a system call in mo
On 13 August 2012 23:49, Richard O'Keefe wrote:
>
> On 13/08/2012, at 11:26 PM, Alexander Kjeldaas wrote:
>
> >
> > This isn't that hard - a pipe shouldn't be needed anymore. Just require
> a post-2003 glibc.
> >
> > fexecve is a system call in most BSDs. It is also implemented in glibc
> using
On 13/08/2012, at 11:26 PM, Alexander Kjeldaas wrote:
>
> This isn't that hard - a pipe shouldn't be needed anymore. Just require a
> post-2003 glibc.
>
> fexecve is a system call in most BSDs. It is also implemented in glibc using
> a /proc hack.
fexecve is now in the Single Unix Specific
Quoth Brandon Allbery ,
> On Mon, Aug 13, 2012 at 10:23 AM, Donn Cave wrote:
>
>> Though speaking of platforms, I guess one large headache would be
>> what to do about Microsoft operating systems. Given the unusual
>>
>
> Microsoft provides APIs that work as is for this, by my understanding; it's
On Mon, Aug 13, 2012 at 10:23 AM, Donn Cave wrote:
> Though speaking of platforms, I guess one large headache would be
> what to do about Microsoft operating systems. Given the unusual
>
Microsoft provides APIs that work as is for this, by my understanding; it's
the POSIX fork/exec model that m
On Mon, Aug 13, 2012 at 7:26 AM, Alexander Kjeldaas <
alexander.kjeld...@gmail.com> wrote:
> This isn't that hard - a pipe shouldn't be needed anymore. Just require a
> post-2003 glibc.
>
So, we are desupporting the *BSDs and OS X (and Solaris etc.) now? glibc
is only used on Linux and the Hurd
Quoth Evan Laforge ,
...
> ... or at least make sure the haskell version doesn't suffer from
> problems fixed in the python one.
Exactly. This morning I'm reading suggested solutions that would
work only some of the time, or on only some platforms, which wouldn't
be satisfactory in the long run.
This isn't that hard - a pipe shouldn't be needed anymore. Just require a
post-2003 glibc.
fexecve is a system call in most BSDs. It is also implemented in glibc
using a /proc hack.
http://www.kernel.org/doc/man-pages/online/pages/man3/fexecve.3.html
Apparently, there are proposals/RFCs to get
In Unix, at least, "check, then act" is generally considered unwise:
1. Something can go wrong between checking and acting.
2. You might not be checking the right thing(s). In this case, the fact
that the file exists is not useful if you don't have permission to execute
it. You may not be able to
On Sun, 2012-08-12 at 23:18 -0700, Evan Laforge wrote:
> Yes, I ran into the same thing a while back. The problem is that the
> subprocess has already been forked off before it runs exec() and finds
> out the file doesn't exist.
Given how astonishingly common it is to pass an invalid executable n
On Sun, Aug 12, 2012 at 6:18 PM, Niklas Hambüchen wrote:
> I just came across the fact that running
>
> createProcess (proc "asdfasdf" [])
>
> with non-existing command "asdfasdf" returns perfectly fine handles.
> I would expect an exception.
> You can even hGetContents on stdout: You just get
I just came across the fact that running
createProcess (proc "asdfasdf" [])
with non-existing command "asdfasdf" returns perfectly fine handles.
I would expect an exception.
You can even hGetContents on stdout: You just get "".
I find this highly counter-intuitive. Is this intended?
Thanks
15 matches
Mail list logo
