From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2921 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: question: hard-coded file descriptors in stdin/stdout/stderr Date: Fri, 15 Mar 2013 14:43:00 -0400 Message-ID: <20130315184300.GI20323@brightrain.aerifal.cx> References: <5141F86D.8010000@eservices.virginia.edu> <20130314171752.GB19010@port70.net> <51420E17.9030305@eservices.virginia.edu> <20130315083357.GH20323@brightrain.aerifal.cx> <5143345E.4080209@eservices.virginia.edu> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1363372990 2690 80.91.229.3 (15 Mar 2013 18:43:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Mar 2013 18:43:10 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2922-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 15 19:43:36 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UGZbM-0004TK-0D for gllmg-musl@plane.gmane.org; Fri, 15 Mar 2013 19:43:36 +0100 Original-Received: (qmail 22525 invoked by uid 550); 15 Mar 2013 18:43:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22514 invoked from network); 15 Mar 2013 18:43:12 -0000 Content-Disposition: inline In-Reply-To: <5143345E.4080209@eservices.virginia.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2921 Archived-At: On Fri, Mar 15, 2013 at 10:46:54AM -0400, Zvi Gilboa wrote: > >> [Rich wrote:] Not only are the numbers 0/1/2 specified and widely > hard-coded in applications; > > >> [LM wrote:] I've been trying to port msh to Windows and it uses > hard-coded 0, 1 and 2 with pipes and expects them to mean stdin, > stdout and stderr. > > Thank you for this valuable input! Clearly, remapping 0/1/2 from > within psxcalls would be the only responsible approach:) Note that even if the shell doesn't hard-code them, every single non-trivial shell script ever written hard-codes them. I think this was the motivation for POSIX requiring that they have the specific values 0/1/2. > That kind of "translation" is an essential part of the psxcalls > project. Surprisingly (or not), the vast majority of differences > between the Native API and POSIX are about syntax, not > functionality. In other words, there exist only very few POSIX > features that cannot be implemented using the Native API in a > straight-forward way. There are for sure some cases that require That's nice to hear. I suspect there are a lot more subtleties like different error conditions and corner cases, which probably need consideration on a case-by-case basis whether it's important to match the POSIX behavior (or whether it's even possible to match it exactly). Still, I think most such problems are things that can be solved incrementally, and shouldn't stall the project. > programming acrobatics (fork() and exec()) being the most obvious > examples), but that's the exception, not the rule. Whenever I > implement one of the functions, I try to phrase the task in the form > of a question, for instance: "using the Native API, how would you > map a memory page to the address space of a user applications?" > That kind of approach to writing the library surely entails a lot of > work, but is also very exciting -- like solving a puzzle every > single day... Keep up the good spirits -- I'm glad to see this finally happening. My hope for the past 7+ years has been that we could get to a point where software (or at least FOSS) could be written with a portable core targetting POSIX rather than having windows-specific hacks all over the core to deal with the badness of msvcrt, or bloated "portable runtime" libraries that layer abstractions on top of the standardized abstractions. Rich