cd command does not work in GUI Command console

[wenzeslaus]

Any of these

cd
cd --help
cd some_directory

in the wxGUI (shell, non-Python) command console causes

[Errno 2] No such file or directory

probably on all platforms (reported on ​MS Windows, ​Mac OS X, confirmed on Ubuntu) and for all versions (now tested with trunk (r58578) and packaged 6.4.3).

For me, ls and cat work in GUI command console as well as in the normal system command line. I guess it's unrelated, but the change of the directory from GUI works (in 7, Settings -> GRASS working environment -> Change working directory).

[neteler]

Screenshot of added --help flag support (GRASS 7 code)

[neteler]

diff of added --help flag support (GRASS 7 code)

[neteler]

The lacking --help support affects rather all modules.

Attached a diff (GRASS 7 code) and a screenshot for review.

[wenzeslaus]

Replying to neteler:

The lacking --help support affects rather all modules.

Note that I meant cd --help as a test of standard system cd command. No connection to GRASS modules and any kind of support of their --help was intended.

Attached a diff (GRASS 7 code) and a screenshot for review.

If see the feature at the screenshot, but I'm not getting the same result. I don't understand how the patch would add the feature which is at the screenshot, i.e. the support for complete of predefined long flags.

None of the predefined flags is autocompleted in the GUI Command console, however, they worked without the patch and works with the patch:

g.region --help
...
r.proj --overwrite ...

The patch is little bit more crucial for GRASS than the not working cd command, so I would say that the patch is somehow hidden here.

For me, the patch changes parser, so that modules now accepts also

g.region --h

and not only

g.region --o

I cannot say the effect in the GUI without a detailed analyses but it seems right.

I actually like the patch for the parser, I wanted propose --h and inclusion of --help in the manual page myself.

I just don't like the wording of the --help description, especially the slash:

--help Command line help/usage summary

What about

--help Prints usage summary

We use word print for -p and -g options already.

[neteler]

Replying to wenzeslaus:

Replying to neteler:

...

I actually like the patch for the parser, I wanted propose --h and inclusion of --help in the manual page myself.

Yes, the patch adds this, too (run "make distclean" to see it).

I just don't like the wording of the --help description,

Submitted with improved wording in r58783 (GRASS 7 only so far).

[wenzeslaus]

Replying to neteler:

Replying to wenzeslaus:

Replying to neteler:

...

I actually like the patch for the parser, I wanted propose --h and inclusion of --help in the manual page myself.

Yes, the patch adds this, too (run "make distclean" to see it).

I just don't like the wording of the --help description,

Submitted with improved wording in r58783 (GRASS 7 only so far).

OK it works for me. The problem was that I tried writing - character on numeric keypad but it works only for - with key code 45, so probably only -_ button speaking about English layout.

I fixed this in r58788. It now reacts to numeric keypad - key and also to general wx.WXK_SUBTRACT which however, does nothing for me on Ubuntu 12.04 with US locale and USA keyboard (note also that the change gives expected results also for Czech keyboard: the - reacts, -_ key on English layout does not). These cases now triggers the autocomplete:

event.GetKeyCode() == 45 and not event.ShiftDown()
event.GetKeyCode() == wx.WXK_NUMPAD_SUBTRACT
event.GetKeyCode() == wx.WXK_SUBTRACT

However, note that this change is in fact not much related to this ticket about cd command as well as the unifying approach to --help in parser (and consequently in wxGUI command console) done in r58783.

[annakrat]

r58783 caused that help checkbox appeared in auto-generated dialogs. I removed it in r58793 because help button is enough.

[wenzeslaus]

Testing cd command in Python outside GRASS session:

>>> import subprocess
>>> subprocess.call(['cd', '--help'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/subprocess.py", line 493, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

While cp --help works. So, using which to find first cp and then cd:

$ which cp
/bin/cp
$ echo $?
0
$ which cd
$ echo $?
1

There is really no cd executable. Checking cp and cd error message style in command line:

$ cp aa
cp: missing destination file operand after `aa'
Try `cp --help' for more information.
$ cd aa
bash: cd: aa: No such file or directory

cd is part of bash, not a separate command. So, GUI needs to implement its own cd command using Python (os.chdir(path)). There is a change working directory item in the menu, so it might be enough just to connect cp some/path to the same handler in the similar way as d.* commands are handled. Some syntax pitfalls may occur especially on MS Windows and with white space and non-ASCII characters.

With the new understanding of the problem, changing to enhancement.

[wenzeslaus]

cd command implemented in r59388 for trunk. cd without parameters opens the dialog opened from GUI main menu change working directory item. All supported possibilities are:

cd
cd -h
cd --h
cd --help
cd existing_dir
cd not_existing_dir 

Test:

cd "--h"                                                                        
Changes current working directory for this GUI.                                 
Usage: cd [directory]                                                           
                                                                                
cd "asdfsae"                                                                    
[Errno 2] No such file or directory: 'asdfsae'                                  
                                                                                
cd "raster"                                                                     
Working directory changed to:                                                   
"/full/path/from/os.getcwd/function/to/raster"                                      
                                                                                

Tested on Linux (Ubuntu) with spaces and UTF-8 in path. Needs test on MS Windows and Mac OS X.

And by the way:

$ which cp
/bin/cp
$ which cd
(no output)
$ type cp
cp is /bin/cp
$ type cd
cd is a shell builtin

[glynn]

Replying to wenzeslaus:

There is really no cd executable.

If the shell runs an external program, it has to do so in a child process. A "cd" program would change the current directory of the child process running the "cd" program, which is of no use to anyone.

Some built-in shell commands are built-in for convenience or efficiency. "cd" is built in because it has to be; only the shell itself can change its current directory. Likewise for "export" and "ulimit".

[wenzeslaus]

Let's do one more enhancement before closing this ticket. ~ does not work. It would be probably better if it would be supported by some replace.

cd ~/Documents/                                                               
[Errno 2] No such file or directory: '~/Documents/'  

cd ~                                                                          
[Errno 2] No such file or directory: '~' 

I also ask for comments about behavior of cd without parameters. Currently, it is aligned with behavior of GRASS modules not the original bash command.

Also is there something which should be done to improve experience of MS Windows command line users?

[wenzeslaus]

Replying to wenzeslaus:

Let's do one more enhancement before closing this ticket. ~ does not work. It would be probably better if it would be supported by some replace.

~ implemented in r62190. Works the same for all platforms although on MS Windows this is not expected.

r62190 adding a feature, so no backport to 7.0 is necessary, closing the ticket.

I also ask for comments about behavior of cd without parameters. Currently, it is aligned with behavior of GRASS modules not the original bash command.

I agrre with myself on my original idea, so it is aligned with GRASS modules.

Also is there something which should be done to improve experience of MS Windows command line users?

The is probably nothing which could be done. What should be done is support of their transition to Linux and this, in this case, is already done by support of cd command and ~ syntax.