On 29-08-2009, at 02:55, Allin Cottrell wrote: > > One question occurs to me, as I push out the 1.8.4 release: > I wonder if anyone ever uses gretlcli.exe on Windows? I've > included it for completeness but maybe it's not earning its keep?
1. Why is gretlcli useful? A very nice property of Gretl is that the gui records a lot of what you have done: interactive menu commands are translated to batch commands (most of the time). This leaves the user a record of what has been done. You can save the command log and edit it to get a script that can be rerun as many times as you want. Easy to use new data etc and rerun. Especially when many estimations have to be done with new data, batch processing will come in quite handy. Launch a shell script (cmd batch file) running any required gretl scripts and saving gretl output. I then have inputs and output available for archiving and viewing independently from the original application. (Of course you can do that in the gui but it's a chore, open script, run script, save output etc etc). Gretl (and gretlcli I hope) can do LaTeX output. I wouldn't dream of using gretlcli in Mac OS X, Linux or Windows for exploratory analysis or for trying out something. But the log file of what I have done in the gui is more than just useful. I can use it as described above. The utility and added value of Gretl over and above what for example Eviews has to offer, is gretlcli and the gui command log, amongst other things. It lets you run scripts in batch. The current gretlcli on Windows does not operate in the same way as the gui. In a networked environment it doesn't read the gretlnet.txt file and thus has/may have different directories and paths compared to the gui. 2. Terminal I don't understand what the horribleness of cmd.exe has to do with running gretlcli. Once you are in gretlcli you have reasonable commandline editing which is independent from what the terminal or the shell has on offer. BTW: The default terminal emulator on Windows XP can be customized to make it more palatable. <rant> The batch language of cmd.exe is indeed primitive but even so, it has improved quite a bit compared to its predecessors. You can now do complicated input/output redirection (similar to bash...). There is more than enough trickiness to get yourself into a real muddle. (ever tried to run a bash script with line endings <CR><LF>, that you completely forgot about? Try it.). Cmd.exe has history, reasonably decent command line editing. </rant> Berend
