From spedraja at gmail.com  Thu Feb 23 18:18:49 2012
From: spedraja at gmail.com (Sergio Pedraja)
Date: Thu, 23 Feb 2012 08:18:49 +0000 (UTC)
Subject: [Unix-jun72] =?utf-8?q?Invitaci=C3=B3n_a_conectarnos_en_LinkedIn?=
Message-ID: <844019596.21368193.1329985129946.JavaMail.app@ela4-bed81.prod>

LinkedIn
------------



Me gustaría añadirte a mi red profesional en LinkedIn.
 
-Sergio

Sergio Pedraja
IT Security Administrator / Information Security Manager en Savings Bank
Santander y alrededores, España

Confirma que conoces a Sergio Pedraja:
https://www.linkedin.com/e/-p9hg1j-gyzit23b-16/isd/6035310103/YCHqBtRa/?hs=false&tok=2G1F-50oSieR81

--
Estás recibiendo invitaciones a conectar. Haz clic para darte de baja:
http://www.linkedin.com/e/-p9hg1j-gyzit23b-16/pQvcBySBaffs0LLhMMtx8DQb3x_CTMm/goo/unix-jun72%40tuhs%2Eorg/20061/I2097818457_1/?hs=false&tok=1I03vjIjSieR81

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, EE.UU.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120223/c20e668b/attachment.html>

From spedraja at gmail.com  Thu Feb 23 18:36:06 2012
From: spedraja at gmail.com (SPC)
Date: Thu, 23 Feb 2012 09:36:06 +0100
Subject: [Unix-jun72]
	=?iso-8859-1?q?Invitaci=F3n_a_conectarnos_en_LinkedI?=
	=?iso-8859-1?q?n?=
In-Reply-To: <844019596.21368193.1329985129946.JavaMail.app@ela4-bed81.prod>
References: <844019596.21368193.1329985129946.JavaMail.app@ela4-bed81.prod>
Message-ID: <CACytpF-QVudY8MB8BqVH6xGubT5U=ds+8t_admJAreqmqrgv=A@mail.gmail.com>

*Very* sorry for the mistake.

Sergio.

El 23 de febrero de 2012 09:18, Sergio Pedraja <spedraja at gmail.com>escribió:

>
>  [image: LinkedIn]
>
>
>
>   [image: Sergio Pedraja]
>
>  *De Sergio Pedraja*
>
> IT Security Administrator / Information Security Manager en Savings Bank
> Santander y alrededores, España
>
>
>
>
> Me gustaría añadirte a mi red profesional en LinkedIn.
>
> -Sergio
>
>
>
>  Confirma que conoces a Sergio<https://www.linkedin.com/e/-p9hg1j-gyzit23b-16/isd/6035310103/YCHqBtRa/?hs=false&tok=2G1F-50oSieR81>
>
>
>
>   Estás recibiendo invitaciones a conectar. Date de baja<http://www.linkedin.com/e/-p9hg1j-gyzit23b-16/pQvcBySBaffs0LLhMMtx8DQb3x_CTMm/goo/unix-jun72%40tuhs%2Eorg/20061/I2097818457_1/?hs=false&tok=1I03vjIjSieR81>
> © 2012, LinkedIn Corporation. 2029 Stierlin Ct., Mountain View, CA 94043
> EE.UU.
>
>
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>
>


-- 
Gracias.
-- 
Saludos - Greetings - Freundliche Grüße - Salutations

Sergio Pedraja
 <http://www.linkedin.com/in/sergiopedraja>
twitter: @sergio_pedraja
http://plus.google.com/u/0/101292256663392735405
http://www.linkedin.com/in/sergiopedraja
http://www.quora.com/Sergio-Pedraja
https://www.xing.com/profile/Sergio_Pedraja
http://www.viadeo.com
http://www.avalonred.com/
-----
No crea todo lo que ve, ni crea que está viéndolo todo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120223/ade2df89/attachment.html>

From lm at bitmover.com  Wed Feb  1 01:49:50 2012
From: lm at bitmover.com (Larry McVoy)
Date: Tue, 31 Jan 2012 07:49:50 -0800
Subject: [TUHS] History of man pages
In-Reply-To: <34F8DEFE-9667-4915-9A3F-703EE78C07E1@ronnatalie.com>
References: <20120131013631.GB45125@dereel.lemis.com>
	<20120131015335.GA31880@minnie.tuhs.org>
	<34F8DEFE-9667-4915-9A3F-703EE78C07E1@ronnatalie.com>
Message-ID: <20120131154950.GZ17183@bitmover.com>

I still use it, BitMover's MLA (signed by the likes of Intel, Cisco,
IBM, HP, etc) is maintained in troff.  And one of those companies,
not to be named, shoved it into word (in fact they all did that part),
turned on track changes, made some typo like fixes, turned off track
changes, and changed some major stuff.  I took the word doc, extracted
to text, ran it through my formatter and diffed 'em and found the
unwanted changes.  Said company proceeded to be shocked!  shocked!
shocked, I tell you!  Shocked!  that this had happened and it must
have been a huge mistake!

Go roff.  Or go diff.  Or something :)

On Tue, Jan 31, 2012 at 08:04:09AM -0500, Ronald Natalie wrote:
> Gosh, I'd forgotten about that.    "Roff is the simplest of the text formatting programs but is utterly frozen."
> They finally dragged me off troff in the mid-90's.
> 
> 
> On Jan 30, 2012, at 8:53 PM, Warren Toomey wrote:
> 
> > On Tue, Jan 31, 2012 at 12:36:31PM +1100, Greg 'groggy' Lehey wrote:
> >> I've received a link http://manpages.bsd.lv/history.html claiming to
> >> be about man pages; in fact, it's a lot more than that, including the
> >> prehistory of troff.  Interesting stuff.
> >> 
> >> Greg
> > 
> > Thanks Greg, yes a good read. Pity we've lost the PDP-11 asm
> > version of roff from 1st/2nd Edition Unix.
> > 	Warren
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com


From a.phillip.garcia at gmail.com  Wed Feb  1 05:16:17 2012
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Tue, 31 Jan 2012 13:16:17 -0600
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
Message-ID: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>

http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120131/7b847bfb/attachment.html>

From imp at bsdimp.com  Wed Feb  1 05:27:15 2012
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 31 Jan 2012 12:27:15 -0700
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
Message-ID: <165D3734-0D92-43B9-9D71-62690AB7BB5E@bsdimp.com>

Well, except for the part that it stopped making sense before Linux was invented...  the split also allows minimal ram disk images to load the rest of the OS and mount the full system remotely...  These were still useful after 1990 when Linux was first released.  It wasn't until around 1995 or so that disks were big/cheap enough for it to not matter...

Warner

On Jan 31, 2012, at 12:16 PM, A. P. Garcia wrote:

> http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120131/ecc6c47a/attachment.html>

From a.phillip.garcia at gmail.com  Wed Feb  1 05:39:18 2012
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Tue, 31 Jan 2012 13:39:18 -0600
Subject: [TUHS] xv6
Message-ID: <CAFCBnZvGVMY3gsDymXzv+61nDn=bD6iYhvp3w4KF0wX4rOm5Xg@mail.gmail.com>

saw this on osnews under 'related articles'; it's a rewrite of sixth
edition for x86:

http://pdos.csail.mit.edu/6.828/2011/xv6.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120131/9ff55ef6/attachment.html>

From arnold at skeeve.com  Wed Feb  1 19:26:39 2012
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 1 Feb 2012 01:26:39 -0800
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
Message-ID: <201202010926.q119QdMm007019@freefriends.org>

> http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

Cute, but most of the history is wrong.

The distinction between /bin and /usr/bin is true - / held the things
need to boot the system. Other things were on /usr.

The Berkeley guys did NOT invent shared libraries.  Shared libraries as
we know them came originally from Sun, on SunOS 4.x for sure, possibly
on SunOS 3.x. (Larry?)  Many commercial vendors adopted the design (Ultrix,
I think, and maybe others) and finally around 4.4 they found their way into
"pure" BSD.

/home and /opt came into the picture circa 1989 with SVR4 when Berkeley,
AT&T and Sun (and maybe a few others?) got together to standardize the
layout and make diskless booting possbile and reasonable with NFS sharing
of home directories. /sbin & /usr/sbin came into the picture at this
point also, to hold executables that until then had lived in /etc. The
idea was that /etc should only have per-machine configuration files.

The general point of the article and of some of the postings, that the
proliferation doesn't make a lot of sense today, is well taken. The
Bell Labs guys themselves recognized this when they did Plan 9.

The problem is even worse on 64 bit Linux systems, which can handle
two different architectures. /lib and /lib64 confuse a lot of the
older 'configure' programs.

Personally, I hate reading articles by "experts" where 85% of the facts
are wrong.  I lived through all of it, and I know better... :-)

Arnold


From jrvalverde at cnb.csic.es  Wed Feb  1 21:12:14 2012
From: jrvalverde at cnb.csic.es (Jose R. Valverde)
Date: Wed, 1 Feb 2012 12:12:14 +0100
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
Message-ID: <20120201121214.55c73577@cnb.csic.es>

On Tue, 31 Jan 2012 13:16:17 -0600
"A. P. Garcia" <a.phillip.garcia at gmail.com> wrote:
> http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

I think this is typical misunderstanding of modern-day newcomers. The main 
problem to me seems to be that they think of UNIX (and Linux) as a Windows
PC, which it isn't (and they even do not understand the Windows PC itself).

The fact that at some point people was strained by disk space (and it has
nothing to do with Ken or Dennis or disk availability) only means they had 
a pressure to split contents, and unless anyone was a moron, everyone would 
do it in a similar rational way.

A rational way in the times meant adapting for the times' needs, and by
then UNIX was a multi-user OS.

So, beyond the point of filling up a disk (and that's the point for the partition
system) there was a need to ensure you could separate user data from system data:
adding user programs or data to a separate space (disk, partition, whatever)
ensured the system space was not filled and the system would not become unusable.

That was the real reason for /, /usr, /tmp and /var as standard partitions for
most of us, not the availability of new disks. And the same is valid for 
separating system-specific binaries from general users.

When disks came it would be handy to move a partition to a separate disk,
but the need itself has nothing to do with the availability of extra disks.

This is something obvious to anyone maintaining a multi-user server, only
presumptuous single-user windows toyers think they know better. Even now
when I get a user asking to set up a new computing server, their first
query is how to separate system from users and scratch space. Any power
user has filled his own system once and knows the risk. They also know they
can cope with their own system and files. And they all know they cannot in
a shared environment where they cannot control other users' files. Point
is, the very first idea that occurs to any sensible being when facing a
multiuser system is how to separate contents safely.

