By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,933 Members | 1,243 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,933 IT Pros & Developers. It's quick & easy.

Include path question

P: n/a
Hello,
assume foo/bar.h exists, and is included as '#include "bar.h"' in
foo/bar.c. `gcc -c foo/bar.c` will compile it fine (i.e. finds the
file). Is this a gcc extension or a C compiler standard feature that
foo/ will be searched without explicitly passing -Ifoo?

$ cat foo/bar.h
#define GOAL 1

$ cat foo/bar.c
#include <stdio.h>
#include "bar.h"
int main(void) {
printf("%d\n", GOAL);
return 0;
}

-`J'
--
Oct 28 '06 #1
Share this Question
Share on Google+
26 Replies


P: n/a
Jan Engelhardt said:
Hello,
assume foo/bar.h exists, and is included as '#include "bar.h"' in
foo/bar.c. `gcc -c foo/bar.c` will compile it fine (i.e. finds the
file). Is this a gcc extension or a C compiler standard feature that
foo/ will be searched without explicitly passing -Ifoo?
The Standard does not specify the details of interfacing with an
implementation.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 28 '06 #2

P: n/a

"Jan Engelhardt" <je*****@linux01.gwdg.dewrote in message
news:Pi******************************@yvahk01.tjqt .qr...
Hello,
assume foo/bar.h exists, and is included as '#include "bar.h"' in
foo/bar.c. `gcc -c foo/bar.c` will compile it fine (i.e. finds the
file). Is this a gcc extension or a C compiler standard feature that
foo/ will be searched without explicitly passing -Ifoo?

$ cat foo/bar.h
#define GOAL 1

$ cat foo/bar.c
#include <stdio.h>
#include "bar.h"
int main(void) {
printf("%d\n", GOAL);
return 0;
}

-`J'
--
As a general rule if you include .h files in the same directory as the
associated .c file, they can be include with a simple quoted name.
All compilers have options for specifying default directories to search for
includes, and conventions vary.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Oct 28 '06 #3

P: n/a
Malcolm said:

<snip>
All compilers have options for specifying default directories to search
for includes,
Some systems don't support the concept of "directory". Compilers on such
systems do not have options for specifying default directories to search
for "includes" (i.e. headers), since headers on such systems are not stored
in directories.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 28 '06 #4

P: n/a
"Richard Heathfield" <in*****@invalid.invalidwrote in message
Malcolm said:

<snip>
>All compilers have options for specifying default directories to search
for includes,

Some systems don't support the concept of "directory". Compilers on such
systems do not have options for specifying default directories to search
for "includes" (i.e. headers), since headers on such systems are not
stored
in directories.
There are plenty of computer systems without directories, but compilers
don't run on them. The compiler gets so angry at not having a directory to
sit in that it leaves and goes to another machine.
In other words, it becomes a cross compiler.

Some systems call directories "folders" for some impenetrable reason. Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

Oct 28 '06 #5

P: n/a

"Malcolm" <re*******@btinternet.comwrote in message
news:pK******************************@bt.com...
"Richard Heathfield" <in*****@invalid.invalidwrote in message
Malcolm said:

<snip>
All compilers have options for specifying default directories to search
for includes,
Some systems don't support the concept of "directory". Compilers on such
systems do not have options for specifying default directories to search
for "includes" (i.e. headers), since headers on such systems are not
stored
in directories.
There are plenty of computer systems without directories, but compilers
don't run on them. The compiler gets so angry at not having a directory
to
sit in that it leaves and goes to another machine.
In other words, it becomes a cross compiler.

Some systems call directories "folders" for some impenetrable reason. Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Wow, I compiled a lot of programs in several languages, naturally C being
one
of them, on an OS that had not concept of directories or folders. And I
assure
you it was not an obscure OS. LOL.
Oct 28 '06 #6

P: n/a

Malcolm wrote:

Some systems call directories "folders" for some impenetrable reason. Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".

Well I agree that 99.9% of computers out there have OS's with the
concept of "directories". 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 had either just one
directory for the whole system, or one system directory and one
directory per user, or one directory per physical volume, or
directories had to be created by system staff.

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

Oct 28 '06 #7

P: n/a
"Ancient_Hacker" <gr**@comcast.netwrote in message
>
Malcolm wrote:

>Some systems call directories "folders" for some impenetrable reason.
Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".


Well I agree that 99.9% of computers out there have OS's with the
concept of "directories". 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 had either just one
directory for the whole system, or one system directory and one
directory per user, or one directory per physical volume, or
directories had to be created by system staff.

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.
However plenty of embedded systems don't have directories, even though they
may ahve backing store. Everything can be completely flat.

--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Oct 28 '06 #8

P: n/a
>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.
>However plenty of embedded systems don't have directories, even though they
may ahve backing store. Everything can be completely flat.
Oct 28 '06 #9

P: n/a
On Sat, 28 Oct 2006 23:27:21 +0100, "Malcolm"
<re*******@btinternet.comwrote:
>"Ancient_Hacker" <gr**@comcast.netwrote in message
>>
Malcolm wrote:

>>Some systems call directories "folders" for some impenetrable reason.
Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".
And others have neither.
>>

Well I agree that 99.9% of computers out there have OS's with the
concept of "directories". 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 had either just one
directory for the whole system, or one system directory and one
directory per user, or one directory per physical volume, or
directories had to be created by system staff.

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.
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. And it doesn't use a cross compiler. It very
nicely generates native machine code for the S/370, S/390, Z8xx, and
Z9xx families of processors, the same hardware it executes on.
>However plenty of embedded systems don't have directories, even though they
may ahve backing store. Everything can be completely flat.

Remove del for email
Oct 28 '06 #10

P: n/a
In article <c8********************************@4ax.com>,
Barry Schwarz <sc******@doezl.netwrote:
>On Sat, 28 Oct 2006 23:27:21 +0100, "Malcolm"
<re*******@btinternet.comwrote:
>>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...
And it doesn't use a cross compiler. It very
>nicely generates native machine code for the S/370, S/390, Z8xx, and
Z9xx families of processors, the same hardware it executes on.
>>However plenty of embedded systems don't have directories, even though they
may ahve backing store. Everything can be completely flat.


Remove del for email

--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)
Oct 29 '06 #11

P: n/a
In article <12*************@corp.supernews.com>,
Barry <ba****@nullhighstream.netwrote:
....
>Wow, I compiled a lot of programs in several languages, naturally C
being one of them, on an OS that had not concept of directories or
folders. And I assure you it was not an obscure OS. LOL.
MSDOS 1.0?

Oct 29 '06 #12

P: n/a
In article <zY******************************@bt.com>,
Malcolm <re*******@btinternet.comwrote:
....
>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. However plenty of
embedded systems don't have directories, even though they may ahve
backing store. Everything can be completely flat.
The point is that none of that matters. The C standard doesn't require
it, so, as far as the troglodytes in this ng are concerned, it doesn't
exist.
Oct 29 '06 #13

P: n/a
Malcolm said:
"Richard Heathfield" <in*****@invalid.invalidwrote in message
>Malcolm said:

<snip>
>>All compilers have options for specifying default directories to search
for includes,

Some systems don't support the concept of "directory". Compilers on such
systems do not have options for specifying default directories to search
for "includes" (i.e. headers), since headers on such systems are not
stored
in directories.
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".

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Oct 29 '06 #14

P: n/a
Jan Engelhardt <je*****@linux01.gwdg.dewrites:
Hello,
assume foo/bar.h exists, and is included as '#include "bar.h"' in
foo/bar.c. `gcc -c foo/bar.c` will compile it fine (i.e. finds the
file). Is this a gcc extension or a C compiler standard feature that
foo/ will be searched without explicitly passing -Ifoo?

$ cat foo/bar.h
#define GOAL 1

$ cat foo/bar.c
#include <stdio.h>
#include "bar.h"
int main(void) {
printf("%d\n", GOAL);
return 0;
}
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.

Yours,

--
Jean-Marc
Oct 29 '06 #15

P: n/a
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>
Oct 29 '06 #16

P: n/a
On Sun, 29 Oct 2006 00:27:38 +0000 (UTC), ro******@ibd.nrc-cnrc.gc.ca
(Walter Roberson) wrote:
>In article <c8********************************@4ax.com>,
Barry Schwarz <sc******@doezl.netwrote:
>>On Sat, 28 Oct 2006 23:27:21 +0100, "Malcolm"
<re*******@btinternet.comwrote:
>>>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
Oct 29 '06 #17

P: n/a

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

Oct 29 '06 #18

P: n/a
>
>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'
--
Oct 29 '06 #19

P: n/a
>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
subdirectories were plenty...
-leor
Oct 29 '06 #20

P: n/a

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

Oct 29 '06 #21

P: n/a
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.typ", 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>
Oct 29 '06 #22

P: n/a
>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.typ", 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>:filename.typ
<drive>:filename.typ;<user>
<drive>:filename.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.
Oct 30 '06 #23

P: n/a
In article <jp********************************@4ax.com>,
Barry Schwarz <sc******@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
Oct 30 '06 #24

P: n/a
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 "directories" 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)

Oct 30 '06 #25

P: n/a

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.)

Oct 30 '06 #26

P: n/a
On 28 Oct 2006 15:20:20 -0700, "Ancient_Hacker" <gr**@comcast.net>
wrote:
<snip>
Well I agree that 99.9% of computers out there have OS's with the
concept of "directories". 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 "hierarchical" 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.net
Nov 20 '06 #27

This discussion thread is closed

Replies have been disabled for this discussion.