svn commit: r268641 - head/usr.sbin/service

[dteske at FreeBSD.org]

From: Jordan Hubbard [mailto:jordanhubbard at me.com] 
Sent: Tuesday, July 15, 2014 9:42 PM
To: dteske at freebsd.org
Cc: Benjamin Kaduk; Bryan Drewery; svn-src-head at freebsd.org;
svn-src-all at freebsd.org; src-committers at freebsd.org
Subject: Re: svn commit: r268641 - head/usr.sbin/service

 

 

On Jul 15, 2014, at 7:40 PM, dteske at freebsd.org <mailto:dteske at 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