>|> The last character of the mode (normally x or `-') is t if
>|> the 1000 bit of the mode is on.
>After a bit of experimenting I must say that this doesn't appear to be
>true when a directory has the sticky bit set.
After a trivial amount of "ls"ing I must say that it *does* appear to be
true when a directory has the sticky bit set, at least under SunOS 4.1.1
(and probably under most if not all SunOS 4.x releases):
auspex% ls -ld /tmp
drwxrwsrwt 3 bin 3072 Jun 29 11:56 /tmp
("/tmp" being a standard "sticky" directory in many flavors of UNIX,
including SunOS 4.1[.x]).
The original poster said he was running "Athena UNIX on SPARCs" (or an
differently-cased version of same :-)); dunno whether that means SunOS
4.x with various Project Athenaisms on top of it, or a port of, say, BSD
to the SPARC-based machines in question.
>|> Hence the "s" means nothing and the "S" means that only you (and a
>|> super-user) may delete files from that directory. In both cases as
>|> no-one else has write permission this effectively means nothing as well.
>It would thus appear that both "s" and "S" mean that a directory is
Nope. "s" means that the the appropriate set-ID and execute-permission
bits are both set; "S" means that the appropriate set-ID bit is set, but
the execute-permission bit *isn't* set.
The set-UID bit on directories means nothing in SunOS 4.x (and probably
in most if not all other flavors of UNIX, either).
The set-GID bit on directories means "use BSD semantics for setting the
group of newly-created files in this directory" in SunOS 4.x (and, I
think, SVR4, and maybe some other flavors of UNIX).
Neither of them make directories "sticky" in any flavor of UNIX with
which I'm familiar; the "sticky bit" (1000 bit) is used for that in all
flavors of UNIX I know of with that notion (4.3BSD and later,
SVR3.<whatever> and later, and systems that picked it up from there,
such as SunOS 4.x and 5.x).