Relative path doesn't work for Go command

Since you can go upwards by passing a relative path .... to the Go command I would appreciate if going downwards by relative paths would be supported as well.

The 2nd command triggers an error dialog ...

Go C:\ Go Windows\System32

I'm just curious, what's the usecase behind that?

In our development environment we have many tools that allow to copy relative pathes to the clipboard or simply dumps relative pathes directly to the console (during logging). If you want to do something with such a deeply nested file it is very convenient to just copy the relative path and using a Go "{clip}" command bound to CTRL+ALT+V to quickly catch it instead of manually traversing the folder tree. :thumbsup:

And when doing that, you always have a file display open, that matches the start of any of the relative paths from your logs?

I guess a little script in place of your GO "{clip}" command could also do the trick, couldn't it? Just something, that checks if the path currently in the clipboard is relative or not, if it is, prepend the current filedisplay path to it and GO.

"Go Windows" and then "Go System32" will work, but it only works for direct children one at a time, not relative paths two or more levels deep.

Go "{sourcepath}{clip}" will also solve the problem, except then it won't work if you sometimes have absolute paths in the clipboard. A bit of scripting could be used to always do the appropriate thing.

I already use a small script for this (which unfortuntely doesn't detect relative path very reliable).

I just thought that it might be an oversight because this works very well ...

Go C:\
Go .\Windows\System32

Thus I assumed that you may want to simplify this a little to avoid confusions in rare occassions.

BTW: Is there any API method I can use to determine whether a path is relative or not? Currently I take a string as relative path if the first character is a letter and the second is not a colon. In this case I simply prefix the path with "." and pass it to the Go command.

Checking for \ at the start of the path is also a good idea, if UNC paths are possible. Other than that, sounds like you have a solution.

Your relative path-test sounds like it should do the trick? In what occassions does it fail?
Maybe trimming single occurences of "" and "/" from the beginning/end is an idea to enhance it and also making sure, that it recognizes string like "...." as well, but I don't know what variety of paths you're dealing with over there. o)

I guess he does it the other way round. He checks for relative paths and not for absolute paths to decide later on, its not absolute, so it must be relative. Hum, did I get this right AKA? o)

Yes, I think it's more easy to detect a false relative than a true absolut path. :sunglasses:

I use ConEmu as multi-tab console manager for a long time. There I have a shortcut bound to CTRL+O that instantly open a new DOpus tab placed to the path of the active console. Thus if I need to manipulate some files that were shown as relative pathes (e.g. during a maven log output) I simply press CTRL+O and start whatever I need to do ...

Ok, I think I see. So you..

  • select the relative path
  • CTRL-C the relative path into the clipboard
  • then it's CTRL-O in ConEmu to open DO with the current ConEmu-Tab path
  • and then CTRL+ALT+V in DO to make DO step down the relative path

Shouldn't it be possible to combine all these steps into a single one with the macro language ConEmu provides?

Yes, but I also use this command quite often after grabbing a relative file path from the maven console output.

I switched over to true absolute path detection, seems to work better now.

@script jscript

function OnClick(clickData) {
	if (DOpus.GetClipFormat() == "text") {
		var path = DOpus.GetClip();
		if (!/^([A-Z]:|[\\/]).*$/i.test(path)) {
			path = ".\\" + path;
		clickData.func.command.RunCommand("Go \"" + path + "\"");

Sorry, certainly I meant "from the maven file output" ...