[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: RE: RE: RE: RE: RE: List of ALL Commands

From   "Sergiy Radyakin" <[email protected]>
To   [email protected]
Subject   Re: st: RE: RE: RE: RE: RE: List of ALL Commands
Date   Fri, 19 Sep 2008 15:27:57 -0400

commands, so it does not list you any of the undocumented commands (I
mean really undocumented, like -showpoint- or -zipfile-, so it does
what you write: it lists "official Stata commands", but not what is
written in the help file: "getcmds will retrieve the name of all
built-in Stata commands..."). Anyways, it will address the same
maintenance files that I mentioned earlier: "use the alias help file
to find other built-in and ado-file programs that do not have
hlp-files with the same name". See the ReadAlias procedure.

"better approach is to highlight everything but command names, so that
commands are implied as the complement." -- but you still need to know
what the command names are to exclude them from highlighting, right?

"maintaining a list" is of course a nightmare, as long as a human
being is involved somewhere in the process, but it does not have to.
One can (programmatically) analyse _current_ set of installed ado
files to get the possible program names, but one can't look into the
internals of Stata to get the list of built-in commands (unless you
bruteforce it with -which- aaaa, -which- aaab, -which- aaac, ....
-which- zzzzzzz...zzzzzz).

If this list is known, then everything else is (at least in theory)
doable. With details to be determined by the user, whether to limit
the list with what is in the BASE, BASE+PLUS, or

So may I rephrase my request:
"does anyone have a list L, such that the response of Stata to
-which- X yields "built-in command: X", if and only if X is an element
of list L"?

Note also that built-in commands have priority and will override any
.ado-implemented commands, so that if I had a zipfile.ado - I wouldn't
be able to use it and have hard time understanding why. Note also that
strangely enough Stata complains when I try to define a just-defined
program, but does not complain when I redefine a built-in command:

program define foobar
  display "foobar"

program define foobar
foobar already defined

// above is fine and is what it is supposed to be

program define use
  display "use"

//Stata does not give an error here, but there is no way to use our new -use-
// I'd expect that defining programs with names coinciding with
built-in commands be prohibited. Otherwise, what is the rationale?

Thank you,
     Sergiy Radyakin

On Fri, Sep 19, 2008 at 2:23 PM, Nick Winter <[email protected]> wrote:
> Jeff Pitblado has a command -getcmds- which generates a listing of all
> official Stata commands, collected by searching for ado files, hlp files,
> and the help alias files.  It's a bit old; not sure if it generates a truly
> comprehensive list under Stata 10.  But it does make for a useful list for
> syntax highlighting purposes, especially because its use of the help alias
> files means that it includes, eg, -reg- -regr- -regre- -regres- and
> -regress-.
> net from
> or
> findit getcmds
> -Nick Winter
> Sergiy Radyakin wrote:
>> maintanance files will help when compiling a list of built-in and
>> supplied-with commands.
>> look e.g. at ...\Stata10\ado\base\c\cmddlg.maint
>> and in general at *.maint
>> IMHO the lists should be separated into language constructs (program,
>> end, while, if, etc), built-in commands (basic bricks), and everything
>> else (ado). I guess the students wanted to know what tools are at
>> hand, available for work, in an attempt to reduce the open-end
>> question "which command to use?" to a multiple choice question "which
>> of these to use?".
>> -which- and -findfile- are not useful for the purpose. because in
>> order to check whether the command exists or not you must have an idea
>> of what it may be called. I've seen a few people who would _suspect_
>> existence of xtivreg2. (in other words this is precisely the case
>> where in order to ask a question, you need to know the answer).
>> About 5 years ago I've seen in library a 3-volume encyclopedia (I
>> guess about 5000pages in total) of all software released in a
>> particular year (e.g. in 1990, don't remember now). Although an
>> immense effort was done to sort and describe all those programs, it
>> was surely neither complete nor accurate.
>> However, I see a very practical need for such a list of Stata
>> commands: for the purpose of syntax highlighting. It would
>> significantly improve the readability of the programs, because current
>> highlighters AFAIK are based on Stata's 6-7 syntax (at least mine is).
>> It may also help preventing name collisions.
>> Regards, Sergiy Radyakin
>> On Fri, Sep 19, 2008 at 12:35 PM, Nick Cox <[email protected]> wrote:
>>> -findit- does not guarantee to find everything in the public domain. For
>>> example, -findit- will not find programs published informally within
>>> Statalist postings, such as yours this week.
>>> Nick
>>> [email protected]
>>> Martin Weiss
>>> Agreed! Would a combination of -findfile-, -which- and -findit- be
>>> sufficient?
>>> Nick Cox
>>> -which- tells whether a command is visible to Stata given your Stata
>>> installation and your current working directory. That is only a subset
>>> of existence "as we know it, Jim".
>>> Martin Weiss
>>> An alphabetical list is pointless. If it is all about the mere existence
>>> of
>>> a command, -which- is the way to go...
>>> *
>>> *   For searches and help try:
>>> *
>>> *
>>> *
>> *
>> *   For searches and help try:
>> *
>> *
>> *
> --
> --------------------------------------------------------------
> Nicholas Winter                                 434.924.6994 t
> Assistant Professor                             434.924.3359 f
> Department of Politics                  [email protected] e
> University of Virginia w
> PO Box 400787, 100 Cabell Hall
> Charlottesville, VA 22904
> *
> *   For searches and help try:
> *
> *
> *
*   For searches and help try:

© Copyright 1996–2024 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index