That Ken and Denis did the obvious thing (as many of us did at the time --I
remember having a /usr/local on my machines years before it was commonplace 
use) only speaks of their common sense (and the ignorance or lack of common 
sense in complainers).

This is still valid in the times of petabyte disk arrays, ACLs, quotas,
queuing systems and all what nots. Even more so in these large installations
(I have witnessed multi-TB scratch files in jobs, filling a supercomputing
installation and requiring operator intervention to avoid stopping the work
of all other users).

And so on, I could rant all day arguing why this was the obvious approach
to many problems then, and often now too.

So, to me, this looks more like a case of "reintrepreting and twisting the
facts to justify untenable beliefs" instead of trying to understand what 
actually happened and why. Like saying the wheel was invented only to make 
carriages and that we keep using carriages (instead of say helicopters) just 
because of tradition and "bureaucrats" instead of accepting that there were 
many needs and when the wheel came it was -and still is- the obvious solution 
to most of those problems (among them carrying loads in carriages).

				j
-- 
			EMBnet/CNB
		Scientific Computing Service
	Solving all your computer needs for Scientific
			Research.

		http://bioportal.cnb.csic.es
		  http://www.es.embnet.org


From imp at BSDIMP.COM  Thu Feb  2 03:35:53 2012
From: imp at BSDIMP.COM (Warner Losh)
Date: Wed, 1 Feb 2012 10:35:53 -0700
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <20120201121214.55c73577@cnb.csic.es>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
Message-ID: <9BAA3D8D-6B2C-4EDD-A413-5079E63D6E86@bsdimp.com>




On Feb 1, 2012, at 4:12 AM, Jose R. Valverde wrote:
> So, beyond the point of filling up a disk (and that's the point for the partition
> system) there was a need to ensure you could separate user data from system data:
> adding user programs or data to a separate space (disk, partition, whatever)
> ensured the system space was not filled and the system would not become unusable.

You had different quotas on different partitions as well...  Something most folks don't get these days: you used to get 5MB from the CS department and be grateful they gave you that much...

There were bugs in the dim, dark past too where if you filled up /, the system would crash.  Having a separate / insulated you from that.

Also, fsck and file systems were a little more fragile in the early days than now, so you wanted to make sure that you minimized the amount of data needed to change before / could be mounted rw.  This boot-strapping process these days (on linux) happens in a ram disk, but historically (and still in many BSDs) happens on the actual drive, so any corruption or filesystem issue would take a while to repair, and once repaired you had to reboot to ensure that the pages that were swapped in read-only that might have been changed behind the scenes by fsck were properly flushed.

None of that was mentioned in the article :)

Warner



From random832 at fastmail.us  Thu Feb  2 23:32:45 2012
From: random832 at fastmail.us (Random832)
Date: Thu, 02 Feb 2012 08:32:45 -0500
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <20120201121214.55c73577@cnb.csic.es>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
Message-ID: <4F2A907D.9000000@fastmail.us>

On 2/1/2012 6:12 AM, Jose R. Valverde wrote:
> So, beyond the point of filling up a disk (and that's the point for the partition
> system) there was a need to ensure you could separate user data from system data:
> adding user programs or data to a separate space (disk, partition, whatever)
> ensured the system space was not filled and the system would not become unusable.

The thing is, /usr isn't "user data". That's /home. /usr is just "more 
system space".

And this article never actually explains sbin. Or /usr/share, which is 
interesting because as I understand it it's designed to be shareable 
between multiple computers of possibly different architectures


From tfb at tfeb.org  Thu Feb  2 23:35:58 2012
From: tfb at tfeb.org (Tim Bradshaw)
Date: Thu, 2 Feb 2012 13:35:58 +0000
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <201202010926.q119QdMm007019@freefriends.org>
References: <201202010926.q119QdMm007019@freefriends.org>
Message-ID: <D8A41C46-2690-4C3E-8EF3-0B6DCB0FB81C@tfeb.org>

On 1 Feb 2012, at 09:26, arnold at skeeve.com wrote:

> The Berkeley guys did NOT invent shared libraries.  Shared libraries as
> we know them came originally from Sun, on SunOS 4.x for sure, possibly
> on SunOS 3.x. (Larry?)  Many commercial vendors adopted the design (Ultrix,
> I think, and maybe others) and finally around 4.4 they found their way into
> "pure" BSD.

4.  3 may have had them but not in any version we had, so I'd guess not in a major release, anyway.

From tfb at tfeb.org  Thu Feb  2 23:45:25 2012
From: tfb at tfeb.org (Tim Bradshaw)
Date: Thu, 2 Feb 2012 13:45:25 +0000
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <20120201121214.55c73577@cnb.csic.es>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
Message-ID: <8E4D7C90-58E1-4860-BBEB-040A5C765DBE@tfeb.org>

On 1 Feb 2012, at 11:12, Jose R. Valverde wrote:

> This is something obvious to anyone maintaining a multi-user server, only
> presumptuous single-user windows toyers think they know better.

If only this were true.  Until reasonably recently (may be a couple of years ago was the last time I cared), a major Unix vendor's recommendation was not to have separate /var, because that was "old fashioned" (I assume).  Some of their installation / upgrade programs would fail if you did in fact.  For additional amusement, the default install would put no limit on the size of the memory-based /tmp filesystem.  So basically anything on the system could fill / with all the undesirable consequences that has, and also eat the system's memory in an unpleasantly persistent way.

--tim

From lm at bitmover.com  Thu Feb  2 23:49:20 2012
From: lm at bitmover.com (Larry McVoy)
Date: Thu, 2 Feb 2012 05:49:20 -0800
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <D8A41C46-2690-4C3E-8EF3-0B6DCB0FB81C@tfeb.org>
References: <201202010926.q119QdMm007019@freefriends.org>
	<D8A41C46-2690-4C3E-8EF3-0B6DCB0FB81C@tfeb.org>
Message-ID: <20120202134920.GT6205@bitmover.com>

On Thu, Feb 02, 2012 at 01:35:58PM +0000, Tim Bradshaw wrote:
> On 1 Feb 2012, at 09:26, arnold at skeeve.com wrote:
> 
> > The Berkeley guys did NOT invent shared libraries.  Shared libraries as
> > we know them came originally from Sun, on SunOS 4.x for sure, possibly
> > on SunOS 3.x. (Larry?)  Many commercial vendors adopted the design (Ultrix,
> > I think, and maybe others) and finally around 4.4 they found their way into
> > "pure" BSD.
> 
> 4.  3 may have had them but not in any version we had, so I'd guess not in a major release, anyway.

I got there when SunOS 4.1 was being worked on and they were definitely in
4.0.  4.0 gave you shared libs, vnodes, mmap, there was a lot of good stuff
in there.  It actually worked by 4.1.1 which was probably my favorite SunOS
release.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com


From imp at bsdimp.com  Fri Feb  3 03:24:26 2012
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 2 Feb 2012 10:24:26 -0700
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <4F2A907D.9000000@fastmail.us>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
Message-ID: <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>


On Feb 2, 2012, at 6:32 AM, Random832 wrote:

> On 2/1/2012 6:12 AM, Jose R. Valverde wrote:
>> So, beyond the point of filling up a disk (and that's the point for the partition
>> system) there was a need to ensure you could separate user data from system data:
>> adding user programs or data to a separate space (disk, partition, whatever)
>> ensured the system space was not filled and the system would not become unusable.
> 
> The thing is, /usr isn't "user data". That's /home. /usr is just "more system space".

/usr was user data, back in the day.  /home came about much later.

> And this article never actually explains sbin. Or /usr/share, which is interesting because as I understand it it's designed to be shareable between multiple computers of possibly different architectures

sbin was created in SYS Vr4 to move all the binaries that were in /etc.  /usr/share was created to move all the non-binary, non-text files that were in /etc like termcap and timezone info.

Warner





From imp at bsdimp.com  Fri Feb  3 03:40:01 2012
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 2 Feb 2012 10:40:01 -0700
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
Message-ID: <78400D2A-74E6-434D-B168-4D1C1EDB8326@bsdimp.com>


On Feb 2, 2012, at 10:24 AM, Warner Losh wrote:

> 
> On Feb 2, 2012, at 6:32 AM, Random832 wrote:
> 
>> On 2/1/2012 6:12 AM, Jose R. Valverde wrote:
>>> So, beyond the point of filling up a disk (and that's the point for the partition
>>> system) there was a need to ensure you could separate user data from system data:
>>> adding user programs or data to a separate space (disk, partition, whatever)
>>> ensured the system space was not filled and the system would not become unusable.
>> 
>> The thing is, /usr isn't "user data". That's /home. /usr is just "more system space".
> 
> /usr was user data, back in the day.  /home came about much later.
> 
>> And this article never actually explains sbin. Or /usr/share, which is interesting because as I understand it it's designed to be shareable between multiple computers of possibly different architectures
> 
> sbin was created in SYS Vr4 to move all the binaries that were in /etc.  /usr/share was created to move all the non-binary, non-text files that were in /etc like termcap and timezone info.

That should read 'all non-binary executables and non-config files'

Warner

From cowan at mercury.ccil.org  Fri Feb  3 03:36:24 2012
From: cowan at mercury.ccil.org (John Cowan)
Date: Thu, 2 Feb 2012 12:36:24 -0500
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
Message-ID: <20120202173623.GQ30634@mercury.ccil.org>

Warner Losh scripsit:

> sbin was created in SYS Vr4 to move all the binaries that were in /etc.
> /usr/share was created to move all the non-binary, non-text files that
> were in /etc like termcap and timezone info.

Does anyone know what the "s" in sbin stands for?  "Superuser"?  I would
have put these files in /root/bin, but perhaps /root did not yet exist.

Not everything in /usr/share comes from /etc; in particular, /usr/share/dict
was formerly /usr/dict.

-- 
Go, and never darken my towels again!           John Cowan
        --Rufus T. Firefly                      http://ccil.org/~cowan


From tim.newsham at gmail.com  Fri Feb  3 04:02:41 2012
From: tim.newsham at gmail.com (Tim Newsham)
Date: Thu, 2 Feb 2012 08:02:41 -1000
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <4F2A907D.9000000@fastmail.us>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
Message-ID: <CAGSRWbi_OR1LUDMugsumtKUuFgJK0W-Q6F9oT6kf7F1ATO3Rwg@mail.gmail.com>

> The thing is, /usr isn't "user data". That's /home. /usr is just "more
> system space".

