Include path question

[CBFalconer]

Re: Include path question

Richard Heathfield wrote:

Malcolm said:
>

.... snip ...

>>
>There are plenty of computer systems without directories, but
>compilers don't run on them.

>
MVS and VM/CMS are counter-examples. Undoubtedly there are others
as well, but those will suffice. Both are platforms for which ISO
C implementations exist, and neither has the concept of "directory" .

Another one, easily available to most, is CP/M-80. An easily
available simulator for many systems is at:

<http://www.schorn.ch/cpm/intro.html>

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[Barry Schwarz]

Re: Include path question

On Sun, 29 Oct 2006 00:27:38 +0000 (UTC), roberson@ibd.nr c-cnrc.gc.ca
(Walter Roberson) wrote:

>In article <c8o7k2t5kie6f0 9tdk57jdp5leb3u fr60c@4ax.com>,
>Barry Schwarz <schwarzb@doezl .netwrote:

>>On Sat, 28 Oct 2006 23:27:21 +0100, "Malcolm"
>><regniztar@bt internet.comwro te:

>

>>>I would say a directory is a group of files which does not include all that
>>>are physically readable by the system.
>>>I don't know of a system with a compiler that doesn't have directories.

>

>>the real world is not bound by the limitations of your knowledge. The
>>IBM MVS operating system, currently marketed under the name z/OS does
>>not have directories.

>
>My recollection from <mumbleyears ago is that it has logical disks
>(not the right term, I know) that are often internally defined as
>cylinder groups on physical disks, and that the logical disks can
>be associated with a letter, and that a file designation by a user
>is by a two part name (the second part of which may be associated
>by tradition with a particular file "type") followed by the letter...
>e.g., HELLO TEXT Z designating file HELLO TEXT on the cylinder group
>currently associated with the letter Z.
>
>Once a letter was associated with a cylinder group, the user could
>request a listing of contents, with at least some level of wildcarding.
>
>If the above is still the situation in z/OS then I would say that
>z/OS -does- have directories within the definition given by Malcolm --
>a grouping of files that does not include all that are physically
>readable on the system. There might not be any master directory,
>and other than drive A you might have to peak through people's
>PROFILE to figure their default file set... and you'd miss all the dynamic
>associations.. .

Sorry but MVS has never had an association between a "logical disk"
and a letter. IBM has several different operation systems and a
different one may have something similar to what you describe.


Remove del for email

[Leor Zolman]

Re: Include path question


Gordon Burditt wrote:

The concept of tree-structured directories didnt get popular until Unix
V6 and MSDOS 2.0 came out.
>

I would say a directory is a group of files which does not include all that
are physically readable by the system.
I don't know of a system with a compiler that doesn't have directories.

>
CP/M 2.0 would qualify as not having directories, with the BDS C
Compiler. It wasn't ANSI C compliant (what was in the late 1970's?
Although this one didn't support floating point, at least the early
versions didn't). Unless you decided that each floppy had its
own directory and that constituted directory support, it didn't
support directories.
>

