From owner-svn-src-all@FreeBSD.ORG Wed Jul 16 05:44:11 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4955661A; Wed, 16 Jul 2014 05:44:11 +0000 (UTC) Received: from shxd.cx (unknown [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C3422EBF; Wed, 16 Jul 2014 05:44:11 +0000 (UTC) Received: from [64.201.244.132] (port=50386 helo=THEMADHATTER) by shxd.cx with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X75AU-0004Tb-M6; Tue, 15 Jul 2014 09:01:26 -0700 From: To: "'Jordan Hubbard'" , References: <201407150218.s6F2Itj8044531@svn.freebsd.org> <53C56BE9.9050304@FreeBSD.org> <20140715191553.GA31990@dft-labs.eu> <011a01cfa09b$928b4710$b7a1d530$@FreeBSD.org> <013701cfa09f$3ffad0c0$bff07240$@FreeBSD.org> <6DD1779E-01EE-46ED-894A-21134279AF6F@me.com> In-Reply-To: <6DD1779E-01EE-46ED-894A-21134279AF6F@me.com> Subject: RE: svn commit: r268641 - head/usr.sbin/service Date: Tue, 15 Jul 2014 22:43:58 -0700 Message-ID: <01af01cfa0b8$f07aa5b0$d16ff110$@FreeBSD.org> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHOLaehGAwRwf+WS/ay3he7mLcSrwIdqyYRAXy+1UkB4SBdqgG6S7aCAOPm/sABtG/VFZtWo1nw Content-Language: en-us Sender: devin@shxd.cx Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: 'Benjamin Kaduk' , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, 'Bryan Drewery' X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 05:44:11 -0000 From: Jordan Hubbard [mailto:jordanhubbard@me.com] Sent: Tuesday, July 15, 2014 9:42 PM To: dteske@freebsd.org Cc: Benjamin Kaduk; Bryan Drewery; svn-src-head@freebsd.org; svn-src-all@freebsd.org; src-committers@freebsd.org Subject: Re: svn commit: r268641 - head/usr.sbin/service On Jul 15, 2014, at 7:40 PM, dteske@freebsd.org wrote: I define non-UNIXy as chicanery that makes working in a POSIX environment more difficult POSIX does not define or mandate any specific set of environment variables. OS X is POSIX and UNIX03 compliant (and qualified to use the Unix trademark, unlike FreeBSD), and I've already described its behavior with respect to environment variables. Be careful how you sling terms like POSIX or UnixT around. ;-) [Devin Teske] (smiles) Will do. However I'm re-reading my statement and holding to the meaning I've interred it: Windows has POSIX compliance Mac OS X has POSIX compliance So does Linux, as does FreeBSD If working in one of these POSIX environments (note: the Windows POSIX environment I use is MinGW) compiling C code, using standard POSIX APIs, etc. I view the overall environment as being non-UNIXy if that POSIX environment is not properly integrated. Now, my statement's standpoint is that if my POSIX system has the API calls to inter the terminal type I'm being run within, is the overall system outside ignoring this POSIX-made-available information? So example would be Windows as being non-UNIXy (this I believe we agree upon). Non-UNIXy because while I can load the MinGW or SFU or Cygwin layers to access POSIX-compliant APIs, Windows itself could care less about that layer. It's not integrated. Skipping Mac OS X, looking at FreeBSD, my statement was designed to encapsulate that we actively seek to maintain great compliance with POSIX and also (maybe this is the leap; but I would think) try to make sure we integrate that information as often as possible. (and thus, not force someone to build a layer on-top of the boot process to re-access the data that should perhaps already be made available -- e.g., $TERM to know what we're running within). -- Devin