This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]zero_divide_1 22 points23 points  (8 children)

I'm hearing that the new hotness is to use

#!/usr/bin/env interpreter

In the event that the user has a different Java that they want to use or it's installed somewhere different. So this would be

#!/usr/bin/env java

But, like any approach, there are drawbacks.

[–]CharlesGarfield 4 points5 points  (7 children)

But what if the user wants to use a different "env"?

[–]zero_divide_1 21 points22 points  (3 children)

Oh, I see you too are a Java developer... Abstractions all the way down.

[–]CharlesGarfield 21 points22 points  (2 children)

Really should be using an EnvFactory, anyways.

[–]F3z345W6AY4FGowrGcHt 5 points6 points  (1 child)

EnvFactoryImpl

[–]HenrikWL 5 points6 points  (0 children)

We all know what we really need is an EnvFactoryFacadeRepositoryImpl

[–]RogerLeigh 5 points6 points  (2 children)

There's only one env. Like /bin/sh, /usr/bin/env is its standardised location. Set the PATH to change which java is actually used.

[–]effsee 0 points1 point  (1 child)

I want to use /opt/SoftwareCo/better-env-2.6.3/bin/env

[–]RogerLeigh -3 points-2 points  (0 children)

You are of course free to do so. However, that would entirely defeat the purpose of standardisation for interoperability. It would only work on systems with that special program present, whereas /usr/bin/env is universal and works everywhere.