Can't recall if they were there in CP/M 2.0 or were only introduced for
2.2, but there were "user areas" that subdivided a logical drive into,
I believe it was, 16 numbered sub-areas. For the capacities of the day
(I paid $3,600 for a 10mb 8" Morrow hard disk drive circa 1980...), 16
subdirectories were plenty...
-leor

[Jan Engelhardt]

Re: Include path question

>

>I've collected the behaviour of some C and C++ compilers on
>http://www.bourguet.org/cpp/include.html
>If you know other behaviours, I'm interested to add them.

GCC should be put into the list where Visual C is listed, because that
is what I observed (#include "" in the directory of the file containing
the directive).

Have you tried SUNWspro yet?

-`J'
--

[Gordon Burditt]

Re: Include path question

>The concept of tree-structured directories didnt get popular until Unix

>V6 and MSDOS 2.0 came out.
>>
>I would say a directory is a group of files which does not include all that
>are physically readable by the system.
>I don't know of a system with a compiler that doesn't have directories.

>>
>CP/M 2.0 would qualify as not having directories, with the BDS C
>Compiler. It wasn't ANSI C compliant (what was in the late 1970's?
>Although this one didn't support floating point, at least the early
>versions didn't). Unless you decided that each floppy had its
>own directory and that constituted directory support, it didn't
>support directories.
>>

>
>Can't recall if they were there in CP/M 2.0 or were only introduced for
>2.2, but there were "user areas" that subdivided a logical drive into,
>I believe it was, 16 numbered sub-areas.

I'm reasonably sure they weren't present in CP/M 2.0, which is why
I said CP/M 2.0. The "sub-areas" didn't increase the number of
files you could fit on a floppy. "user 0" was special. A "user
0" file appeared in all "sub-areas", and a program running as "user
0" saw only "user 0" files.

And perhaps most important, there was no standardized way of
specifying "the config.h file in user area 5" by some kind of path
name. CP/M didn't provide a way of translating a text "path name"
into a FCB, so although it was possible to invent a syntax for such
a "path name", every application that wanted to use such a thing
had to be aware of the syntax or use a library that was, and it
wouldn't work for applications written before that feature was
introduced.

>For the capacities of the day
>(I paid $3,600 for a 10mb 8" Morrow hard disk drive circa 1980...), 16
>subdirectori es were plenty...
-leor

[Leor Zolman]

Re: Include path question


Gordon Burditt wrote:

Can't recall if they were there in CP/M 2.0 or were only introduced for
2.2, but there were "user areas" that subdivided a logical drive into,
I believe it was, 16 numbered sub-areas.

>
I'm reasonably sure they weren't present in CP/M 2.0, which is why
I said CP/M 2.0. The "sub-areas" didn't increase the number of
files you could fit on a floppy. "user 0" was special. A "user
0" file appeared in all "sub-areas", and a program running as "user
0" saw only "user 0" files.
>
And perhaps most important, there was no standardized way of
specifying "the config.h file in user area 5" by some kind of path
name. CP/M didn't provide a way of translating a text "path name"
into a FCB, so although it was possible to invent a syntax for such
a "path name", every application that wanted to use such a thing
had to be aware of the syntax or use a library that was, and it
wouldn't work for applications written before that feature was
introduced.
>

Well, I did add user-area prefix recognition to the BDS C filename
syntax when user areas came out... so at least there was a "standard"
way of doing it under *that* platform...
-leor

[CBFalconer]

Re: Include path question

Gordon Burditt wrote:

>

.... snip ...

>
And perhaps most important, there was no standardized way of
specifying "the config.h file in user area 5" by some kind of path
name. CP/M didn't provide a way of translating a text "path name"
into a FCB, so although it was possible to invent a syntax for such
a "path name", every application that wanted to use such a thing
had to be aware of the syntax or use a library that was, and it
wouldn't work for applications written before that feature was
introduced.

You obviously never used either ZCPR or my DOS+ system. Both had
DU addressing, whereby the file location could be described as
"B8:filename.ty p", for example. My CCP+ (not sure about ZCPR) had
paths for executables, and (memory hazy) possibly for data.
CP/M2.2 documentation claimed that any user could execute programs
with the sys attribute in user area 0, but it didn't do it. DOS+
did. Together with the executables path, and the extension to
loading executables from COMMAND.LBR, this allowed much to be
packed into a small space and fairly good control of user
capabilities.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[Gordon Burditt]

Re: Include path question

>And perhaps most important, there was no standardized way of

>specifying "the config.h file in user area 5" by some kind of path
>name. CP/M didn't provide a way of translating a text "path name"
>into a FCB, so although it was possible to invent a syntax for such
>a "path name", every application that wanted to use such a thing
>had to be aware of the syntax or use a library that was, and it
>wouldn't work for applications written before that feature was
>introduced.

>
>You obviously never used either ZCPR or my DOS+ system. Both had
>DU addressing, whereby the file location could be described as
>"B8:filename.t yp", for example. My CCP+ (not sure about ZCPR) had
>paths for executables, and (memory hazy) possibly for data.

That's great, now if only it could have been made to work for stuff
like the standard text editor, so you don't have the situation that
B8:filename.typ works on your system, fails with an error on some
other programs, or worse, since error-checking was never a strong
point of CP/M programs, quietly use B:filename.typ in the current
user area instead, or something else. There's a lot to be said for
consistency.

I remember seeing *at least*:
<drive><user>:f ilename.typ
<drive>:filenam e.typ;<user>
<drive>:filenam e.typ.<user>

and the user number wasn't always in decimal.

>CP/M2.2 documentation claimed that any user could execute programs
>with the sys attribute in user area 0, but it didn't do it. DOS+
>did. Together with the executables path, and the extension to
>loading executables from COMMAND.LBR, this allowed much to be
>packed into a small space and fairly good control of user
>capabilities .

[Walter Roberson]

Re: Include path question

In article <jpl9k2pg1imkna r2jkkn07iqqu7fh uese7@4ax.com>,
Barry Schwarz <schwarzb@doezl .netwrote:

>Sorry but MVS has never had an association between a "logical disk"
>and a letter. IBM has several different operation systems and a
>different one may have something similar to what you describe.

Rechecking, it appears I was referring to CMS.

I very briefly investigated MVS last night; found a bunch of
unrelated T-shirt importation places, and lots of repetitions of
sites that didn't say anything much useful. I did find that
MVS's component specifiers are a convention rather than an
actual grouping.

What I was not able to determine within a reasonable time, though,
was exactly what an MVS catalog is. I could see that there was more
than one, including a critical "master catalog", and I could see
a few utilities such as LISTCAT that would list the catalog given
a project code.

It -appeared-, with the little hard data that I could find, that an MVS
catalog was arguably a "directory" within the meaning given by an
earlier poster. I did see a hint that catalogs did not really
organize the storage, and instead merely provided more convenient
ways to go between readable names and internal dataset serial numbers,
but if that is the case then it could be argued that a catalog entry
was akin to a traditional Unix directory entry, which merely associates
a name and an inode number with all the real action happening
at the inode level. None of this was really very clear in what I found.
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer

[Jalapeno]

Re: Include path question

Walter Roberson wrote:

>
What I was not able to determine within a reasonable time, though,
was exactly what an MVS catalog is. I could see that there was more
than one, including a critical "master catalog", and I could see
a few utilities such as LISTCAT that would list the catalog given
a project code.
>
It -appeared-, with the little hard data that I could find, that an MVS
catalog was arguably a "directory" within the meaning given by an
earlier poster.

Not from an application programming perspective. You are barking up the
wrong tree if you are trying to find "directorie s" in MVS.

(hint #1: look up HFS).

(hint #2: http://www.redbooks.ibm.com/redbooks/SG245482.html read the
first paragraph of section 1.1 HFS Overview)

[Jalapeno]

Re: Include path question


Barry Schwarz wrote:

>
the real world is not bound by the limitations of your knowledge. The
IBM MVS operating system, currently marketed under the name z/OS does
not have directories.

While true, you can, however, create HFS data sets that are organized
with a tree-like structure using directories via USS (Unix Systems
Services). From a C program, luckily, your file structure (whether it
is PDS, Physical Sequential, or VSAM or whatever) looks like a stream
and the details aren't necessary. If you are writing a program that
_needs_ to know these details then, it's off-topic here :o) (I am
pretty sure you know all this Barry. Sometimes MVS people forget about
USS in MVS.)

[Dave Thompson]

Re: Include path question

On 28 Oct 2006 15:20:20 -0700, "Ancient_Hacker " <grg2@comcast.n et>
wrote:
<snip>

Well I agree that 99.9% of computers out there have OS's with the
concept of "directorie s". By which you probably mean the ability to
create multiple, named directories. And without the intervention of
the system operator.
>
But there have been plenty of OS's without that concept. Even OS's for
$12M computers. Most OS's before 1970 or so <snip>
The concept of tree-structured directories didnt get popular until Unix
V6 and MSDOS 2.0 came out.

MULTICS was definitely several years earlier; TOPS-20 was TTBOMR about
concurrent with first Unix, and TENEX several years earlier.

OS/360 had hierarchically organized _names_, stored centrally in a
system catalog not in separate directories, by the mid '60s. And it
was more widely used and known/taught than the others combined.

But if you mean 'popular' in the sense of used (directly) by large
numbers of people, that would indeed be MSDOS; those others ran on
systems an ordinary person couldn't afford.

But to Walter Roberson downthread, the S/370 et seq system with
"logical disk" with 1letter* 8char-filename 8char-filetype is _CMS_
(run under VM) NOT MVS or any other flavor of OS/* now z/OS.
(* Technically IIRC 1letter disk and optional 1digit mode, but the
latter is rarely needed or used.)

And although it's a debatable point of terminology, I would say that
any centralized metadata mapping names to storage (regions) is a
directory, including CMS, RT-11, and early CP/M or MSDOS; where
necessary I would call this a "one-level" or "fixed" directory in
contrast to "hierarchic al" and/or "user-defined" directories. For a
truly nondirectory structure I would point to IBM partitioned data
sets (PDS); Unix (originally) "ar" and "tar" archives; and the alltime
classic, labelled magtapes. Note not ZIP; it has metadata both
distributed AND centralized, and so counts as directoried.

- David.Thompson1 at worldnet.att.ne t