Saving a command as a string

[Sam Smith]

Let's say I type in

regress dependentvariable income gender

Is there any way to save that command (either in memory or on disk) as a string except for manually copying it and pasting it in? I've searched quite a bit but nothing came up.
(I'm saving it to use in -estimates notes- .)

Thank you in advance.

[ben earnhart]

Well, you really should have a log going. Examples posted on Statalist, we're kinda lazy/sloppy about that, but anything important, you should have a logfile.

[Nick Cox]

 
local cmd regress dependentvariable income gender 
di "`cmd'" 

Find out about local and global macros and notes.

[daniel klein]

Honestly, I never really understood the need to have a log file, except (a) your computations require too much time to just re-run your do-file(s) and/or (b) you are working with data provided by some third-party that you are not allowed to store on your machines.

That being said, in this example Stata saves the command for you in e(cmdline).

Best
Daniel

[ben earnhart]

Interesting. Daniel, I started out in a shared Unix environment whereby *everything* was done with .do files and .log files. It was possible to use Stata interactively, but then that meant the rest of the team couldn't use it. So that's one reason I got into the habit. But apart from the "back in the day..." stories, here are a few good reasons for using logs:

• 1) Sometimes (more often than not), it's easier to slice-and-dice output from a .log file than anything copied or pasted. And if you have very much output, much faster. Nowadays, -outreg2- and -tabout- and such are good, but still, for many forms of output, I can take raw Stata output from a .log and turn it into a pretty table faster than you could type the -outreg2 command with appropriate options.
• 2) Sharing output with others. I'm in an academic environment, and it's quite common to share output, either as preliminary findings, or for trouble-shooting. Of course, you could share the data and .do files, but especially if the data is big (or as you mention, has restrictions), .log files are handier.
• 3) Verification for yourself, line-by-line, that it did what you thought it did. Sure, some simple command worked fine two months ago, and you can see no reason why it wouldn't keep working the way you expect. But sometimes this isn't the case, and being able to go back and verify is very important.
• 4) Related to 2 and 3, replication. Again, you *can* re-construct things with the data and .do file, but if random third parties (such as some journals) need to verify/audit your results, a good logfile (or set of them) allows them to see, step-by step, everything you did and what happened when you did it.

These words are only a crude defense of .log files. You do use .do files, right?

[daniel klein]

Ben,

there is no need to defend log-files. I agree that they can be very useful and they will not do any harm.

Your first point sounds interesting, as I have always used user-written stuff to produce "nice-looking" tables. I would be interested in an example how you get output from a log file, without copy and paste, though. Do you write routines to extract the desired results? If so think about sharing these routines with others.

Concerning your second point, I agree, given big data or restrictions. If this is not the case though, I prefer do-files, especially in shared work, as it allows me (or my colleagues) not only to spot errors/problems, but to also easily correct them or implement alternative code right away.

The verification part is important, but again, I prefer do-files. For the reasons outlined above, but also because I try to let Stata do a lot of checking (via confirm, assert etc.) instead of looking through a dozen lines of code and output. If I want to add a check, I can quickly do this in a do-file.

I totally agree on your last point, I would like to see more journals to request something like that. I can only imagine how many tiny coding errors in data management may have corrupted published results, because nobody ever looked at the code.

Best
Daniel

[ben earnhart]

Daniel -- the most common scenario for using log-file-output for tables is that I import it into Excel as fixed-width ASCII. If you place your column-breaks correctly, you can get really long output into manageable tables fast. *Sometimes* copy-and-paste works (it's gotten better over the years), but with a fixed-width ASCII import, I know where my columns are for everything. Very handy for correlation matrices and summary tables, for example, or a set of cross-tabs with the same width. A little annoying for regressions, since you need to import it twice (once for the betas, another for the fit statistics) so -outreg2- has some advantages, but once you're used to processing output as raw text, you can do a lot of formatting really fast.

I have a colleague who works from output in Word; he'll copy-and paste from Word to the command line, then copy-and-paste from Stata to his Word file. Now *that's* the worst of all possible worlds . I've forced him into situations where he needed to use .do files and .log files, so slowly weaning him away from the dark side.

Oh, and when sharing, I generally share the .do file *and* the .log file. And, ideally, the data, though with big or restricted-use data, sharing the data may not be feasible.

[Sam Smith]

That being said, in this example Stata saves the command for you in e(cmdline).

Daniel, Thanks for providing the most helpful answer in this thread so far. Stata does indeed ereturn the entire example command in e(cmd). However, if one uses an -ml- command, Stata ereturns only e(cmd)=ml. Is there a way to have Stata save the entire ml command, or would that require a user-written script?


Ben and Nick,

I appreciate your replies. I use -log-, -cmdlog-, and -estimates notes- extensively. I'm trying to figure out how to save the command to -estimates notes- without referring to the log. I'm also familiar with local and global macros.

What I'm asking, specifically, is whether it's possible to save the last command into a local macro without physically copying and pasting it in.

The fact that the replies have pointed me to other methods suggests that the answer is "no." Is that correct?

[ben earnhart]

Sam -- Sorry for hijacking your thread. More to your point, could you create an arbitrary macro containing your command, then use that as your command? The arbitrary macro, say SamCmd, would be accessible regardless of what else has or has not occurred in the meanwhile.

[daniel klein]

Ben,

using Excel (or other spreadsheet software) sounds like an interesting idea. I guess I have not spend enough time to explore the export features of Stata, yet.

Sam, depending on what exactly you want, it could be as simple as a this

pr samcmd ,sclass
    vers 11.2
    di as res `". `0'"'
    `0'
    sret clear
    sret loc samcmd `"`0'"'
end

Here is an applied example

. sysuse auto
(1978 Automobile Data)

. samcmd regress price mpg
. regress price mpg
(output omitted)

. sret li

macros:
             s(samcmd) : "regress price mpg"

Best
Daniel

[ben earnhart]

I was thinking of something as simple as this:

​local SamCmd="reg price mpg"

`SamCmd'

estimates notes: "`SamCmd'"

[Sam Smith]

Daniel,

Thank you very much. I know that sreturn saves the -regress- command but it appears not to save an -ml- command in the same way. Or am I doing something wrong?

Thanks!

Ben,

using Excel (or other spreadsheet software) sounds like an interesting idea. I guess I have not spend enough time to explore the export features of Stata, yet.

Sam, depending on what exactly you want, it could be as simple as a this

pr samcmd ,sclass
vers 11.2
di as res `". `0'"'
`0'
sret clear
sret loc samcmd `"`0'"'
end

Here is an applied example

. sysuse auto
(1978 Automobile Data)

. samcmd regress price mpg
. regress price mpg
(output omitted)

. sret li

macros:
s(samcmd) : "regress price mpg"

Best
Daniel

[daniel klein]

[...] but it appears not to save an -ml- command in the same way. Or am I doing something wrong?

Can't tell, as you are not showing what you did.

Best
Daniel