Thats exactly what /usr is supposed to be.  user data.
ie. /usr/ken, /usr/dmr.

-- 
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com


From imp at bsdimp.com  Fri Feb  3 04:10:17 2012
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 2 Feb 2012 11:10:17 -0700
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <20120202173623.GQ30634@mercury.ccil.org>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
Message-ID: <FED51EC2-ECBD-457C-ABC8-1DC3468F23DE@bsdimp.com>


On Feb 2, 2012, at 10:36 AM, John Cowan wrote:

> Warner Losh scripsit:
> 
>> sbin was created in SYS Vr4 to move all the binaries that were in /etc.
>> /usr/share was created to move all the non-binary, non-text files that
>> were in /etc like termcap and timezone info.
> 
> Does anyone know what the "s" in sbin stands for?  "Superuser"?  I would
> have put these files in /root/bin, but perhaps /root did not yet exist.

I'd been told a long time ago that  is stands for 'system' for people that need to administer the system, not necessarily super users.  The FreeBSD hier man page seems to bear this out:

     /sbin/     system programs and administration utilities fundamental to
                both single-user and multi-user environments

> Not everything in /usr/share comes from /etc; in particular, /usr/share/dict
> was formerly /usr/dict.

That's true, but /usr/dict was a bit of an odd-ball at the top /usr level.  /usr/share contained all the stuff from /etc and also other things that didn't seem to belong.  That's why it is documented as having the architecture independent files in it...

Warner



From dave at horsfall.org  Fri Feb  3 07:14:56 2012
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 3 Feb 2012 08:14:56 +1100 (EST)
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <20120202173623.GQ30634@mercury.ccil.org>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
Message-ID: <alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>

On Thu, 2 Feb 2012, John Cowan wrote:

> Does anyone know what the "s" in sbin stands for?  "Superuser"?  I would 
> have put these files in /root/bin, but perhaps /root did not yet exist.

I seem to recall that they were statically linked i.e. not using those 
new-fangled shared library thingies.  And if you've ever tried to admin a 
system with a trashed shared library, you'll understand; it usually 
involves looking for the installation media.

> Not everything in /usr/share comes from /etc; in particular, 
> /usr/share/dict was formerly /usr/dict.

As I dimly recall, /usr/share was exported, hence the name.

-- Dave


From imp at bsdimp.com  Fri Feb  3 07:49:44 2012
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 2 Feb 2012 14:49:44 -0700
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
	<alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>
Message-ID: <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>


On Feb 2, 2012, at 2:14 PM, Dave Horsfall wrote:

> On Thu, 2 Feb 2012, John Cowan wrote:
> 
>> Does anyone know what the "s" in sbin stands for?  "Superuser"?  I would 
>> have put these files in /root/bin, but perhaps /root did not yet exist.
> 
> I seem to recall that they were statically linked i.e. not using those 
> new-fangled shared library thingies.  And if you've ever tried to admin a 
> system with a trashed shared library, you'll understand; it usually 
> involves looking for the installation media.

/bin is also statically linked, at least on those distributions that support split / and /usr.  SunOS 4.x and 4.4BSD did this. Except for the ones that have gone to a dynamic root moving the shared libraries from /usr/lib to /lib.  Prior to the /etc -> /sbin moves, all binaries were statically linked.  Even after the move /bin and /sbin remained static, while /usr/bin and /usr/sbin were dynamic.  The needs of reliability vs space savings pushed all the binaries in /sbin and  /bin to be static.

Even after the split in more modern systems, init and sh tend to be the only binaries that are statically linked anymore.  Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used).

Warner

>> Not everything in /usr/share comes from /etc; in particular, 
>> /usr/share/dict was formerly /usr/dict.
> 
> As I dimly recall, /usr/share was exported, hence the name.
> 
> -- Dave
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> 



From tim.newsham at gmail.com  Fri Feb  3 08:29:04 2012
From: tim.newsham at gmail.com (Tim Newsham)
Date: Thu, 2 Feb 2012 12:29:04 -1000
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
	<alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>
	<52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>
Message-ID: <CAGSRWbiJesxtoC38_FEZM7_jMa3cvx=SUjT+nUoGd5irxr_ajg@mail.gmail.com>

>   Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used).

you're kidding, right?  Disk space of binaries?
(I still wish "du" had a "-$" flag that pulled info from a recent price
database).

> Warner

-- 
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com


From imp at bsdimp.com  Fri Feb  3 08:47:24 2012
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 2 Feb 2012 15:47:24 -0700
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <CAGSRWbiJesxtoC38_FEZM7_jMa3cvx=SUjT+nUoGd5irxr_ajg@mail.gmail.com>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
	<alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>
	<52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>
	<CAGSRWbiJesxtoC38_FEZM7_jMa3cvx=SUjT+nUoGd5irxr_ajg@mail.gmail.com>
Message-ID: <E5C6A964-1931-4EB9-9B62-303309FDDAA6@bsdimp.com>


On Feb 2, 2012, at 3:29 PM, Tim Newsham wrote:

>>  Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used).
> 
> you're kidding, right?  Disk space of binaries?
> (I still wish "du" had a "-$" flag that pulled info from a recent price
> database).

No.  I'm not kidding.

Remember that these systems exist in more places than on monster-sized hard-disks.  Embedded systems had limits of 4MB, 8MB or 16MB when these patches were done.  While NAND has grown so that 64MB or 256MB parts are more common on boards, the savings is still rather substantial and allow for additional functionality.  The space savings rivals 'crunchgened' binaries (think busybox).  Savings between 32MB and 64MB is only a few $$$, but if you ship a million of something, the savings can be substantial.

In addition, having everything link in shared libraries makes doing security updates much easier.

Warner



From lyndon at orthanc.ca  Fri Feb  3 08:59:25 2012
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 2 Feb 2012 14:59:25 -0800
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <E5C6A964-1931-4EB9-9B62-303309FDDAA6@bsdimp.com>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
	<alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>
	<52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>
	<CAGSRWbiJesxtoC38_FEZM7_jMa3cvx=SUjT+nUoGd5irxr_ajg@mail.gmail.com>
	<E5C6A964-1931-4EB9-9B62-303309FDDAA6@bsdimp.com>
Message-ID: <015B02C6-41F4-433C-97A3-7F4BF6715DEC@orthanc.ca>


On 2012-02-02, at 2:47 PM, Warner Losh wrote:

> Embedded systems had limits of 4MB, 8MB or 16MB when these patches were done.

Those systems also tend to ship with a very carefully culled set of binaries.  Perhaps someone reading this with access to that type of system could do some measurements of a static vs. shared build of one of those embedded systems.  A well designed system without library bloat can pump out some pretty skinny static binaries.

--lyndon

From lyndon at orthanc.ca  Fri Feb  3 08:53:54 2012
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 2 Feb 2012 14:53:54 -0800
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
	<alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>
	<52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>
Message-ID: <AF73B35E-BB6C-44FE-A128-2EEE0A4CF0E0@orthanc.ca>


On 2012-02-02, at 1:49 PM, Warner Losh wrote:

> Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used

In the day of sub-hundred dollar terabyte drives, you're kidding me, right?

Also, ever lost libc.so on a Solaris box?

From norman at oclsc.org  Fri Feb  3 09:16:35 2012
From: norman at oclsc.org (Norman Wilson)
Date: Thu, 02 Feb 2012 18:16:35 -0500 (EST)
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
Message-ID: <1328224608.3272.for-standards-violators@oclsc.org>

Lyndon Nerenberg:

  A well designed system without library bloat can pump out some
  pretty skinny static binaries.

=======

V6, for example.  Or even V7 if carefully pruned.

Once upon a time, I made an RK05 disk (5MB) with a stripped-down
post-V7 for an 11/45.  It had just enough programs to allow
basic file manipulation and text-processing.

We used this compact system to allow our secretaries (in a
small university department in the early 1980s) to continue
typing up papers and letters on the day the machine-room
air conditioning was being replaced.  With the doors standing
open and a big fan, we were willing to leave the 11/45 running,
but not the VAX-11/780.

Due to contractor screwups (when the chilled water was turned
on, it rained up and down the hall--many poorly-soldered
joints in the copper pipes), we actually needed this for a
couple of days, so for safety I shut the system down every
evening, removed the RK05 cartridge, and took it downstairs
to the 11/34 that had a tape drive, where I booted RT11 and
took an image backup with ROLLOUT.

Norman Wilson
Toronto ON


From imp at bsdimp.com  Fri Feb  3 09:33:37 2012
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 2 Feb 2012 16:33:37 -0700
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <015B02C6-41F4-433C-97A3-7F4BF6715DEC@orthanc.ca>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
	<alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>
	<52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>
	<CAGSRWbiJesxtoC38_FEZM7_jMa3cvx=SUjT+nUoGd5irxr_ajg@mail.gmail.com>
	<E5C6A964-1931-4EB9-9B62-303309FDDAA6@bsdimp.com>
	<015B02C6-41F4-433C-97A3-7F4BF6715DEC@orthanc.ca>
Message-ID: <5274AA4A-9A0A-45BE-9387-564970B522D4@bsdimp.com>


On Feb 2, 2012, at 3:59 PM, Lyndon Nerenberg wrote:
> On 2012-02-02, at 2:47 PM, Warner Losh wrote:
> 
>> Embedded systems had limits of 4MB, 8MB or 16MB when these patches were done.
> 
> Those systems also tend to ship with a very carefully culled set of binaries.  Perhaps someone reading this with access to that type of system could do some measurements of a static vs. shared build of one of those embedded systems.  A well designed system without library bloat can pump out some pretty skinny static binaries.


You know that I wrote those patches for FreeBSD when I was producing embedded systems that needed the savings, right?

At the time, the size of / was on the order of 60MB without the patches and 8MB with the patches (excluding the kernel and modules).  Compression got the size of the kernel + / + /usr down to about 7MB which left enough room on the flash for our monolithic application.  At the time, the crunchgen approach to binaries produced similar values (about 6MB for the same list of binaries we selected).  However, our build process and monolithic application were ill suited to crunchgenning so we opted for shared libraries which got us most of the benefits and allowed us better flexibility in deploying new versions of our program.

After the patches were done, we discovered other benefits, such as easier deploying of security fixes...

Warner




From carl.lowenstein at gmail.com  Fri Feb  3 09:37:42 2012
From: carl.lowenstein at gmail.com (Carl Lowenstein)
Date: Thu, 2 Feb 2012 15:37:42 -0800
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <1328224608.3272.for-standards-violators@oclsc.org>
References: <1328224608.3272.for-standards-violators@oclsc.org>
Message-ID: <CAOgEH+OKy9fPkMLO99BXZQ_DrY_m4vG0s2WRddixc=b7U_DhWw@mail.gmail.com>

