Launching program from outside it's directory causes it to fail in locating relay.jar

[ThinkDigitalSoftware]

This can cause issues when trying to write scripts that reside outside the project's directory.

$ ./gnirehtet/gnirehtet rt
Starting gnirehtet...
'adb' reverse tcp:31416 tcp:31416
'adb' shell am startservice -a com.genymobile.gnirehtet.START
Starting service: Intent { act=com.genymobile.gnirehtet.START }
'java' -jar relay.jar
Error: Unable to access jarfile relay.jar

$ cd ./gnirehtet/

$ ./gnirehtet rt
Starting gnirehtet...
'adb' reverse tcp:31416 tcp:31416
'adb' shell am startservice -a com.genymobile.gnirehtet.START
Starting service: Intent { act=com.genymobile.gnirehtet.START }
'java' -jar relay.jar
2017-04-07 12:08:07.947 I Main: Starting server...

[Zero3K]

I thought that issue was fixed in an earlier version according to the commit log.

[ThinkDigitalSoftware]

I downloaded the files about a week ago and ran them. I'm not sure if they've updated since then.

…

On Apr 9, 2017 2:36 PM, "Zero3K" ***@***.***> wrote: I thought that issue was fixed in an earlier version according to the commit log. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AV-HfWwJ1YNQ7qnVhfhk8YOVSDoADOqcks5ruU9IgaJpZM4M3SMj> .

[Zero3K]

So, you ran v1.0.1 of it?

[rom1v]

Thank you for the report. Indeed, the script assumed (for simplicity) that it was called from its own directory.

To make it callable from everywhere, we have to detect the actual directory of the script (after symlink resolution), which is unfortunately not easily done by calling commands in a portable way.

Requirements: all the following commands must work on both Linux and Mac OS.

The simple one, from the current directory:

./gnirehtet rt

By calling bash:

bash gnirehtet rt

From another directory:

gnirehtet/gnirehtet rt

From a symlink:

ln -s /the/gnirehtet/directory/gnirehtet /tmp
/tmp/gnirehtet rt

I implemented a best effort solution (53542df, not merged into master), but by default it does not work on Mac OS (it seems that brew install coreutils fixes the problem), so this would break the script even with ./gnirehtet rt for them. So I think we have to find a better solution.

[ThinkDigitalSoftware]

Isn't there a command to list current directory so you can find the jar file in there? Or, is that more of an issue with bash not providing the variable/function needed?

…

On Apr 10, 2017 3:57 AM, "Romain Vimont (®om)" ***@***.***> wrote: Thank you for the report. Indeed, the script assumed (for simplicity) that it was called from its own directory. To make it callable from everywhere, we have to detect the actual directory of the script (after symlink resolution), which is unfortunately not easily done by calling commands in a portable way. Requirements: all the following commands must work on both Linux and Mac OS. The simple one, from the current directory: ./gnirehtet rt By calling *bash*: bash gnirehtet rt From another directory: gnirehtet/gnirehtet rt From a symlink: ln -s /the/gnirehtet/directory/gnirehtet /tmp /tmp/gnirehtet rt I implemented a *best effort* solution (53542df <53542df>, not merged into master), but by default it does not work on Mac OS (it seems that brew install coreutils fixes the problem), so this would break the script even with ./gnirehtet rt for them. So I think we have to find a better solution. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AV-HfWAAYmmELuojTfr4fcyOugEa8Ct-ks5rugsIgaJpZM4M3SMj> .

[rom1v]

@ThinkDigitalRepair The problem is to determine the physical directory of gnirehtet (which is not necessarily the current directory) from the command from which the script has been called (in the variable $0).

For instance, suppose you have these files:

/home/rom/gnirehtet/gnirehtet
/home/rom/gnirehtet/gnirehtet.apk
/home/rom/gnirehtet/relay.jar

And a symlink pointing in /usr/bin, created by:

ln -s /home/rom/gnirehtet/gnirehtet /usr/bin/

Then, when you call gnirehtet or /usr/bin/gnirehtet, we have to retrieve the path /home/rom/gnirehtet to find relay.jar. In theory, this is straightforward: resolve symlinks recursively, then take the directory of the result.

The problem is to do it in a way that is:

• portable (works natively on Linux and Mac OS)
• simple (do not reimplement the whell)
• consistent (should work whether it is called from another directory and/or a symlink and/or by calling bash explicitly…)

This can cause issues when trying to write scripts that reside outside the project's directory.

Meanwhile, of course, as a workaround, you can enclose the call to gnirehtet by calls to cd:

cd /the/directory/of/gnirehtet
./gnirehtet rt
cd -

[ThinkDigitalSoftware]

Understandable. Would it be possible to encapsulate relay.jar in the gnirehtet executable? I think I used to do something similar in c++ or Java a while ago

…

On Apr 10, 2017 9:12 AM, "Romain Vimont (®om)" ***@***.***> wrote: @ThinkDigitalRepair <https://github.com/ThinkDigitalRepair> The problem is to determine the physical directory of *gnirehtet* (which is not necessarily the current directory) from the command from which the script has been called (in the variable $0). For instance, suppose you have these files: /home/rom/gnirehtet/gnirehtet /home/rom/gnirehtet/gnirehtet.apk /home/rom/gnirehtet/relay.jar And a symlink pointing in /usr/bin, created by: ln -s /home/rom/gnirehtet/gnirehtet /usr/bin/ Then, when you call gnirehtet or /usr/bin/gnirehtet, we have to retrieve the path /home/rom/gnirehtet to find relay.jar. In theory, this is straighforward: resolve symlinks recursively, then take the directory of the result. The problem is to do it in a way that is: - portable (works natively on Linux and Mac OS) - simple (do not reimplement the whell) - consistent (should work whether it is called from another directory and/or a symlink and/or by calling *bash* explicitly…) This can cause issues when trying to write scripts that reside outside the project's directory. Meanwhile, of course, as a workaround, you can enclose the call to gnirehtet by calls to cd: cd /the/directory/of/gnirehtet ./gnirehtet rt cd - — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AV-HfTGX8lJT5x227MSqRATR8ggC5k3Mks5rulTjgaJpZM4M3SMj> .

[rom1v]

Would it be possible to encapsulate relay.jar in the gnirehtet executable?

Would it be preferable to do so?

gnirehtet is just a bash script.

[ThinkDigitalSoftware]

I guess it wouldn't. Thanks for your quick responses!

…

On Apr 10, 2017 9:19 AM, "Romain Vimont (®om)" ***@***.***> wrote: Would it be possible to encapsulate relay.jar in the gnirehtet executable? Would it be preferable to do so? *gnirehtet* is just a bash script. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AV-HffyfguG0fQ4KOCV4dqd37Ibwx64_ks5rulaJgaJpZM4M3SMj> .

[ewoks]

@rom1v definitely it wouldn't be preferable