[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tab-completion inconsistencies
From: |
Daniel J Sebald |
Subject: |
Tab-completion inconsistencies |
Date: |
Thu, 07 Mar 2013 13:30:38 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
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
- Tab-completion inconsistencies,
Daniel J Sebald <=