On Thu, Feb 2, 2012 at 3:16 PM, Norman Wilson <norman at oclsc.org> wrote:
> Lyndon Nerenberg:
>
>  A well designed system without library bloat can pump out some
>  pretty skinny static binaries.
>
> =======
>
> V6, for example.  Or even V7 if carefully pruned.
>
> Once upon a time, I made an RK05 disk (5MB) with a stripped-down
> post-V7 for an 11/45.  It had just enough programs to allow
> basic file manipulation and text-processing.
>
> We used this compact system to allow our secretaries (in a
> small university department in the early 1980s) to continue
> typing up papers and letters on the day the machine-room
> air conditioning was being replaced.  With the doors standing
> open and a big fan, we were willing to leave the 11/45 running,
> but not the VAX-11/780.
>
> Due to contractor screwups (when the chilled water was turned
> on, it rained up and down the hall--many poorly-soldered
> joints in the copper pipes), we actually needed this for a
> couple of days, so for safety I shut the system down every
> evening, removed the RK05 cartridge, and took it downstairs
> to the 11/34 that had a tape drive, where I booted RT11 and
> took an image backup with ROLLOUT.

You may have been lucky not to need the backup images.  My experience
with ROLLIN/ROLLOUT early on was that DEC software used only 200 of
the 203 tracks available on a RK05.   Unix on the other hand also used
the 3 spare tracks.  4872 whole blocks.  So ROLLIN backups of a Unix
RK05 did not always have everything on them.

    carl
-- 
    carl lowenstein         marine physical lab     u.c. san diego
                                                 clowenstein at ucsd.edu


From imp at bsdimp.com  Fri Feb  3 09:35:38 2012
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 2 Feb 2012 16:35:38 -0700
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <AF73B35E-BB6C-44FE-A128-2EEE0A4CF0E0@orthanc.ca>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
	<alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>
	<52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>
	<AF73B35E-BB6C-44FE-A128-2EEE0A4CF0E0@orthanc.ca>
Message-ID: <E84966AB-3128-4C2E-A07D-20A2FEB27294@bsdimp.com>


On Feb 2, 2012, at 3:53 PM, Lyndon Nerenberg wrote:
> On 2012-02-02, at 1:49 PM, Warner Losh wrote:
>> Thankfully, most binaries are dynamic these days, which saves a ton of space on / (as a percentage of what's used
> 
> In the day of sub-hundred dollar terabyte drives, you're kidding me, right?

No.  Read what I wrote: as a percentage of the whole.

> Also, ever lost libc.so on a Solaris box?

Yes. Thankfully, I've never had a similar loss on my FreeBSD boxes. :)

Warner

From cowan at mercury.ccil.org  Fri Feb  3 09:58:38 2012
From: cowan at mercury.ccil.org (John Cowan)
Date: Thu, 2 Feb 2012 18:58:38 -0500
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <1328224608.3272.for-standards-violators@oclsc.org>
References: <1328224608.3272.for-standards-violators@oclsc.org>
Message-ID: <20120202235838.GE21161@mercury.ccil.org>

Norman Wilson scripsit:

> Once upon a time, I made an RK05 disk (5MB) with a stripped-down
> post-V7 for an 11/45.  It had just enough programs to allow basic file
> manipulation and text-processing.

In my first job, around 1976, I hand-carried an RK05 from New Jersey
to Kansas City.  It was full of my employer's proprietary software,
which I was to install.  The laternative was to bring a huge pile of
floppies, which didn't seem sensible.

I was able to convince the airline security of those days that they
could neither open the RK nor X-ray it, but when it got there, it was
unreadable anyway.  My colleague took the next flight, with the huge
pile.

> Due to contractor screwups (when the chilled water was turned on, it
> rained up and down the hall--many poorly-soldered joints in the copper
> pipes), [...]

During PM, always mount a scratch machine room!

-- 
First known example of political correctness:   John Cowan
After Nurhachi had united all the other         http://www.ccil.org/~cowan
Jurchen tribes under the leadership of the      cowan at ccil.org
Manchus, his successor Abahai (1592-1643)
issued an order that the name Jurchen should       --S. Robert Ramsey,
be banned, and from then on, they were all           The Languages of China
to be called Manchus.


From tfb at tfeb.org  Fri Feb  3 21:10:02 2012
From: tfb at tfeb.org (Tim Bradshaw)
Date: Fri, 3 Feb 2012 11:10:02 +0000
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <AF73B35E-BB6C-44FE-A128-2EEE0A4CF0E0@orthanc.ca>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
	<alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>
	<52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>
	<AF73B35E-BB6C-44FE-A128-2EEE0A4CF0E0@orthanc.ca>
Message-ID: <0D449762-FD45-4528-B46E-AEA962E6B7CA@tfeb.org>

On 2 Feb 2012, at 22:53, Lyndon Nerenberg wrote:
> 
> In the day of sub-hundred dollar terabyte drives, you're kidding me, right?
> 
> Also, ever lost libc.so on a Solaris box?

This is missing the point.  A system with shared libraries can deliver a fix to a bug in a library by a new version of that library, instead of a new version of every program which is statically linked against that library.

From jrvalverde at cnb.csic.es  Sat Feb  4 01:22:16 2012
From: jrvalverde at cnb.csic.es (Jose R. Valverde)
Date: Fri, 3 Feb 2012 16:22:16 +0100
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <0D449762-FD45-4528-B46E-AEA962E6B7CA@tfeb.org>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
	<alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>
	<52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>
	<AF73B35E-BB6C-44FE-A128-2EEE0A4CF0E0@orthanc.ca>
	<0D449762-FD45-4528-B46E-AEA962E6B7CA@tfeb.org>
Message-ID: <20120203162216.504c4bb7@cnb.csic.es>

Whoa!

	I wasn't expecting this flood of comments! :-)

	Anyway, I think that I was clear: the choices about separating files
into directories, partitions, disks, network shares, etc... have always been
pretty obvious to anybody with a minimum of common sense. The only way around
them is foolishness or ignorance (or both).

	I can understand a newcomer, using a computer for his/her petty games
one task at a time and not doing much, to believe the world would be simpler
if it (or the filesystem) were flat and suited to his unvoiced personal 
expectations. This is nothing new, the machine language opcode RPM (read  
programmer's mind) is as old a joke as I can remember.

	There was a reason to separate user data from system data to avoid
the system disk from becoming unusable by a misbehaving user. There was one
to separate /tmp for the same reason (a buggy program might generate a huge
temporary file and render the system unusable for all other users). Same for
/var and out of control log files. When vendors started adding their software 
in /usr (and maintaining it) there ceased to be a standard, well known set 
of "reserved system program names" and it made sense to separate /usr/local 
for non-vendor maintained files which might have an unknown naming conflict 
(and I witnessed many at the time, not the less GNU) with "non-standard-UNIX" 
vendor additions. When LANs started to be common it made sense to share as 
many files as possible, and since executables would not be shareable on an
heterogeneous network (something most newcomers have never experienced -or
fancied) it became sensible to have /home and /usr/share separate and served
over the network. When UNIX systems became more complex and started to take 
over mainframes and get many users, it made sense to separate system programs 
from user programs, and it didn't make sense to duplicate all of them: hence 
a /bin for programs common to users and admins, and a /sbin for just admins 
(for standard system commands) and a /usr/bin and /usr/sbin (for vendor 
maintained commands and  system daemons) and a /usr/local/bin and a 
/usr/local/sbin (for locally added commands and system tools and daemons). 
/lib, /lib64, /usr/lib and /usr/lib64? Heck! that's not even enough to
ensure user programs keep on running after a system upgrade and cleanup.
I often try to keep relevant packages in their own directory and run an
automated ldd to save in their own .../lib their shared libraries before
doing an upgrade. There are binaries that haven't been updated since the
'90s and require very old libraries (or even worst, complex sources that
require various versions of the GCC toolchain). It doesn't make sense to
port them, it's easier to ensure they keep on running keeping their libraries.
And so on.

	And many of these arguments might hold today. One might argue that
since people is now tied to a vendor (Ubuntu, or RedHat, or Oracle, or HP,
or whomever) one no longer needs separate / and /usr spaces. The problem
is that would only work for newbies and occasional users, but would fail
for most other cases (large computing servers and multiuser shops as well
as tiny embedded devices, as pointed out). So, as long as systems are shipped
to run on any machine, the layout should be versatile enough to accommodate
all uses. Hence the need for maintaining these conventions, not legacy or
bureaucracy. What is shortsighted is to expect all use-cases to be like a
home user who only runs one game or, at most, his/her word-processor, 
e-mail and navigator simultaneously.

	Beyond that, the original articles and comments complained also about
directory naming (/bin /etc /lib) as "unintuitive". I fail to understand in
what way is it easier for someone new to a computer to learn a "/bin /etc /var
/lib" alien terminology and what it means, than to learn "System Config Libraries
etc..." or "Windows Windows32 Windows64 Temp Users and Settings, etc..." The
point is one needs to learn them and if you are familiar with one terminology
then to map terms, and if we are to use a standard, at least POSIX is one.

	That said, I often place everything (but /boot) in a single partition 
for single-user machines (except for power users who usually demand at least
separate /tmp and /home) and there is nothing to prevent one from making symlinks
(er, aliases for Windowers) to system directories with whatever names you like.
And I still see a need to separate the system from vendor files and from user
files (like, e.g. when you later want to switch from say RedHat to Debian). Only
a moron would ignore the risk of system files left around by vendor-specific
naming conventions.

	I said originally I could rant on and on. And I can. And add lots of
anecdotes, but I'll leave it here.

	Sorry. Couldn't resist.

				j

-- 
			EMBnet/CNB
		Scientific Computing Service
	Solving all your computer needs for Scientific
			Research.

		http://bioportal.cnb.csic.es
		  http://www.es.embnet.org


From ron at ronnatalie.com  Sat Feb  4 02:06:13 2012
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 3 Feb 2012 11:06:13 -0500
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <20120203162216.504c4bb7@cnb.csic.es>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
	<alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>
	<52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>
	<AF73B35E-BB6C-44FE-A128-2EEE0A4CF0E0@orthanc.ca>
	<0D449762-FD45-4528-B46E-AEA962E6B7CA@tfeb.org>
	<20120203162216.504c4bb7@cnb.csic.es>
Message-ID: <E1C1F408-6892-4D9E-9739-5104A4E2C48C@ronnatalie.com>


On Feb 3, 2012, at 10:22 AM, Jose R. Valverde wrote:
> 
> 	There was a reason to separate user data from system data to avoid
> the system disk from becoming unusable by a misbehaving user.

But this wasn't practically done in the early UNIX.   Even much that was in /usr was required for normal system operation and there was stuff that got left on the root that was within the user's ability to hose up.    I was system administrator of a V6 UNIX that was used in a University setting in the late 70's.   People banging on the disks was the least of my issues.    There were far more fun ways to crash UNIX (and even PDP-11's in general), break security, etc... that I ran around trying to forestall.

