In another thread I was cockily saying that any program [which is not part of the OS user interface, like a shell] with names like exit, test or help is stupid. I meant to imply that such common names should be reserved to the top level user interface, usually a command shell or core OS utility.

User schily remarked that help is a command of the sccs version control system which has been an integral part of Unix since the 70s. sccs is in fact included in the Single Unix Specification.

The online documentation of sccs seems ambiguous. Most pages list help as an sccs subcommand, invoked as sccs help <topic>. Then there is a /usr/bin/sccshelp command. But another page indeed lists a dedicated /usr/ccs/bin/help.

I assume that for sccs users /usr/ccs/bin/ would be in the path so that help has been part of many Unix installations for 40 years¹. In that case I would argue that even though the choice of command name is regrettable sccs would have seniority and bash should have called its built-in bash-help or the like.

So is it or was it common to have an (sccs) help command in your path?

The past did not work that way.

You are buying into a somewhat flawed modern model that wasn't the case at the time.

But I smiled and said, “No sweat, I'll train you. The first command you learn is HELP” and proceeded to type it in on the console terminal. So the data center manager, the shift supervisor and the eight day operators watched the LA100 buzz out the usual introductory text. When it finished they turned to me with expectant faces and I said in an avuncular manner, “This is your most important command!”

The shift supervisor stepped forward and studied the text for about a minute. He then turned with a very puzzled expression on his face and asked, “What do you use it for?” Sigh.

Rather famously, Unix didn't not come with a simple help command for beginners. This was a hole (much discussed on on-line discussion fora) that was filled not just once, by the writers of the Bourne Again shell, but several times over. Mortice-Kern provided a help command that would search for doco to print from a helpfile using a helpindex. AT&T System 5 Release 3.2 had a help command, too, for example:

$ help
help:UNIX System On-line Help

 Choices description 
 s starter: general information
 l locate:find a command with keyword
 u usage: information about command 
 g glossary: definition of terms 
 r redirect to a file or a command 
 q Quit
 Enter choice

That this was in AT&T Unix rather puts the kibosh on the idea that superseding an SCCS command named help is illegitimate or that the writers of the Bourne Again shell were out of step. But there's more.

We were expected to actually use PATH.

# PATH sets the initial shell PATH variable
#
#PATH=/usr/bin:/etc:/bin:/boot/grub:/boot/grup/bin:/boot/solaris/bin:/sbin:
/usr/openwin/bin:/usr/5bin://usr/X11/bin:/usr/apache/bin:/usr/apache2/bin:
/usr/appserver/bin:/usr/ccs/bin:/usr/dt/bin:/usr/j2se/bin:usr/local/bin:
/usr/oasys/bin:/usr/pgadmin3/bin:/usr/proc/bin:/usr/sadm/bin:
/usr/sadm/admin/bin:/usr/sadm/sysadm/bin:/usr/sbin:/usr/sfw/bin:
/usr/sfw/i386-sun-solaris2.10/bin:/usr/sfw/sbin:/usr/snadm/bin:
/usr/sunvts/bin:/usr/ucb:/usr/ucb:/usr/vmsys/bin:/usr/xpg4/bin:
/usr/xpg6/bin

One part of the modern model is that everything goes into one giant directory, be it Daniel J. Bernstein's /command or Arch Linux's /usr/bin. This of course causes all of the headaches with different commands named fastboot (which in other models would be distinguished by being in bin/ and sbin/). But that wasn't the model then.

The model then is exemplified by the multiple variants of the ls command that I discussed and by questions such as "Nexenta bash script uses /usr/sun/bin/sed instead of /usr/bin/sed". There are a whole load of command directories, and what subset of them one chooses to have listed in the value of the PATH environment variable, and in what order, determines the personality of the operating system that one sees.

The command search path could, and to an extent still can, include things such as:

• 
  /bin and /usr/bin/ — the traditional, pre-dating formal standardization, general toolsets; from a post-formal-standardization viewpoint, commands that conform to the System V Interface Definition and the X/Open Portability Guide version 3


• 
  /sbin and /usr/sbin/ — system administration tools


• 
  /etc/ and /usr/etc/ — more system administration tools (Yes Virginia, executables once went in /etc/.)


• 
  /5bin and /usr/5bin/ — System V (i.e. 5) compatibility directory with AT&T Unix System 5 compatible tools


• 
  /usr/ucb/ — UCB (i.e. BSD) compatibility directory with BSD-compatible tools


• 
  /usr/mbin/ — multi-byte character set capable variants of /usr/bin tools


• 
  /usr/rbin/ — tools made available by an administrator to some "restricted" shells


• 
  /usr/lbin/ — locally-installed tools, a precursor of /usr/local/bin/
  


• 
  /usr/amdahl/bin/ and /usr/sun/bin/ — operating system vendor tools, more generally taking the form of /usr/$OEM/bin and from which a parallel can be drawn to /usr/local/bin
  


• 
  /usr/games/ — games


• 
  /usr/ccs/bin — various developer tools, as you have observed


