From mboxrd@z Thu Jan 1 00:00:00 1970 From: pepe@naleco.com (Josh Good) Date: Sat, 25 Mar 2017 00:55:58 +0100 Subject: [TUHS] Were all of you.. Hippies? In-Reply-To: References: <009301d2a1c9$cb604c70$6220e550$@ronnatalie.com> <20170321202839.GG21805@naleco.com> <20170324001832.GA13511@naleco.com> <20170324002754.GW23802@mcvoy.com> <1490332489.2836059.921835720.2069930C@webmail.messagingengine.com> Message-ID: <20170324235556.GA29323@naleco.com> On 2017 Mar 24, 07:23, shawn wilson wrote: > On Fri, Mar 24, 2017, 01:15 Random832 wrote: > > > On Thu, Mar 23, 2017, at 21:03, ron minnich wrote: > > > In Unix, resources have names. They are visible in a name space, > > > organized > > > into directories. The names can be enumerated by opening and reading a > > > directory. Information about them can be determined with stat. Their > > > contents can be read by open and read. They can be changed with open and > > > write. > > > > And if each resource has a directory (possibly organized in a > > multiple-level hierarchy) containing several files that describe > > attributes of that resource, what are you to do when you want to print a > > report listing a summary of some information about those resources, one > > per line? > > > > In bash - > which read -a foo; do echo <(cmd ${foo[0]}); > done #...? :) Yeah, because "lspci" was not hard enough to type. Also, in Unix resources have a name when the kernel has a driver to be able to know about those resources. But "lspci" can list also hardware for which the kernel knows no driver (not a typical need in "pure UNIX" running on a PDP-11 or PDP-8, I guess). "lspci" is akin to "fdisk -l", for when you need to know what is laying under the running kernel, at a level lower than the kernel abstractions for the hardware which it knows about (i.e, hardware for which it has a driver). Which brings up a question I have: why didn't UNIX implement ethernet network interfaces as file names in the filesystem? Was that "novelty" a BDS development straying away from AT&T UNIX? -- Josh Good