In fact our /usr was on the root disk.   We had two "user" home directory drives /sys1 and /sys2 on two more RK05's. My first quota as a student was 8 blocks (4K).   I supplemented that at first with a dectape (half a megabyte) and then with my own RK05 pack (we reserved two drives for user mounted volumes).    

We swapped to an RF11 fixed head disk of about a megabyte.

The fun one was people trying to ascribe meanings to the "acronyms" on the kernel disk (KEN and DMR).




From lyricalnanoha at usotsuki.hoshinet.org  Sat Feb  4 02:09:08 2012
From: lyricalnanoha at usotsuki.hoshinet.org (Steve Nickolas)
Date: Fri, 3 Feb 2012 17:09:08 +0100 (CET)
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <20120203162216.504c4bb7@cnb.csic.es>
References: <CAFCBnZvMuUvZNm72pvWkS30PH7o3eS8ii2WQ5XaZyviAxhwHOA@mail.gmail.com>
	<20120201121214.55c73577@cnb.csic.es>
	<4F2A907D.9000000@fastmail.us>
	<89159FF1-5521-4890-A5F0-30DC9E5B7EC9@bsdimp.com>
	<20120202173623.GQ30634@mercury.ccil.org>
	<alpine.BSF.2.00.1202030759350.66525@aneurin.horsfall.org>
	<52BD3851-95AF-4DFC-8728-9F2DB1E1614C@bsdimp.com>
	<AF73B35E-BB6C-44FE-A128-2EEE0A4CF0E0@orthanc.ca>
	<0D449762-FD45-4528-B46E-AEA962E6B7CA@tfeb.org>
	<20120203162216.504c4bb7@cnb.csic.es>
Message-ID: <alpine.DEB.2.00.1202031706580.3528@ns383864.ovh.net>

On Fri, 3 Feb 2012, Jose R. Valverde wrote:

(snipping)

> 	There was a reason to separate user data from system data to avoid
> the system disk from becoming unusable by a misbehaving user. There was one
> to separate /tmp for the same reason (a buggy program might generate a huge
> temporary file and render the system unusable for all other users). Same for
> /var and out of control log files. When vendors started adding their software
> in /usr (and maintaining it) there ceased to be a standard, well known set
> of "reserved system program names" and it made sense to separate /usr/local
> for non-vendor maintained files which might have an unknown naming conflict
> (and I witnessed many at the time, not the less GNU) with "non-standard-UNIX"
> vendor additions. When LANs started to be common it made sense to share as
> many files as possible, and since executables would not be shareable on an
> heterogeneous network (something most newcomers have never experienced -or
> fancied) it became sensible to have /home and /usr/share separate and served
> over the network. When UNIX systems became more complex and started to take
> over mainframes and get many users, it made sense to separate system programs
> from user programs, and it didn't make sense to duplicate all of them: hence
> a /bin for programs common to users and admins, and a /sbin for just admins
> (for standard system commands) and a /usr/bin and /usr/sbin (for vendor
> maintained commands and  system daemons) and a /usr/local/bin and a
> /usr/local/sbin (for locally added commands and system tools and daemons).
> /lib, /lib64, /usr/lib and /usr/lib64? Heck! that's not even enough to
> ensure user programs keep on running after a system upgrade and cleanup.
> I often try to keep relevant packages in their own directory and run an
> automated ldd to save in their own .../lib their shared libraries before
> doing an upgrade. There are binaries that haven't been updated since the
> '90s and require very old libraries (or even worst, complex sources that
> require various versions of the GCC toolchain). It doesn't make sense to
> port them, it's easier to ensure they keep on running keeping their libraries.
> And so on.
>
> 	And many of these arguments might hold today. One might argue that
> since people is now tied to a vendor (Ubuntu, or RedHat, or Oracle, or HP,
> or whomever) one no longer needs separate / and /usr spaces. The problem
> is that would only work for newbies and occasional users, but would fail
> for most other cases (large computing servers and multiuser shops as well
> as tiny embedded devices, as pointed out). So, as long as systems are shipped
> to run on any machine, the layout should be versatile enough to accommodate
> all uses. Hence the need for maintaining these conventions, not legacy or
> bureaucracy. What is shortsighted is to expect all use-cases to be like a
> home user who only runs one game or, at most, his/her word-processor,
> e-mail and navigator simultaneously.
>
> 	Beyond that, the original articles and comments complained also about
> directory naming (/bin /etc /lib) as "unintuitive". I fail to understand in
> what way is it easier for someone new to a computer to learn a "/bin /etc /var
> /lib" alien terminology and what it means, than to learn "System Config Libraries
> etc..." or "Windows Windows32 Windows64 Temp Users and Settings, etc..." The
> point is one needs to learn them and if you are familiar with one terminology
> then to map terms, and if we are to use a standard, at least POSIX is one.
>
> 	That said, I often place everything (but /boot) in a single partition
> for single-user machines (except for power users who usually demand at least
> separate /tmp and /home) and there is nothing to prevent one from making symlinks
> (er, aliases for Windowers) to system directories with whatever names you like.
> And I still see a need to separate the system from vendor files and from user
> files (like, e.g. when you later want to switch from say RedHat to Debian). Only
> a moron would ignore the risk of system files left around by vendor-specific
> naming conventions.
>
> 	I said originally I could rant on and on. And I can. And add lots of
> anecdotes, but I'll leave it here.
>
> 	Sorry. Couldn't resist.
>
> 				j
>
>

Actually, I tend to think the bare minimum to get the system running goes 
in /bin, /sbin and /lib, the rest of the base in /usr/bin, /usr/lib, 
/usr/include and /usr/sbin ... and all installed apps really ought to be 
in trees off /opt (although that would break stuff that expects X in 
/usr/X11R6/bin if I put it in /opt/X11 instead).  But that's just my own 
opinion.

-uso.


From pepe at naleco.com  Sun Feb  5 05:34:17 2012
From: pepe at naleco.com (Pepe)
Date: Sat, 4 Feb 2012 20:34:17 +0100
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
Message-ID: <000901cce373$fc2e2ad0$50651bac@naleco.com>

"Jose R. Valverde" <jrvalverde at cnb.csic.es> said:

> Beyond that, the original articles and comments complained also about
> directory naming (/bin /etc /lib) as "unintuitive". I fail to
> understand in 
> what way is it easier for someone new to a computer to learn a "/bin
> /etc /var /lib" alien terminology and what it means, than to learn
> "System Config Libraries 
> etc..." or "Windows Windows32 Windows64 Temp Users and Settings,
> etc..."

In SCO Xenix/UNIX, the home directory is usually mounted on /u.

I was amused the first time I saw it.


From lyndon at orthanc.ca  Sun Feb  5 07:05:03 2012
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sat, 4 Feb 2012 13:05:03 -0800
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <000901cce373$fc2e2ad0$50651bac@naleco.com>
References: <000901cce373$fc2e2ad0$50651bac@naleco.com>
Message-ID: <944F79B5-F88C-42EF-A73D-10DDDE0F2987@orthanc.ca>


On 2012-02-04, at 11:34 AM, Pepe wrote:

> In SCO Xenix/UNIX, the home directory is usually mounted on /u.
> 
> I was amused the first time I saw it.

The /u convention was a common site convention in at least the early 1980s. I don't recall a vendor using it as a default in any shipping system, though.  Mind you, I have blissfully forgotten most of my follies with Xenix.

--lyndon

From hjt at ATComputing.nl  Sun Feb  5 18:38:00 2012
From: hjt at ATComputing.nl (Hendrik Jan Thomassen)
Date: Sun, 5 Feb 2012 09:38:00 +0100
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
Message-ID: <20120205083800.GA12910@vcursdoc.atcomputing.nl>


If I recall well the /sbin directory first appeared in HP/UX,
and the name stood for 'Static binaries'. Its reason for existence
was that with the introduction of shared libraries the file with
the C-library had become a single point of failure. Therefore this
sbin was introduced to hold Statically linked executables for the
most important commands needed to fix a broken system (sh, ls, mv,
cp, find, tar, fsck etcetera). With this directory earlier than
/bin in his PATH the administrator could at least restore a working
libc.so file. And, while we are at it, the name 'executable' was
not commonly used: they were called 'binaries' (except in IBM
mainframe terminology were they were called 'load modules').
Only much later the habit of /sbin = System binaries emerged.

An important reason to split /bin vs. /usr/bin and /lib vs. /usr/lib
etc. was that the root file system had to be kept small. The fsck
program, while at work, builds tables. If possible, they stay in
memory, but if memory runs out fsck writes them to disk. However,
you don't want them to be written to an untrusted/unchecked file
system, and certainly not to the file system currently under repair.
Since the root file system has to be checked before the others, it
had to be small enough so ensure that fsck could run memory-based
only. Therefore: the /bin, /lib and other root-fs based directories
held the minimal stuff needed for booting and for repairs/restores,
while all the rest had to go into the "overflow" directories /usr/bin,
/usr/lib etc (and, obviously, /usr was a separately mounted partition).
Remember: those were the days that every reboot included a full
fsck on all your partitions. 
-- 
Hendrik-Jan Thomassen     <hjt at ATComputing.nl>
AT Computing
6546 BE  Nijmegen NL      Fax +31 24 352 72 92
info at atcomputing.nl       www.atcomputing.nl
'If you think education is expensive, then try ignorance.'



From jaapna at xs4all.nl  Sun Feb  5 20:13:50 2012
From: jaapna at xs4all.nl (Jaap Akkerhuis)
Date: Sun, 5 Feb 2012 11:13:50 +0100
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <20120205083800.GA12910@vcursdoc.atcomputing.nl>
References: <20120205083800.GA12910@vcursdoc.atcomputing.nl>
Message-ID: <3FFAC15F-C8C4-4B7E-B4F5-679652F907FF@xs4all.nl>


On Feb 5, 2012, at 9:38, Hendrik Jan Thomassen wrote:

