Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Bruno.Verlyck@inria.fr
To: Xavier.Leroy@inria.fr
Cc: caml-list@inria.fr
Subject: Re: Objective Caml's Unix libraries
Date: Wed, 12 Mar 1997 20:50:09 +0100 (MET)	[thread overview]
Message-ID: <199703121950.UAA13512@kickapoo.inria.fr> (raw)
In-Reply-To: <199703120941.KAA08613@pauillac.inria.fr> (message from Xavier Leroy on Wed, 12 Mar 1997 10:41:17 +0100 (MET))

[ english summary at the end ]
   From: Xavier Leroy <Xavier.Leroy@inria.fr>
   Date: Wed, 12 Mar 1997 10:41:17 +0100 (MET)

   No.  File descriptors are an abstract type in the Unix library, and
   this is a conscious decision.

   > File descriptors are integers indeed.

   That's what C programming lets you believe, but they are not.  It
   does not make sense to add or multiply two file descriptors, for
   instance.
Tout ceci est indiscutable.

   At any rate, the only way to pass file descriptors to an exec'd
   program within the Unix library is to map them using dup2 to stdin,
   stdout or stderr.

   I agree it's an unpleasant constraint, but it's a small price to
   pay for the additional safety brought by having abstract file
   descriptors.

Le problème est que C suinte de partout.  Si je devais implémenter
/bin/sh en Caml, la librairie Unix ne me permettrait pas de traiter la
redirection <&3.  Une fonction fileno : filedesc -> int résoudrait ce
problème (et celui de Pawel.Wojciechowski), mais je ne vois pas
comment traiter >&3 (je n'ai réfléchi que 5 minutes).

Bon, l'interface de /bin/sh est de niveau scandaleusement bas, il y a
(n'en doutons pas) moyen d'en concevoir une meilleure.  Encore faut-il
pouvoir (avoir le droit de) changer les specs...  Et là, on n'a pas
nécessairement le choix du prix à payer.  Ré-écrire une librairie Unix
modifiée ? (il faudrait l'appeler Shell :-)

In english: Xavier's arguments are very strong.  But within them (and
the Unix library), I can't write a /bin/sh clone, because of >&3
(here, and for Pawel.Wojciechowski, it would be enough to add a fun
fileno : filedesc -> int, like the stdio macro) and <&3 -- but I
thought about it for only 5 min.

My point is that you can try to change the specs, but you have to be
allowed to...

Bruno.

Disclaimer: I don't need anything more than the Unix library.




  reply	other threads:[~1997-03-13  9:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-03-11 23:05 Pawel Wojciechowski
1997-03-12  9:41 ` Xavier Leroy
1997-03-12 19:50   ` Bruno.Verlyck [this message]
1997-03-13  9:52     ` Alexandre Frey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199703121950.UAA13512@kickapoo.inria.fr \
    --to=bruno.verlyck@inria.fr \
    --cc=Xavier.Leroy@inria.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox