27 Apr
2019
27 Apr
'19
2:16 p.m.
From at least V2 to V6, the ls(1) command would not
show directory entries whose names began with a '.'
unless the -a flag was supplied.
This was changed in V7: only the directory entries
for "." and ".." would be skipped by default.
All further versions of Research Unix retain the
convention of V7 and Plan 9 ultimately made it
unnecessary. However, BSD and its descendants did
not follow suit. Instead, they continued behaving
like V6 with an additional -A flag to emulate V7.
Was the initial behavior intentional or just a
matter of expediency?
Who made the change and what was their motivation?
Was it a reaction to the intentional hiding of what
came to be known as "dot files"?
Thanks,
Anthony
27 Apr
27 Apr
3:38 p.m.
On Sat, Apr 27, 2019 at 8:26 AM Anthony Martin <ality(a)pbrane.org> wrote:
From at least V2 to V6, the ls(1) command would not
show directory entries whose names began with a '.'
unless the -a flag was supplied.
This was changed in V7: only the directory entries
for "." and ".." would be skipped by default.
gnu ls does not follow this convention. The system V sources one can find
on the internet have the curious code:
#define DOTSUP 1
...
if (aflg==0 && dentry->d_name[0]=='.'
# ifndef DOTSUP
&& (dentry->d_name[1]=='\0' ||
dentry->d_name[1]=='.'
&& dentry->d_name[2]=='\0')
# endif
) /* check for directory items '.',
'..',
* and items without valid inode-number;
*/
continue;
which is the V7 behavior ifdef'd out.
All further versions of Research Unix retain the
convention of V7 and Plan 9 ultimately made it
unnecessary. However, BSD and its descendants did
not follow suit. Instead, they continued behaving
like V6 with an additional -A flag to emulate V7.
This has been the BSD convention since at least 4BSD :)
But I find this interesting, since the 8th edition was based on BSD 4.1c I
thought....
And system III and later all have the above code.
Was the initial behavior intentional or just a
matter of expediency?
Who made the change and what was their motivation?
Was it a reaction to the intentional hiding of what
came to be known as "dot files"?
It looks like, from the source, to be a blip in V7.
Warner
28 Apr
28 Apr
11:59 p.m.
On Sat, Apr 27, 2019 at 9:38 AM Warner Losh <imp(a)bsdimp.com> wrote:
On Sat, Apr 27, 2019 at 8:26 AM Anthony Martin <ality(a)pbrane.org> wrote:
I've confirmed that all the ls.c's that I have from AT&T, apart from
research, do the . is a hidden file thing in ls. All the research things
inherit the V7 behavior (though the V8 sources I found have an
off-by-default ifdef for the BSD behavior). All descendants of SysV that I
could find source to have the V6 behavior, not V7. Both system III and all
revs of System V I could find have an #ifdef for this, and a 1 line change
restore the V7 behavior. Illumos has the BSD semantics and has lost even
the ifdef.
As pointed out later in the thread I was incorrect about 'base on 4.1BSD. I
took a closer look at the sources we have. The kernel has various bits of
BSD included in it starting in V8, but as noted the networking bits seem
odd to my eye. I didn't do a detailed analysis beyond spot checking a few
files. The userland looks more like evolved V7 code with some BSDism
imported rather than a wholesale switch to the BSD versions.
I like the dot is hidden thing. It's simple, elegant, and transports to
other systems well, so long as they are unix or have filesystems that don't
get hung up on 'extension'. That latter bit is likely why many find it...
distasteful.
Warner
From at least V2 to V6, the ls(1) command would
not
show directory entries whose names began with a '.'
unless the -a flag was supplied.
This was changed in V7: only the directory entries
for "." and ".." would be skipped by default.
gnu ls does not follow this convention. The system V sources one can find
on the internet have the curious code:
#define DOTSUP 1
...
if (aflg==0 && dentry->d_name[0]=='.'
# ifndef DOTSUP
&& (dentry->d_name[1]=='\0' ||
dentry->d_name[1]=='.'
&& dentry->d_name[2]=='\0')
# endif
) /* check for directory items '.',
'..',
* and items without valid inode-number;
*/
continue;
which is the V7 behavior ifdef'd out.
11:47 a.m.
On Sat, Apr 27, 2019 at 10:26 AM Anthony Martin <ality(a)pbrane.org> wrote:
From at least V2 to V6, the ls(1) command would not
show directory entries whose names began with a '.'
unless the -a flag was supplied.
This was changed in V7: only the directory entries
for "." and ".." would be skipped by default.
All further versions of Research Unix retain the
convention of V7 and Plan 9 ultimately made it
unnecessary. However, BSD and its descendants did
not follow suit. Instead, they continued behaving
like V6 with an additional -A flag to emulate V7.
Was the initial behavior intentional or just a
matter of expediency?
I believe it's been publicly stated that it was a mistake in early Unix.
Apparently, Rob Pike had a Google+ post to this effect back in 2012 (or
earlier): I see a reference to it from another mailing list around that
time. Unfortunately, the Google+ content is now lost. Rob, do you have a
copy?
Who made the change and what was their motivation?
Was it a reaction to the intentional hiding of what
came to be known as "dot files"?
Speaking from memory, I think the intent was to avoid showing '.' and
'..',
and that a programming error accidentally hid all dotfiles; probably this
went unnoticed because there just weren't many of them at the time. This
was corrected in 7th Edition, but the existing behavior had already escaped
into the world via Berkeley.
I suspect the "dot file" convention came later, as a side-effect of
observed behavior of ls.
- Dan C.
2:44 p.m.
Dan Cross <crossd(a)gmail.com> writes:
Here's a tweet that shows the post:
https://twitter.com/rauchg/status/698689290667053060/photo/1?ref_src=twsrc%…
On Sat, Apr 27, 2019 at 10:26 AM Anthony Martin
<ality(a)pbrane.org> wrote:
> From at least V2 to V6, the ls(1) command would not
> show directory entries whose names began with a '.'
> unless the -a flag was supplied.
[snip]
Was the
initial behavior intentional or just a
matter of expediency?
I believe it's been publicly stated that it was a mistake in
early Unix.
Apparently, Rob Pike had a Google+ post to this effect back in
2012 (or
earlier): I see a reference to it from another mailing list
around that
time. Unfortunately, the Google+ content is now lost. Rob, do
you have a
copy? 
4:15 p.m.
On Apr 28, 2019, at 4:47 AM, Dan Cross <crossd(a)gmail.com> wrote:
I suspect the "dot file" convention came later, as a side-effect of observed
behavior of ls.
This could’ve been avoided if there was a convention about
where to store per user per app settings & possibly state. On
one of my Unix machines I have over 200 dotfiles.
1825
days inactive
1826
days old
7 comments
7 participants
participants (7)
-
Anthony Martin -
arnold＠skeeve.com -
Bakul Shah -
Dan Cross -
jcs -
Larry McVoy -
Warner Losh