> Remember: those were the days that every reboot included a full
> fsck on all your partitions. 

And before such a modern tool as fsck came one used icheck/ncheck/clri to
fix broken file systems.  Ah, those were the days ...

	jaap


From imp at bsdimp.com  Mon Feb  6 03:15:15 2012
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 5 Feb 2012 10:15:15 -0700
Subject: [TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split
In-Reply-To: <20120205083800.GA12910@vcursdoc.atcomputing.nl>
References: <20120205083800.GA12910@vcursdoc.atcomputing.nl>
Message-ID: <E88D8354-1917-4985-8DDB-21FF615C025F@bsdimp.com>


On Feb 5, 2012, at 1:38 AM, Hendrik Jan Thomassen wrote:
> If I recall well the /sbin directory first appeared in HP/UX,
> and the name stood for 'Static binaries'.

Do you recall when this was?

4.3-RENO has the bin/sbin split, and that was 1990, but the split isn't yet in 4.3-Tahoe, which was in 1988.  In 4.3-RENO it was already system binaries since 4.3 didn't have shared libraries, at least according to the TUHS 4.3-RENO archive

	http://minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/share/man/man7/hier.7

I don't have a copy of the BSD SCCS trees to narrow the split down further...

Perhaps this indicates multiple invention?

Warner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120205/84dadaff/attachment.html>

From wkt at tuhs.org  Tue Feb 21 06:30:35 2012
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 21 Feb 2012 06:30:35 +1000
Subject: [TUHS] Yet Another Kernel Description Document
Message-ID: <20120220203034.GA10432@minnie.tuhs.org>

All, I've just received from Poul-Henning Kamp a document entitled
"UNIX Program Description", dated January 1976 and written by the
UNIX Support Group. It contains detailed descriptions of the functions
inside a Unix kernel. Given the date and the USG origin, I'm guessing
that the system described is PWB/1.0. Can anybody confirm this at all?

The URL is http://minnie.tuhs.org/Archive/PDP-11/Distributions/usdl/unix_program_description_jan_1976.pdf
but I'll move it if it turns out not to be about PWB.

I love how new documents and artifacts keep appearing! Thanks phk.

Cheers,
	Warren


From arnold at skeeve.com  Tue Feb 21 06:52:36 2012
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 20 Feb 2012 12:52:36 -0800
Subject: [TUHS] why the leading under score added to function names?
Message-ID: <201202202052.q1KKqagi002055@freefriends.org>

Hi All.

Recently at work I helped someone figure out that when working with ld,
the name of a function "foo" gets turned into "_foo" by the compiler.
(It took this old-timer 15 minutes to solve a problem he had been working
on for two days!)

I'm pretty sure this dates back to PDP-11 days.  I'm wondering "why?".
Why did the C compiler prepend an underscore to function names?

Thanks,

Arnold


From dave at horsfall.org  Tue Feb 21 09:21:41 2012
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 21 Feb 2012 10:21:41 +1100 (EST)
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <201202202052.q1KKqagi002055@freefriends.org>
References: <201202202052.q1KKqagi002055@freefriends.org>
Message-ID: <alpine.BSF.2.00.1202211012090.62608@aneurin.horsfall.org>

On Mon, 20 Feb 2012, arnold at skeeve.com wrote:

[...]

> I'm pretty sure this dates back to PDP-11 days.  I'm wondering "why?".
> Why did the C compiler prepend an underscore to function names?

Sure was the PDP-11 :-)  I vaguely recall that it was to make sure that
user functions did not conflict with predefined assembler functions, as
that would be a pain to diagnose (much like having swap overlap root).

-- Dave


From brantley at coraid.com  Tue Feb 21 10:34:26 2012
From: brantley at coraid.com (Brantley Coile)
Date: Mon, 20 Feb 2012 18:34:26 -0600
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <alpine.BSF.2.00.1202211012090.62608@aneurin.horsfall.org>
References: <201202202052.q1KKqagi002055@freefriends.org>
	<alpine.BSF.2.00.1202211012090.62608@aneurin.horsfall.org>
Message-ID: <96DE558D-5FE2-4F6F-BC83-18EC727162FA@coraid.com>

correct.  we could link to assembler code with _entry points and not worry about symbol collisions in the rest of the code. 

iPhone email

On Feb 20, 2012, at 6:23 PM, "Dave Horsfall" <dave at horsfall.org> wrote:

> On Mon, 20 Feb 2012, arnold at skeeve.com wrote:
> 
> [...]
> 
>> I'm pretty sure this dates back to PDP-11 days.  I'm wondering "why?".
>> Why did the C compiler prepend an underscore to function names?
> 
> Sure was the PDP-11 :-)  I vaguely recall that it was to make sure that
> user functions did not conflict with predefined assembler functions, as
> that would be a pain to diagnose (much like having swap overlap root).
> 
> -- Dave
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From a.phillip.garcia at gmail.com  Tue Feb 21 11:50:09 2012
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Mon, 20 Feb 2012 19:50:09 -0600
Subject: [TUHS] Yet Another Kernel Description Document
In-Reply-To: <20120220203034.GA10432@minnie.tuhs.org>
References: <20120220203034.GA10432@minnie.tuhs.org>
Message-ID: <CAFCBnZsyZkeJ85WBcutUkVec_H7CEGkowVOhghpjj0M3gc3E5A@mail.gmail.com>

nice. any details on the provenance, like those you shared regarding
the 1st edition kernel documents a couple months ago?

On 2/20/12, Warren Toomey <wkt at tuhs.org> wrote:
> All, I've just received from Poul-Henning Kamp a document entitled
> "UNIX Program Description", dated January 1976 and written by the
> UNIX Support Group. It contains detailed descriptions of the functions
> inside a Unix kernel. Given the date and the USG origin, I'm guessing
> that the system described is PWB/1.0. Can anybody confirm this at all?
>
> The URL is
> http://minnie.tuhs.org/Archive/PDP-11/Distributions/usdl/unix_program_description_jan_1976.pdf
> but I'll move it if it turns out not to be about PWB.
>
> I love how new documents and artifacts keep appearing! Thanks phk.
>
> Cheers,
> 	Warren
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>


From wkt at tuhs.org  Tue Feb 21 11:53:27 2012
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 21 Feb 2012 11:53:27 +1000
Subject: [TUHS] Yet Another Kernel Description Document
In-Reply-To: <CAFCBnZsyZkeJ85WBcutUkVec_H7CEGkowVOhghpjj0M3gc3E5A@mail.gmail.com>
References: <20120220203034.GA10432@minnie.tuhs.org>
	<CAFCBnZsyZkeJ85WBcutUkVec_H7CEGkowVOhghpjj0M3gc3E5A@mail.gmail.com>
Message-ID: <20120221015327.GA8313@minnie.tuhs.org>

On Mon, Feb 20, 2012 at 07:50:09PM -0600, A. P. Garcia wrote:
> nice. any details on the provenance, like those you shared regarding
> the 1st edition kernel documents a couple months ago?

Unfortunately, no. phk can't remember exactly where he got the document,
but he is trying to jog his memory :)

Cheers,
	Warren


From imp at bsdimp.com  Tue Feb 21 12:50:00 2012
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 20 Feb 2012 19:50:00 -0700
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <96DE558D-5FE2-4F6F-BC83-18EC727162FA@coraid.com>
References: <201202202052.q1KKqagi002055@freefriends.org>
	<alpine.BSF.2.00.1202211012090.62608@aneurin.horsfall.org>
	<96DE558D-5FE2-4F6F-BC83-18EC727162FA@coraid.com>
Message-ID: <AAE63D3D-4F18-41E3-9059-7F885D6B29F5@bsdimp.com>

And this convention went away with ELF binaries.  No more _foo for function foo.

Also, the fortran compiler would emit entry_ to as to not conflict either.  Made calling C from Fortran, and vice versa, a lot of fun...

Warner

On Feb 20, 2012, at 5:34 PM, Brantley Coile wrote:

> correct.  we could link to assembler code with _entry points and not worry about symbol collisions in the rest of the code. 
> 
> iPhone email
> 
> On Feb 20, 2012, at 6:23 PM, "Dave Horsfall" <dave at horsfall.org> wrote:
> 
>> On Mon, 20 Feb 2012, arnold at skeeve.com wrote:
>> 
>> [...]
>> 
>>> I'm pretty sure this dates back to PDP-11 days.  I'm wondering "why?".
>>> Why did the C compiler prepend an underscore to function names?
>> 
>> Sure was the PDP-11 :-)  I vaguely recall that it was to make sure that
>> user functions did not conflict with predefined assembler functions, as
>> that would be a pain to diagnose (much like having swap overlap root).
>> 
>> -- Dave
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> 



From cowan at mercury.ccil.org  Tue Feb 21 13:33:39 2012
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 20 Feb 2012 22:33:39 -0500
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <AAE63D3D-4F18-41E3-9059-7F885D6B29F5@bsdimp.com>
References: <201202202052.q1KKqagi002055@freefriends.org>
	<alpine.BSF.2.00.1202211012090.62608@aneurin.horsfall.org>
	<96DE558D-5FE2-4F6F-BC83-18EC727162FA@coraid.com>
	<AAE63D3D-4F18-41E3-9059-7F885D6B29F5@bsdimp.com>
Message-ID: <20120221033339.GA11143@mercury.ccil.org>

Warner Losh scripsit:

> Also, the fortran compiler would emit entry_ to as to not conflict
> either.  Made calling C from Fortran, and vice versa, a lot of fun...

Unix f77 emitted _foo_, that is, what C saw as foo_.  In effect you
could call arbitrary Fortran routines from C, but not really vice versa:
in order to do so, the C functions had to have names ending in _ and use
the f77 type system.

-- 
A rabbi whose congregation doesn't want         John Cowan
to drive him out of town isn't a rabbi,         http://www.ccil.org/~cowan
and a rabbi who lets them do it                 cowan at ccil.org
isn't a man.    --Jewish saying


From lyricalnanoha at usotsuki.hoshinet.org  Tue Feb 21 13:41:38 2012
From: lyricalnanoha at usotsuki.hoshinet.org (Steve Nickolas)
Date: Tue, 21 Feb 2012 04:41:38 +0100 (CET)
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <AAE63D3D-4F18-41E3-9059-7F885D6B29F5@bsdimp.com>
References: <201202202052.q1KKqagi002055@freefriends.org>
	<alpine.BSF.2.00.1202211012090.62608@aneurin.horsfall.org>
	<96DE558D-5FE2-4F6F-BC83-18EC727162FA@coraid.com>
	<AAE63D3D-4F18-41E3-9059-7F885D6B29F5@bsdimp.com>
Message-ID: <alpine.DEB.2.00.1202210441010.17788@ns383864.ovh.net>

On Mon, 20 Feb 2012, Warner Losh wrote:

> And this convention went away with ELF binaries.  No more _foo for 
> function foo.
>
> Also, the fortran compiler would emit entry_ to as to not conflict 
> either.  Made calling C from Fortran, and vice versa, a lot of fun...
>
> Warner

Watcom C did the postfix style, dunno if it still does.

-uso.


From ron at ronnatalie.com  Wed Feb 22 04:18:59 2012
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Tue, 21 Feb 2012 13:18:59 -0500 (EST)
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <AAE63D3D-4F18-41E3-9059-7F885D6B29F5@bsdimp.com>
References: <201202202052.q1KKqagi002055@freefriends.org>
	<alpine.BSF.2.00.1202211012090.62608@aneurin.horsfall.org>
	<96DE558D-5FE2-4F6F-BC83-18EC727162FA@coraid.com>
	<AAE63D3D-4F18-41E3-9059-7F885D6B29F5@bsdimp.com>
Message-ID: <61309.20.132.68.147.1329848339.squirrel@webmail.tuffmail.net>

An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120221/3310edb0/attachment.html>

From arnold at skeeve.com  Thu Feb 23 05:17:28 2012
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 22 Feb 2012 11:17:28 -0800
Subject: [TUHS] why the leading under score added to function names?
Message-ID: <201202221917.q1MJHSGw013561@freefriends.org>

Hi All.

This is interesting. It shows that (apparently) early on, assembler was
viewed as the primary programming language.

It also shows the consequences a small, apparently local decision can have:
here we are 40+ years later and GCC on Windows is still preprending
underscores to function names!

In 15 minutes I helped the guy at work solve a problem he'd been working
on for two days!

Thanks everyone,

Arnold

> From: Brantley Coile <brantley at coraid.com>
> To: Dave Horsfall <dave at horsfall.org>
> Date: Mon, 20 Feb 2012 18:34:26 -0600
> Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>
> Subject: Re: [TUHS] why the leading under score added to function names?
>
> correct.  we could link to assembler code with _entry points and not
i> worry about symbol collisions in the rest of the code. 
>
> iPhone email
>
> On Feb 20, 2012, at 6:23 PM, "Dave Horsfall" <dave at horsfall.org> wrote:
>
> > On Mon, 20 Feb 2012, arnold at skeeve.com wrote:
> > 
> > [...]
> > 
> >> I'm pretty sure this dates back to PDP-11 days.  I'm wondering "why?".
> >> Why did the C compiler prepend an underscore to function names?
> > 
> > Sure was the PDP-11 :-)  I vaguely recall that it was to make sure that
> > user functions did not conflict with predefined assembler functions, as
> > that would be a pain to diagnose (much like having swap overlap root).
> > 
> > -- Dave


From dave at horsfall.org  Thu Feb 23 07:22:17 2012
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 23 Feb 2012 08:22:17 +1100 (EST)
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <201202221917.q1MJHSGw013561@freefriends.org>
References: <201202221917.q1MJHSGw013561@freefriends.org>
Message-ID: <alpine.BSF.2.00.1202230752140.62608@aneurin.horsfall.org>

On Wed, 22 Feb 2012, arnold at skeeve.com wrote:

> This is interesting. It shows that (apparently) early on, assembler was
> viewed as the primary programming language.

Well, C didn't exactly spring from Zeus's brow :-)  A good chunk of the
C library was in assembler, as were quite a number of programs.

> It also shows the consequences a small, apparently local decision can have:
> here we are 40+ years later and GCC on Windows is still preprending
> underscores to function names!

When it comes to Windoze, nothing surprises me any more.  Unix has evolved
over the years, but Windoze was spat out and hatched.

-- Dave


From a.phillip.garcia at gmail.com  Thu Feb 23 08:47:29 2012
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Wed, 22 Feb 2012 16:47:29 -0600
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <alpine.BSF.2.00.1202230752140.62608@aneurin.horsfall.org>
References: <201202221917.q1MJHSGw013561@freefriends.org>
	<alpine.BSF.2.00.1202230752140.62608@aneurin.horsfall.org>
Message-ID: <CAFCBnZt5J_7y86z3UWj_JxwAPb_+T2GfhDJVFKkoQYaxb-b05Q@mail.gmail.com>

On Wed, Feb 22, 2012 at 3:22 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 22 Feb 2012, arnold at skeeve.com wrote:
>
> > This is interesting. It shows that (apparently) early on, assembler was
> > viewed as the primary programming language.
>
> Well, C didn't exactly spring from Zeus's brow :-)  A good chunk of the
> C library was in assembler, as were quite a number of programs.
>

relevant:
http://cm.bell-labs.com/who/dmr/hist.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120222/fc7b9729/attachment.html>

From grog at lemis.com  Thu Feb 23 14:30:21 2012
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 23 Feb 2012 15:30:21 +1100
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <alpine.BSF.2.00.1202230752140.62608@aneurin.horsfall.org>
References: <201202221917.q1MJHSGw013561@freefriends.org>
	<alpine.BSF.2.00.1202230752140.62608@aneurin.horsfall.org>
Message-ID: <20120223043021.GA72269@dereel.lemis.com>

On Thursday, 23 February 2012 at  8:22:17 +1100, Dave Horsfall wrote:
> On Wed, 22 Feb 2012, arnold at skeeve.com wrote:
>> It also shows the consequences a small, apparently local decision
>> can have: here we are 40+ years later and GCC on Windows is still
>> preprending underscores to function names!
>
> When it comes to Windoze, nothing surprises me any more.  Unix has
> evolved over the years, but Windoze was spat out and hatched.

I'm no friend of Microsoft either, but gcc isn't exactly Microsoft.
What Arnold mentions here is Unix history in action.

Greg
--
Sent from my desktop computer
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120223/bb41d2c1/attachment.sig>

From spedraja at gmail.com  Thu Feb 23 18:18:43 2012
From: spedraja at gmail.com (Sergio Pedraja)
Date: Thu, 23 Feb 2012 08:18:43 +0000 (UTC)
Subject: [TUHS] =?utf-8?q?Invitaci=C3=B3n_a_conectarnos_en_LinkedIn?=
Message-ID: <1148794579.6426880.1329985123763.JavaMail.app@ela4-bed82.prod>

LinkedIn
------------



Me gustaría añadirte a mi red profesional en LinkedIn.
 
-Sergio

Sergio Pedraja
IT Security Administrator / Information Security Manager en Savings Bank
Santander y alrededores, España

Confirma que conoces a Sergio Pedraja:
https://www.linkedin.com/e/-9arw1o-gyzisxbk-15/isd/6035309375/9Ym-js9F/?hs=false&tok=1RpwAbuU2ieR81

--
Estás recibiendo invitaciones a conectar. Haz clic para darte de baja:
http://www.linkedin.com/e/-9arw1o-gyzisxbk-15/_SZkCeK7HqzqROuy9YxIdtKYnud5RcPs/goo/TUHS%40minnie%2Etuhs%2Eorg/20061/I2097818075_1/?hs=false&tok=1vGDnY_cmieR81

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, EE.UU.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120223/f09e743f/attachment.html>

From spedraja at gmail.com  Thu Feb 23 18:18:49 2012
From: spedraja at gmail.com (Sergio Pedraja)
Date: Thu, 23 Feb 2012 08:18:49 +0000 (UTC)
Subject: [TUHS] =?utf-8?q?Invitaci=C3=B3n_a_conectarnos_en_LinkedIn?=
Message-ID: <483977762.21368179.1329985129840.JavaMail.app@ela4-bed81.prod>

LinkedIn
------------



Me gustaría añadirte a mi red profesional en LinkedIn.
 
-Sergio

Sergio Pedraja
IT Security Administrator / Information Security Manager en Savings Bank
Santander y alrededores, España

Confirma que conoces a Sergio Pedraja:
https://www.linkedin.com/e/-amg4ei-gyzit20d-4/isd/6035310080/f1t_FAOT/?hs=false&tok=2oSTjszkSieR81

--
Estás recibiendo invitaciones a conectar. Haz clic para darte de baja:
http://www.linkedin.com/e/-amg4ei-gyzit20d-4/IES2kw2WbAK2tgMLcf1q-MI/goo/tuhs%40tuhs%2Eorg/20061/I2097818448_1/?hs=false&tok=27FHkZoUeieR81

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, EE.UU.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120223/7860434b/attachment.html>

From random832 at fastmail.us  Sun Feb 26 04:45:23 2012
From: random832 at fastmail.us (Random832)
Date: Sat, 25 Feb 2012 13:45:23 -0500
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <20120223043021.GA72269@dereel.lemis.com>
References: <201202221917.q1MJHSGw013561@freefriends.org>
	<alpine.BSF.2.00.1202230752140.62608@aneurin.horsfall.org>
	<20120223043021.GA72269@dereel.lemis.com>
Message-ID: <4F492C43.3020602@fastmail.us>

On 2/22/2012 11:30 PM, Greg 'groggy' Lehey wrote:
> On Thursday, 23 February 2012 at  8:22:17 +1100, Dave Horsfall wrote:
>> On Wed, 22 Feb 2012, arnold at skeeve.com wrote:
>>> It also shows the consequences a small, apparently local decision
>>> can have: here we are 40+ years later and GCC on Windows is still
>>> preprending underscores to function names!
>> When it comes to Windoze, nothing surprises me any more.  Unix has
>> evolved over the years, but Windoze was spat out and hatched.
> I'm no friend of Microsoft either, but gcc isn't exactly Microsoft.
> What Arnold mentions here is Unix history in action.
>
Yes and no. IIRC, gcc doesn't do that on, for example, Linux ELF. it's 
done on windows, I assume, in deference to the windows 32-bit ABI for 
cdecl calling convention functions.

