Fix opening code via command line using relative paths

[Tyriar]

Opening code using code .., code ../.. was opening the wrong directory
since trailing '.' characters were being trimmed by the launch code.

Fixes #3127

---

@bpasero I'm assuming that the trimming was added for Windows, just wanted to make sure that was the intent. Or can we remove it?

[joaomoreno]

I am really afraid of touching this code, and @bpasero is out. No idea why this code is there... makes very little sense to me. E.g. what happens if we tried to open a folder with a dot at the end (folder.)?

Any way, @Tyriar can you give me more details here? Is this because the new launcher script behaves differently? Did you test this on Linux, OSX and Windows?

[Tyriar]

Might be best to wait for @bpasero if you're concerned.

I've only tested on Linux, I don't see why trailing . character would want to be culled on OSX and Linux. AFAIK on Windows somefile. is equivalent to somefile which I guess explains why it's there?

[joaomoreno]

Not being able to open . or .. seems to me to be a much worse proposition than not being able to open somefile. on Windows only... I'd vote for removing that line altogether right now and let @bpasero speak up when he's back.

What do you think?

[Tyriar]

Sounds good to me, I'll just remove it then.

[joaomoreno]

👍

[bpasero]

@Tyriar please make sure that #1579 is still fixed after this change. The original issue was that someone managed to save a file called "cd.." which is an invalid file on Windows. Maybe a better fix is to remove trailing dots only when there are no leading dots.

[Tyriar]

@bpasero well I assume that is happening again, not being able to open folders seems far worse though. Maybe something like this would be better:

if windows
  path = normalize(path)
  is path is not a directory
    trim '.' from path

I'll reopen #1579 to fix again.

[bpasero]

@Tyriar but if the condition is to only trim "." if there is a non-dot before the dot, you would still be able to open "." and ".."?

[Tyriar]

@bpasero normalizing the path beforehand would transform path from c:\foo\bar\.. to c:\foo and c:\foo\bar\. to c:\foo/bar?

[bpasero]

@Tyriar I would trim all "." from a path on windows, but I see the issue. Why would someone actually type the full path and append ".." at the end? Is that a use case?

[Tyriar]

@bpasero regardless, it should still open the path that's provided, not the path with .'s trimmed. code foo\.. should open ., regardless of whether it's the typical use case. Example usages of where someone would want to do this:

• Opening via a script
• If they have typed a path and changed their mind, adding \.. is faster than backspacing

Not doing so will likely result in another issue down the track.

[bpasero]

@Tyriar makes sense, I am also easy leaving it without the trimming code.

[Tyriar]

I pushed another fix for #1579, I omitted the dir check, not really needed after normalizing. Needs to be verified on Windows.

[bpasero]

Thanks 👍

[bpasero]

@Tyriar with your change, opening "." or ".." on windows will result in the unexpected behaviour as before because path.normalize() will not change "." or ".." to anything.

[Tyriar]

@bpasero would joining with cwd because normalizing fix the issue?

path = path.join(process.cwd(), path)

[bpasero]

Well it might but you can only do so if the path is relative.