Path translation

[AgentOak]

Hi,

I'm running RunInBash 0.1 on Windows 10 x64 1803.

I've created a php.bat containing

@echo off

set cmd=%~n0
$ %cmd% %*

in my PATH and I'm able to run basic php commands.

However, neither relative nor absolute paths are recognized and translated:

C:\Users\Me>php Documents\Projects\test.php
Could not open input file: DocumentsProjectstest.php

C:\Users\Me>php C:\Users\Me\Documents\Projects\test.php
Could not open input file: C:UsersMeDocumentsProjectstest.php

Would it be possible to add an option to have paths translated?

Thanks

[mqudsi]

I actually have a local branch of RunInBash going that does just that, mapping drives to /mnt/foo (by convention, not by mounttab) but at the cost of sometimes mistakenly translating \ when it shouldn't be, e.g. $ printf "\thello" > foo.txt (regardless of whether the quotes are there or not, and didn't know whether it was worth making that the new default or not.

[mqudsi]

Can you try this build?

RunInBash.zip

[AgentOak]

Thank you! This seems to be working quite well, I haven't encountered any edge cases in real usage so far.

Doing some specific tests I think the path recognition might be a bit too aggressive (Documents\dev exists):

C:\Users\Me>$ echo "Documents.\dev"
./Documents/dev

C:\Users\Me>$ echo I like Documents...
I like ./Documents

C:\Users\Me>$ echo "Documents\/\/dev"
./Documents/dev

Looks like it ignores dots at the end of names, even in the middle of a path.

In the second example I don't think Documents needs to be translated; if Documents was actually meant as a path, it should work fine even without prefixing ./? My suggestion would be to only attempt translation if the string contains at least one (back)slash.

Regarding the last one I think it's fine leaving it as is, mixed-slashes are very useful when working with Windows and Linux at the same time.

Whether you want to adjust this or not, I'd be fine with marking this issue as solved, since it works well enough for me.