Now, as far as where windows gets that from (just because something 
evolved within one company doesn't mean it didn't evolve), supposedly 
early versions of Microsoft C (pre-ANSI) were very conservative in terms 
of adhering to the "standard" set by Unix C and K&R - this could have 
extended to the prepending of underscores. For instance, this is, 
according to Raymond Chen, why they added WinMain rather than extending 
main (they didn't know if extensions to main would be allowed). I would 
also guess it's why MSVC stdio is implemented on top of an imitation of 
Unix system calls which is in turn implemented on top of DOS/windows; 
and why MSVC time_t is defined as seconds since 1970. There are comments 
in the code referring to XENIX in various places relating to I/O and 
timestamps, so it's possible that MSVC's C library was indeed, to some 
small degree, based on Unix.


From lyricalnanoha at usotsuki.hoshinet.org  Sun Feb 26 05:24:40 2012
From: lyricalnanoha at usotsuki.hoshinet.org (Steve Nickolas)
Date: Sat, 25 Feb 2012 20:24:40 +0100 (CET)
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <4F492C43.3020602@fastmail.us>
References: <201202221917.q1MJHSGw013561@freefriends.org>
	<alpine.BSF.2.00.1202230752140.62608@aneurin.horsfall.org>
	<20120223043021.GA72269@dereel.lemis.com>
	<4F492C43.3020602@fastmail.us>
Message-ID: <alpine.DEB.2.00.1202252021070.24041@ns383864.ovh.net>

On Sat, 25 Feb 2012, Random832 wrote:

> On 2/22/2012 11:30 PM, Greg 'groggy' Lehey wrote:
>> On Thursday, 23 February 2012 at  8:22:17 +1100, Dave Horsfall wrote:
>>> On Wed, 22 Feb 2012, arnold at skeeve.com wrote:
>>>> It also shows the consequences a small, apparently local decision
>>>> can have: here we are 40+ years later and GCC on Windows is still
>>>> preprending underscores to function names!
>>> When it comes to Windoze, nothing surprises me any more.  Unix has
>>> evolved over the years, but Windoze was spat out and hatched.
>> I'm no friend of Microsoft either, but gcc isn't exactly Microsoft.
>> What Arnold mentions here is Unix history in action.
>> 
> Yes and no. IIRC, gcc doesn't do that on, for example, Linux ELF. it's done 
> on windows, I assume, in deference to the windows 32-bit ABI for cdecl 
> calling convention functions.
>
> Now, as far as where windows gets that from (just because something evolved 
> within one company doesn't mean it didn't evolve), supposedly early versions 
> of Microsoft C (pre-ANSI) were very conservative in terms of adhering to the 
> "standard" set by Unix C and K&R - this could have extended to the prepending 
> of underscores. For instance, this is, according to Raymond Chen, why they 
> added WinMain rather than extending main (they didn't know if extensions to 
> main would be allowed). I would also guess it's why MSVC stdio is implemented 
> on top of an imitation of Unix system calls which is in turn implemented on 
> top of DOS/windows; and why MSVC time_t is defined as seconds since 1970. 
> There are comments in the code referring to XENIX in various places relating 
> to I/O and timestamps, so it's possible that MSVC's C library was indeed, to 
> some small degree, based on Unix.

Though DOS's file i/o calls, starting in 2.0, were much the same as 
Unix's already.  Its open, close, read, write have the same basic 
semantics and at one point it was possible to have DOS require a syntax 
like \dev\con for devices.

-uso.


From cowan at mercury.ccil.org  Sun Feb 26 06:39:59 2012
From: cowan at mercury.ccil.org (John Cowan)
Date: Sat, 25 Feb 2012 15:39:59 -0500
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <4F492C43.3020602@fastmail.us>
References: <201202221917.q1MJHSGw013561@freefriends.org>
	<alpine.BSF.2.00.1202230752140.62608@aneurin.horsfall.org>
	<20120223043021.GA72269@dereel.lemis.com>
	<4F492C43.3020602@fastmail.us>
Message-ID: <20120225203959.GE29866@mercury.ccil.org>

Random832 scripsit:

> For instance, this is, according to Raymond Chen, why they added      
> WinMain rather than extending main (they didn't know if extensions to 
> main would be allowed).                                               

That doesn't sound very reasonable to me.  When you link a Windows
program, it still has a main() procedure provided by Windows which does
setup and then invokes WinMain().

> so it's possible that MSVC's C library was indeed, to some small
> degree, based on Unix.

Without doubt.  After all, there was no other source of C libraries
before ANSI; compare the Whitesmiths library, which was "meticulously
incompatibled".

-- 
Samuel Johnson on playing the violin:           John Cowan
"Difficult do you call it, Sir?                 cowan at ccil.org
 I wish it were impossible."                    http://www.ccil.org/~cowan


From random832 at fastmail.us  Sun Feb 26 08:15:32 2012
From: random832 at fastmail.us (Random832)
Date: Sat, 25 Feb 2012 17:15:32 -0500
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <20120225203959.GE29866@mercury.ccil.org>
References: <201202221917.q1MJHSGw013561@freefriends.org>
	<alpine.BSF.2.00.1202230752140.62608@aneurin.horsfall.org>
	<20120223043021.GA72269@dereel.lemis.com>
	<4F492C43.3020602@fastmail.us>
	<20120225203959.GE29866@mercury.ccil.org>
Message-ID: <4F495D84.8030206@fastmail.us>

I'm going to need to train myself to use the "reply to list" button. 
Though in this case I think part of the problem was duplicate-filtering 
which lost the copy that had the appropriate header.

On 2/25/2012 3:39 PM, John Cowan wrote:
>  Random832 scripsit:
>
>>  For instance, this is, according to Raymond Chen, why they added
>>  WinMain rather than extending main (they didn't know if extensions to
>>  main would be allowed).
>  That doesn't sound very reasonable to me.  When you link a Windows
>  program, it still has a main() procedure provided by Windows which does
>  setup and then invokes WinMain().

This is not true in my experience. If it was ever true, it's not true
today (with MSVC, anyway. GCC may be different, but if there is a
'system-provided main()' it's GCC, or cygwin or mingw, and not anything
from microsoft, that is providing it). The procedure "provided by
windows" (provided by MSVC, actually) that does that is in fact called
WinMainCRTStartup. When you link a windows _console_ program, a
different function (called mainCRTStartup) which does the same setup
(plus opening a console if none is open and setting up stdio which the
WinMain version doesn't) and then invokes main().

The startup function is an interesting read - it has more work to do on
windows than the unix equivalent, because systems like signals (which
are in ANSI), file descriptor based I/O (which is not ANSI but
nevertheless is implemented in MSVC), and such, that are "naturally
occuring" on unix have to be set up. The whole program executes in a
__try/__except block to allow them to make signals work, for example.



From ron at ronnatalie.com  Sun Feb 26 23:28:36 2012
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 26 Feb 2012 08:28:36 -0500
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <4F495D84.8030206@fastmail.us>
References: <201202221917.q1MJHSGw013561@freefriends.org>
	<alpine.BSF.2.00.1202230752140.62608@aneurin.horsfall.org>
	<20120223043021.GA72269@dereel.lemis.com>
	<4F492C43.3020602@fastmail.us>
	<20120225203959.GE29866@mercury.ccil.org>
	<4F495D84.8030206@fastmail.us>
Message-ID: <29D22528-0E74-4465-BA18-BF3DDE1BB674@ronnatalie.com>


On Feb 25, 2012, at 5:15 PM, Random832 wrote:
>> 
> 
> This is not true in my experience. If it was ever true, it's not true
> today (with MSVC, anyway. GCC may be different, but if there is a
> 'system-provided main()' it's GCC, or cygwin or mingw, and not anything
> from microsoft, that is providing it). The procedure "provided by
> windows" (provided by MSVC, actually) that does that is in fact called
> WinMainCRTStartup.

WinMainCRTStartup isn't the replacement for main.   It's the replacement for begin or location zero back in the old days.  (Anybody remember seeing p&P6 printed by errant programs?).   There are different versions of that CRT startup (actually all compiled from the same module with ifdefs) that start:

main - for non-MFC console apps
wmain - same thing but with wchar_t arguments (SOMETHING C/C++ standards hasn't ever addressed to my satisfaction).
WinMain - MFC main function
wWinMain - Ditto, with wchar_t

Actually the bulk of the CRT involves converting between the command line argument as a string and argc/argv (something UNIX does by the OS), and some gook necessary to support C++.

The  fake UNIX environment (POSIX) (read/write/seek, etc...) actually is NOT initialized here, but when it is actually referenced.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20120226/8dc5369c/attachment.html>

From random832 at fastmail.us  Mon Feb 27 11:30:45 2012
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Sun, 26 Feb 2012 20:30:45 -0500
Subject: [TUHS] why the leading under score added to function names?
In-Reply-To: <29D22528-0E74-4465-BA18-BF3DDE1BB674@ronnatalie.com>
References: <201202221917.q1MJHSGw013561@freefriends.org>
	<alpine.BSF.2.00.1202230752140.62608@aneurin.horsfall.org>
	<20120223043021.GA72269@dereel.lemis.com>
	<4F492C43.3020602@fastmail.us>
	<20120225203959.GE29866@mercury.ccil.org>
	<4F495D84.8030206@fastmail.us>
	<29D22528-0E74-4465-BA18-BF3DDE1BB674@ronnatalie.com>
Message-ID: <1330306245.13843.140661041668049@webmail.messagingengine.com>



On Sun, Feb 26, 2012, at 08:28, Ronald Natalie wrote:
> 
> WinMainCRTStartup isn't the replacement for main.

I never said it was. My point was that there is no "main" anywhere in a
program that starts with WinMain, whereas John Cowan claimed that a
"main" exists in such programs which does the things that
WinMainCRTStartup in fact does.

> main - for non-MFC console apps
> wmain - same thing but with wchar_t arguments (SOMETHING C/C++ standards
> hasn't ever addressed to my satisfaction).

I suspect this is partly because the unix world is a multibyte world,
and POSIX has "filenames don't have to be valid in any character set,
they're just bytes".

But Windows never had a satisfactory solution to multibyte vs wide in
pipes, either, anyway.

> WinMain - MFC main function

This existed long before MFC, I suspect.

> wWinMain - Ditto, with wchar_t
> 
> Actually the bulk of the CRT involves converting between the command line
> argument as a string and argc/argv (something UNIX does by the OS), and
> some gook necessary to support C++.

Well, not "by the OS" per se. More like, the OS only supports passing
argc/argv at any level, so the shell converts user-typed strings to
argv.

(A big gripe I have with the CRT is that its _spawn/_exec functions
don't quote strings containing spaces/etc so they can be round-tripped
by the CRT's argv initialization. And the argv code itself doesn't let
you have "wildcards in strings without quotes, literal stars in strings
with them", you have to choose between wildcards or not)

> The  fake UNIX environment (POSIX) (read/write/seek, etc...) actually is
> NOT initialized here, but when it is actually referenced.

mainCRTstartup does in fact call _ioinit() in the version I looked at. I
don't recall if WinMainCRTstartup does or not, it's not in front of me
now.
-- 
Random832



