It doesn't cause any problems, but the issue still remains that the command line uses '/' as the filesep() character rather than '\' which is what most people expect for Windows.  That's whic I left it open, but changed the severity to Minor.

I committed several changesets which remove Octave's differences in behavior with respect to file separator.

http://hg.savannah.gnu.org/hgweb/octave/rev/1e9cb13faa7a
http://hg.savannah.gnu.org/hgweb/octave/rev/832ecfda1d3c
http://hg.savannah.gnu.org/hgweb/octave/rev/427412d40f1a
http://hg.savannah.gnu.org/hgweb/octave/rev/70e83c641b48

It would still be nice to have the correct file separator displayed when using <Tab>, but it shouldn't lead to any problems with Octave now.

Personally, I'd handle such a case by normalization. Which combinations are possible?

- On Windows, '/' is disallowed in file names (thanks goodness!)
- On Unixy systems, '\' could be part of a file name I think, but in a shell that would be a recipe for ambiguities and general disaster. If I saw such a name on my file system, I'd see how to get rid of it ASAP!

So maybe whenever a file name is expected, it should be passed through some "canonicalize_slashes()" function? That one would translate all [\/] to the proper slash for the given platform...

Just my two cents, not very deeply thought out.

When using <Tab> to complete a directory name at the command line, the generated file separator charactor is always the UNIX character '/'.  Instead, Octave (and really Readline), should append the correct filesep() character for the OS in question--in this case '\'.

Three instances of problems arising from this are detailed below.  To find others, grep for comparisons to filesep in the scripts directory.

All examples assume a directory bin/ in the current directory.

ls bin/
Invalid switch - "".
error: ls: command exited abnormally with status 127

The failure results from the fact that ls_command() on Windows is

dir /D

and dir interprets a '/' character as an option leader.

runtests dir_name/

fails because it is looking for either a bare directory name or a name with the appended filesep.  The same thing exists for filedemos.

Finally:

what bin/

error: what: subscript indices must be either positive integers less than 2^31 or logicals
error: called from:
error:   C:\Documents and Settings\Rik\My Documents\Octave\octave-2013-11-27-09-34\share\octave\3.7.
7+\m\miscellaneous\what.m at line 36, column 7
e

This is super-annoying because the warning message is so unrelated to the actual problem.

One coding approach would be to fix Octave's interaction with Readline so that it returns the correct file separator.

A second approach would be to code defensively and accept either file separator '/' or '\' at the end.  This would be a problem if there were actual files that used these two characters as could happen (at low probability as these are not good choices for filename characters).