Tab-completion inconsistencies

[Daniel Sebald]

In trying the example Rik sent, I created a directory with a comma in
the name, something valid in linux and probably elsewhere.  At the
Octave command line I used tab-completion to get the line of text that
normally appears at the linux command line.  However, Octave doesn't
handle that line the same way that linux does.  It might be nice for
code to behave at the Octave command line the same way it does at the
linux command line.  What do others think?  If others think this is a
problem, I'll copy these examples into a bug report.  Here are some
examples:

First, basic tab-completion behavior:

[sebald octave]$ cd tst
{tab-key}
[sebald octave]$ cd tst,flag/
{tab-tab-key}
[sebald octave]$ cd tst,flag/

octave:3> cd tst
{tab-key}
octave:3> cd tst,flag/
{tab-tab-key}
octave:3> cd tst,flag/
Display all 345 possibilities? (y or n)

At that point if I type 'y', all the files in the directory will be
shown.  This is not correct as "tst,flag" is already a unique name in
the file tree.


Second, interpreting what the tab completion produces:

[sebald octave]$ cd tst,flag/
[sebald tst,flag]$

octave:3> cd tst,flag/
parse error:

   syntax error

>>> cd tst,flag/
                ^
How about if I remove the character Octave doesn't like?

octave:4> cd tst,flag
error: tst: No such file or directory
octave:4> ls
octave:5> ls

OK, still problems.  Well, I'm saying it would be nice to accept what
the linux command line is accepting.  [But more than that Octave seems
to have lost its place in the file system tree.  OK, I'm
exiting/re-starting in order to get back to some known directory.  I
can't seem to reproduce this problem.  However, I'm fairly certain there
is something flaky because the fifth example is something I can reproduce.]


Third, let's look at file/directory names with "extended characters",
i.e., characters that typically aren't valid at the command line:

[sebald octave]$ mkdir "lst flag"
[sebald octave]$ cd lst
{tab-key}
[sebald octave]$ cd lst\ flag/
[sebald lst flag]$

octave:3> cd lst
{tab-key}
octave:3> cd 'lst flag/
{apostrophe-key}
octave:3> cd 'lst flag/'
octave:4>

OK, well not bad.  The behavior is slightly different from the linux
command line, but not quite.  Why doesn't the Octave result add a
additional apostrophe at the end when it knows that it has a complete
and unique file system name?


Fourth, tab complete only works one directory deep:

[sebald ~]$ cd octave/lst
{tab-key}
[sebald ~]$ cd octave/lst\ flag/

octave:7> cd octave/lst
{tab-key}
octave:7> cd octave/lst

Nothing happens.  How about this:

octave:7> cd "octave/lst
{tab-key}
octave:7> cd "octave/lst flag/

Well that goes a little bit further.  So finish with:

{double apostrophe-key}
octave:7> cd "octave/lst flag/"
octave:8>


Fifth, now remove the directory and Octave gets somewhat lost:

[sebald ~]$ rmdir octave/lst\ flag/

octave:8> ls
error: unable to find current directory
error: unable to find current directory
octave:8> ls
error: unable to find current directory
shell-init: error retrieving current directory: getcwd: cannot access
parent directories: No such file or directory
octave:9> cd ..
error: unable to find current directory
octave:10> ls
[This shows the list of files in my home base directory in the pager,
not unreasonable.  But then...]
octave:11> cd octave
octave:12> ls
scripts

That last result is missing a hundred or more files in my octave
subdirectory.  Octave is lost in the file system tree at this point.  Exit.


Well, to sum up, I realize it might be a lot of work to make this work
perfectly, but it seems to me that Octave isn't as graceful as it could
be on tab-complete and navigating the file system tree.

Dan

[Jordi Gutiérrez Hermoso-2]

On 7 March 2013 14:30, Daniel J Sebald <[hidden email]> wrote:
> In trying the example Rik sent, I created a directory with a comma in the
> name, something valid in linux and probably elsewhere.

Linux doesn't parse commands. It's just a kernel. It's GNU bash that
is parsing your commands. Incidentally, GNU bash is where jwe
originally grabbed the code for Octave's own parser.

> At the Octave command line I used tab-completion to get the line of
> text that normally appears at the linux command line. However,
> Octave doesn't handle that line the same way that linux does. It
> might be nice for code to behave at the Octave command line the same
> way it does at the linux command line.

Yeah, this is an open problem:

    https://savannah.gnu.org/patch/?7584

It is, incidentally, a difficult problem. The solution isn't easy.

- Jordi G. H.

[Daniel Sebald]

On 03/07/2013 01:36 PM, Jordi Gutiérrez Hermoso wrote:
> On 7 March 2013 14:30, Daniel J Sebald<[hidden email]>  wrote:
>> In trying the example Rik sent, I created a directory with a comma in the
>> name, something valid in linux and probably elsewhere.
>
> Linux doesn't parse commands. It's just a kernel. It's GNU bash that
> is parsing your commands. Incidentally, GNU bash is where jwe
> originally grabbed the code for Octave's own parser.

Yes, the shell.  My bad.  BTW, is there any such tab-completion on
Windows systems, or Windows emulators, and other sorted Windows menagerie?

>> At the Octave command line I used tab-completion to get the line of
>> text that normally appears at the linux command line. However,
>> Octave doesn't handle that line the same way that linux does. It
>> might be nice for code to behave at the Octave command line the same
>> way it does at the linux command line.
>
> Yeah, this is an open problem:
>
>      https://savannah.gnu.org/patch/?7584
>
> It is, incidentally, a difficult problem. The solution isn't easy.

OK, I see it.  That one didn't seem to go too far.  :-)

Should I attach the examples to that patch, or should we close that and
just open a bug report?  Or maybe just put this on a "to-do" list
somewhere.  I realize it isn't any easy problem, but it is worthwhile
trying to solve it because having a non-functional tab-complete or one
that produces something for which the back-arrow is needed to place an
apostrophe in front hampers productivity in a cumulative way.

Dan