Noisily displaying commands in ado-files

[Leonardo Ferreira]

I'm writing an ado-file which generates variables based on user-input.
It's all working fine but I wanted the command I used to be visible.

For instance:

gen bcgv = .
capture confirm variable h2
if _rc == 0 {
replace bcgv = 0 if inrange(agemo,`vacref') `isalive' `lastborn'
recode bcgv (0=1) if inrange(h2,1,3)
}

I want to display in the console the replace and recode command lines.
I managed to surround them by noisily { }, execute the ado file as "noisily adoname", and even adding noisily before each command line.
But nothing seemed to work.

Is there any solution to this approach?

Thanks in advance

[Nick Cox]

noisily is a red herring here, as it's the default any way.

To echo the command lines literally from within a program, display the corresponding text. To see this, consider the results of running

sysuse auto, clear

program p1
    su mpg
end

program p2
    di ". su mpg"
    su mpg
end

p1

p2

[Leonardo Ferreira]

Thank you Nick for your prompt reply.

I realize it is possible to display the command line as you stated.
But my concern was regarding the visibility of the command line.

When you run a do-file, if you do not specify either noisily or quiet commands, Stata will show you the command itself and the result of it. See image below.



But when we do the same using an ado-file, Stata only shows the results.

(8753 missing values generated)
(8753 real changes made)

Is this default behavior of ado-files? If so, are we able to make it act the same way do-files behave?

I hope I made myself clear.

Thanks for your time.

[Nick Cox]

In essence, yes, this absolutely is a key and designed difference between programs and do-files. The sequence is that

1. do do-file echoes commands and gives results.

2. run do-file gives results.

3. a program is this further step with extra features.

You could take a program file and demote it from being a program. Some features could be retained, e.g. you could use syntax to parse the syntax. You would lose e.g. ability to save r-class or e-class results from the demoted program as such.

It seems as if you prefer the self-documenting nature of a do-file, so a do-file is the way to get that.

[Leonardo Ferreira]

For this specific purpose, I'm afraid I will need to stick with ado-files.

I would only need the self-documenting characteristic of do-files for those 2 lines. As you mentioned earlier, the way to go will be display it as text, since I don't have much of a choice.

Thanks again!

[Clyde Schechter]

I have nothing to add to this thread in terms of information, but just thought I'd point out that most ado files contain fairly complex code, much of which is devoted to identifying and dealing with a wide range of general situations and data configurations that the program might encounter, trapping errors, etc. If the commands were routinely echoed to the output, our Results windows would scroll endlessly and our log files would be huge--and mostly with output that we aren't really interested in (except perhaps when debugging). To get a feel for what that would look like, just run your program after -set trace on-. I think that is the rationale for the way ado files behave. The expedient of using -display- is fairly simple when that behavior needs to be overridden.

[Nick Cox]

Clyde is naturally correct too. Broadening the question, note various other ways of documenting what was done, e.g. by generating notes that can be saved with the dataset.