• 
  /usr/xpg4/bin/ — the directory with commands that behave in the ways dictated by the X/Open Portability Guide issue 4


• 
  /usr/xpg6/bin/ — the directory with commands that behave in the ways dictated by the notional X/Open Portability Guide issue 6, more properly known as POSIX.1:2001 or the Single Unix Specification version 3


• 
  /opt/sfw/bin/ — created by installing a CD of additional utilities from Sun, now known as the SunFreeware Companion CD
  


• 
  /opt/csw/bin/ — OpenCSW and Blastwave tools


• 
  /opt/SUNWspro/bin/ — commands from the Sun Workshop (now known as Oracle Developer Studio) tool suite, SUNW being Sun's (original) stock exchange ticker code and spro denoting the old product name SunPro


• 
  /usr/local/bin/ — stuff provided by third parties who do not use an /opt subdirectory or CSW

Sun/Oracle operating systems, and their open source derivatives, were at their height perhaps the most extreme examples of such multiple personality operating systems. (Oracle has since chucked several of these directories, including /usr/ucb and /usr/ccs, away.) But some of the aforegiven are from AIX and others. /usr/amdahl/bin is from UTS, for example.

What program one ran from a given command name depended from what personality one was choosing. The idea that there was, and must be, only one program for any given command name was daft. After all, differentiating commands of the same names was what PATH was for.

There was no notion of strict precedence.

Many commands lived and died quite rapidly. Bill Joy created an iul command as a precursor to ul, for example. BSD also once had a greek command.

The idea that a command was set in stone forever, and owned a name to the excusion of shell builtins and others, was fairly foreign, given the turnover in command sets.

Just for starters, sh itself had been variously the Thompson, Mashey, Bourne, and Korn shells within the space of a decade and a bit. The idea that the Thompson shell's external if command prevented the Bourne shell from having if as a keyword was of course ludicrous.

Notice that the (post-2005, ksh93q) AT&T Korn shell's mechanism for enabling extra built-in commands, the inclusion of /opt/ast/bin in the value of PATH, both supports the notion that built-in commands can supplant external commands of the same names and ties in with the idea that one is expected to use PATH to control personality. (ast stands for AT&T Software Technology, by the way.)

Further reading

• American Telephone and Telegraph Company. "Basics for UNIX System Users: The help command". Unix System V, release 3.2: user's guide. Prentice-Hall. 1989. pp. 2–23 et seq.


• David Fiedler, Bruce H. Hunter, Stephen G. Kochan, and Patrick H. Wood (1986). "/usr — The Mystery Directory". UNIX system administration. Hayden Book Company, ISBN 9780810462892. pp. 54 et seq.


• 
  XPG. Standards, Environments, and Macros. Oracle Solaris Manual Pages. Oracle. 2014.


• 
  XPG4. Standards, Environments, and Macros. SunOS Manual Pages. Oracle. 2004.


• Michael R. Ault (1996). UNIX System Administrator's Companion. Wiley. ISBN 9780471111443.


• 
  if. Manuals. Etsh Project.


• Oddity in ksh93 shell script ("command -p mkdir t" fails)


• https://news.ycombinator.com/item?id=7278408


• Jonathan de Boyne Pollard (2017). An improved manual page for ul. Proposals.

SCCS has been written in 1972 already (making SCCS 46 years old today), but it is hard to get information for SCCS before release 4.0 that has been published February 18 1977. SCCS release 4.0 did definitely include the help command. Older SCCS revisions used a binary history file format that is not compatible to the current SCCS.

Let me give a short information on bash before I write more about SCCS:

bash is a user unfriendly shell as it implements many dumb builtins instead of implementing the ksh93 method for builtins that are not listed in the standard. ksh93 implements a builtin named builtin that allows to set up a search path for builtins. The main problem with such dumb builtins is that they are found with the maximum preference and cannot be deactivated easily. The extended ksh93 builtins however are usually not found by default at all, since they require the user to setup a PATH that includes /usr/ast/bin.

Back to SCCS and UNIX behavior:

Any developer on UNIX typically has /usr/ccs/bin in his PATH as ccs means something similar to C compilation system. This directory holds programs like cc, as, size, strip, nm, m4, make, SCCS, yacc...

/usr/bin/sccshelp has been introduced by Oracle while trying to make Solaris Linux-like and many UNIX people do not like this change.

If you like to check the official online documentation for SCCS, I recommend you to check:

http://sccs.sourceforge.net/

in special: http://sccs.sourceforge.net/man/index.html

it has seen a major rewrite during the past 12 years and btw: I am the maintainer since then.

While the original SCCS subsystem has been written by Marc J. Rochkind at AT&T, Eric Allman from BSD wrote the command sccs in 1980 and made SCCS usage simpler.

So if you live in the AT&T world, all commands are in /usr/ccs/bin while in the BSD universe, you call sccs <subcommand>

Answering your question: yes is was/is common for developers to have the sccs help command in PATH even though the SCCS frontend command sccs is typicalls in /usr/bin