Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: RE: Automatically updating user written programs

From   "Nick Cox" <>
To   <>
Subject   st: RE: Automatically updating user written programs
Date   Mon, 7 Oct 2002 11:59:00 +0100

Tony Brady
> In a recent thread on Statalist Roger Harbord expressed
> some frustration
> with keeping programs downloaded from SSC and elsewhere
> up-to-date. At the
> moment there is no built in process for maintaining these
> programs, it
> relies on the user trying to re-download the ado and being
> told that "all
> files already exist and are up-to-date." To do this for all
> non-official
> Stata programs would obviously be extremely laborious.
> As an author of ado programs, it would be nice to know that
> people are
> mostly using the latest version of my programs, if only to keep the
> half-life of my bugs to a minimum. At the moment typing:
> . update
> is synonymous with typing
> . update from
> So users could, in theory, type:
> . update from
> or
> . update from
> to keep some of their non-official files up-to-date.
> Unfortunately, neither
> of these last 2 commands will work at the moment with Stata
> reporting that
> it can't find a stata.upd file on these servers. For my
> part this is because
> I wasn't aware of the "update from" syntax until about 5
> minutes ago and I
> can't immediately find any documentation on what the
> contents of a stata.upd
> file should look like.
> So where's all this leading? I have two comments:
> 1. People like myself and Kit Baum who maintain websites
> with Stata programs
> on them should probably get to know what a stata.upd file
> should look like
> (apologies to Kit if I typed the wrong URL above)
> 2. Wouldn't it be great if Stata looked for a stata.upd
> file on,
> and anywhere else the user had
> previously installed
> programs from when the user just typed "update all"? All
> really would mean
> all then. Since Stata already maintains a database of user installed
> programs I suspect this might not be too hard to implement.

(On the very last point, yes and no. Stata Corp
runs a regular net search for stuff. It does
not update an existing data base; rather, it throws
away the previous set of search results.)

I imagine that many users would like something
like this.

I would just like to add one note of caution.

These days, the tendency is for different
sources of Stata software to be regarded
as parts of a continuum. Many postings
on this list refer to particular Stata
programs which turn out to be sometimes
official commands and sometimes user-written
commands, and the array of available
programs often looks like a seamless whole.
In most ways, this is excellent, of course.

However, one way in which user-written
commands differ from official commands
is that there is less discipline over
command names. Several times I have
wasted  time trying to understand a very
puzzling set of error messages,
which has turned out to arise because there
are two user-written programs with the
same name which will be both be installed
in STBPLUS. If I install one, and
get some message about replacing files,
this usually creates no surprise
in my mind (seemingly, I just had
an old version, which has been updated).
Conversely, I get a message about
files being up-to-date and this
also usually creates no surprise
(seemingly, I just had a up-to-date
version from some previous burst
with this program).

Concretely, this has happened to me
more than once:

User-written package P includes a
program X.

User-written package Q also includes
a different program with the same
name X.

I install P, including X. (Sometimes
I don't even know that there is
an X included.)

I later install Q. Depending on
whether or not I force a -replace-
of files, I could end up with either
(a) Q without its X or (b)
P without its X, which will cause
immediate problems with Q or
problems with a later attempt
to run P.

Advice therefore under various different

1. The more user-written material you install,
the more likely it is that this will
occasionally happen to you. I stress
"occasionally", but when it does happen,
it is not always obvious why you are
getting strange error messages and
you can be a while before you realise
what the problem is.

2. User-programmers have been recommended
to register their program names with
Stata Corp, although my impression is
that few do this. (I certainly don't,
partly out of laziness, and partly
because I often forget or ignore another
Stata Corp request, to avoid using
proper English words as program names,
and registration wouldn't accept those.)

3. -which- tells you which version
of a program is visible to Stata.
A well-written program will include
a *! comment line giving author,
date and version. (I can't see
a good reason for ignoring _that_

4. Occasionally you have to go
all the way and look inside a program
to see what it is.


*   For searches and help try:

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