bugGNU Octave - Bugs: bug #40726, <Tab> complete uses...


bug #40726: <Tab> complete uses incorrect file separator on Windows

Submitter:  Rik <rik5>
Submitted:  Wed 27 Nov 2013 10:45:54 PM UTC
Category:  Interpreter Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Tue 08 Dec 2015 04:29:39 PM UTC, comment #6: 

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.

Rik <rik5>
Group administrator
Tue 08 Dec 2015 10:21:45 AM UTC, comment #5: 

Rik, can this be closed given your changesets?

Lachlan Andrew <lachlan>
Tue 03 Dec 2013 09:14:44 PM UTC, comment #4: 

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


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.

Rik <rik5>
Group administrator
Fri 29 Nov 2013 10:49:55 AM UTC, comment #3: 

Thinking about this some more...

The canonicalize function would only need to run on Windows. After all, why fix something that's not broken? That is, scratch my bullet point about Unixy systems, it's irrelevant.

Messing with what Readline returns on completion is beside the point IMO. Even on Windows, you can be conditioned into using '/' for dir separators if you're routinely using e.g. the MinGW shell or Git for Windows.

Philipp Kutin <pkutin>
Thu 28 Nov 2013 11:06:08 PM UTC, comment #2: 

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.

Philipp Kutin <pkutin>
Thu 28 Nov 2013 08:51:23 PM UTC, comment #1: 

As to your last sentence:

Windows doesn't accept "/" (or "\", obviously) within filenames.
("\" only works as path separator, once translated to the Windows side)

Philip Nienhuis <philipnienhuis>
Group Member
Wed 27 Nov 2013 10:45:54 PM UTC, original submission:  

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.


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

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).

Rik <rik5>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by pkutin (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-12-08 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code