EViews.com

Please run the attached EViews program. I have tested it in the latest patched versions of EViews 11 and EViews 12 (both 64-bit) . Under certain conditions, it seems that the WFSELECT command does not properly parse the workfile name provided. Specifically, if you provide just the filename with the ".wf1" extension, the command will fail.

Not really a bug per se.

Due to Windows naming conventions, it would be perfectly possible for you to create a workfile with the file name work1.wf1.wf1, in which case you would use:

to select the workfile (without using the .wf1 extension).

In other words, wfselect always assumes you are simply providing the name of the workfile (without file extension), unless you are also providing a path.

Come on, Gareth. That seems like a pretty unsatisfactory answer to me. Why does it work when you supply the absolute path with .wf1 and not when you supply the filename (in the current data path) with .wf1. Using your logic, shouldn't it assume when you use the absolute path that the workfile is named c:\temp\work.wf1.wf1?

Also, do you reasonably believe that anyone would have a legitimate use case to name a workfile with the wf1 extension twice (e.g., work.wf1.wf1)?

Furthermore, do you expect me to believe that WFSELECT was intentionally implemented handle this case differently than WFCREATE, WFSAVE and WFOPEN? Try the following code sequence.

WFCREATE/SAVE/OPEN were all written before Windows supported "." inside a file name. We couldn't change them for backwards compatibility.

WFSELECT was added later.

Also WFOPEN and WFSAVE support many file types, so we can't always assume it is a wf1. They work on files on disk. WFSELECT is only used on workfiles, in memory. They're subtlety different operations.

Unfortunately, these days, most users are unaware of what a file extension is. So yes, it is entirely possible (and I've seen similar) that someone would create a file called this.is.my.wf1, which would then have an additional .wf1 extension on the end.

Unfortunately, these days, most users are unaware of what a file extension is. So yes, it is entirely possible (and I've seen similar) that someone would create a file called this.is.my.wf1, which would then have an additional .wf1 extension on the end.

I think that this only bolsters my point since the user intended to name that file this.is.my.wf1 and EViews wasn't smart enough to realize and then robotically named it this.is.my.wf1.wf1 instead.

Couldn't you just add a bit of conditional processing to the beginning of the WFSELECT command processing that treats terminal ".wf1" tokens in the wfname differently? How about a single level of terminal ".wf1" tokens is treated the same as if none were present and multiple levels of terminal ".wf1" tokens are taken literally? That seems to be the way WFCREATE, WFSAVE, and WFOPEN work.