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
Niklas

PS: I checked how some other programming languages do this:

Python:
    import subprocess; subprocess.call("asdfasdf", shell=False)

    OSError: [Errno 2] No such file or directory

Ruby:
    exec("asdfasdf")

    Errno::ENOENT: No such file or directory - asdfasdf

If you don't want to hack up the whole send-exception-over-the-pipe
thing, the easiest thing to do is to wait for the processes's return
code.  If you don't want to do that, you can at least have the
subproces log, e.g.:

loggedProcess :: Process.CreateProcess -> IO (Maybe IO.Handle,
       Maybe IO.Handle, Maybe IO.Handle, Process.ProcessHandle)
loggedProcess create = do
    r@(_, _, _, pid) <- Process.createProcess create
    Concurrent.forkIO $ do
        code <- Process.waitForProcess pid
        case code of
            Exit.ExitFailure c -> notice $
                "subprocess " ++ show (binaryOf create) ++ " failed: "
                ++ if c == 127 then "binary not found" else show c
            _ -> return ()
    return r
    where
    binaryOf create = case Process.cmdspec create of
        Process.RawCommand fn _ -> fn
        Process.ShellCommand cmd -> fst $ break (==' ') cmd

As an aside, I've had the idea to at some point go look at the latest
python's version of the subprocess module and see about porting it to
haskell, or at least make sure the haskell version doesn't suffer from
problems fixed in the python one.  They went through a lot of
iterations trying to get it right (and earlier python versions are
broken in one way or another) and we might as well build on their
work.

[It's not like the effort the OS is going to do for the stat is going to
be thrown away; whether that call pulls it up off of disk or the one
after the fork that exec will do doesn't matter]

Though speaking of platforms, I guess one large headache would be
what to do about Microsoft operating systems.  Given the unusual
nature of these functions (I mean, what operating-system-independent
command are you going to invoke, anyway?), maybe it would be OK for
the more elaborate support functions to be POSIX / Windows specific.
At the level where people are redirecting the output FD and not the
error FD, etc.

        Donn

POSIX has some new spawn-type calls, btw, but I don't know how widely
implemented they are or how buggy they are.

        Donn

On 13/08/2012, at 11:26 PM, Alexander Kjeldaas wrote:

That warning doesn't seem to be fully up to date.  I'm using MacOS X 10.6.8
and fexecve() isn't in the manuals or in <unistd.h>.

So support is pretty good, I'd say. For non-modern systems, checking the
existence of the file first is possible.  The race isn't important, and one
can always upgrade to a modern operating system.

Niklas

But even given the above, the overhead we're talking about is minuscule.  A
program like '/bin/echo -n '''  which does exactly *nothing*, requires
35(!) system calls to do its job :-).
A more complex program like 'id' requires 250 system calls!

Also, to see just how minuscule this is, the dynamic linker, ld-linux.so
does a few extra access(2) system calls *to the same file*,
/etc/ld.so.hwcaps, on startup of every dynamically linked executable.  2 in
the 'echo' case, and 8 in the 'id' case above.  Even the glibc folks
haven't bothered to optimize those syscalls away.

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.  The appended code is the basic gist of it.
This was not invented by the Python world, but as suggested it's one of
the things that we'd get from a review of their subprocess module.

        Donn

spawn file cmd env = do
  (e0, e1) <- pipe
  fcntlSetFlag e1 F_CLOEXEC
  t <- fork (fex e0 e1)
  close e1
  rx <- readFd e0 256
  if null rx
     then return t
     else ioerr (chrToErrType rx) file
  where
     fex e0 e1 = do
       close e0
       catch  (execve file cmd env)
              (\ e -> writeFd e1 (errToChr e : ioeGetErrorString e))
     ioerr (e, s) file = ioError (mkIOError e s Nothing (Just file))

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: