A symbolic link in /usr/bin/ is not a binary in /usr/bin/ See also: /etc/alternatives/ (though that full abstraction is not needed when the symbolic link is managed manually).
-- Raul On Sat, Mar 11, 2023 at 4:21 AM Elijah Stone <elro...@elronnd.net> wrote: > > I don't think mandating that binaries be placed in /usr/bin is a de facto > standard; and I have never heard of anybody's doing it. I have, once again, > heard of systems which specifically avoid touching /usr/bin. Here is another > example: the brew package manager on macos installs everything into > /opt/homebrew, to avoid touching any part of the system as a whole (since it > is a third-party package manager). Users are expected to update their path > _once_ to include /opt/homebrew/bin, and can then pick up anything they > install through brew without additional effort. > > On Sat, 11 Mar 2023, Raul Miller wrote: > > > In my opinion, a symbolic link at /usr/bin/ijconsole would be no more > > of an imposition than #!/usr/bin/env jconsole (and in many cases it > > would be less of an imposition). > > > > (0) Sadly, neither approach works for the windows cmd environment > > (though either approach would work under cygwin or wsl). > > > > (1) Neither approach cares much about where J is installed. > > > > (2) Both approaches correspond to "defacto standards" (the "nice" > > thing about standards is that there are so many to choose from). > > > > (3) The /usr/bin/env approach requires a PATH update in typical cases, > > while the symbolic link approach does not. > > > > (4) We already have an installed base with /usr/bin/ijconsole > > > > (5) #!/usr/bin/env jconsole won't work for installs where the > > executable is named ijconsole > > > > That said, for now, it's just a small paragraph of documentation -- a > > recommendation for some people to use at install time. > > > > Thanks, > > > > -- > > Raul > > > > On Sat, Mar 11, 2023 at 2:41 AM Elijah Stone <elro...@elronnd.net> wrote: > >> > >> I don't think anyone has proposed a tool like virtualenv, so I don't see > >> how > >> that's relevant. And I don't see why we should make impositions on the way > >> anyone chooses to package j. > >> > >> On Fri, 10 Mar 2023, Raul Miller wrote: > >> > >> > Yes, PATH is the only environmental variable that influences how > >> > /usr/bin/env finds the executable. > >> > > >> > But I was talking about tools like > >> > https://pypi.org/project/virtualenv/ where there's other things going > >> > on. > >> > > >> > That said, you are correct that there are some systems which install > >> > optional software to /usr/local/bin/, and I had forgotten about those. > >> > That said... I don't think there's any significant permissions > >> > problems involved in installing in /usr/bin on bsd systems. As I > >> > understand it, that's /usr/bin/env bash is a historical issue (and, > >> > thus, a backwards compatibility issue). > >> > > >> > Thanks, > >> > > >> > -- > >> > Raul > >> > > >> > On Fri, Mar 10, 2023 at 8:20 PM Elijah Stone <elro...@elronnd.net> wrote: > >> >> > >> >> > /usr/bin/env is the standard for developer systems where different > >> >> > configurations are managed through environmental variables. However, > >> >> > it's > >> >> > rather fragile for non-developers, as it requires properly conditioned > >> >> > environmental variables. > >> >> > >> >> This statement confuses me greatly. Can you elaborate? I think the > >> >> only > >> >> environment variable which is relevant is PATH, and PATH will certainly > >> >> contain /usr/bin. So if PATH contains /usr/bin, and there is a > >> >> /usr/bin/ijconsole, then #!/usr/bin/env ijconsole will do the right > >> >> thing. If > >> >> ijconsole is somewhere other than /usr/bin, and it is in PATH, then > >> >> #!/usr/bin/env ijconsole will pick it up, but #!/usr/bin/ijconsole will > >> >> not. > >> >> So using /usr/bin/env is strictly less fragile. > >> >> > >> >> Using /usr/bin/env is standard for scripts. /usr/bin/ijconsole entails > >> >> _strictly_ more fuss, more fragility, and less portability. > >> >> > >> >> An example: on many BSD systems, bash does not come with the base > >> >> system, but > >> >> is rather provided as a separate package, so it is placed in > >> >> /usr/local/bin. > >> >> Some scripts developed on linux are distributed that use #!/bin/bash, > >> >> and this > >> >> breaks on BSD systems because there is on bash in /bin; when those > >> >> scripts use > >> >> #!/usr/bin/env bash instead, they work. > >> >> > >> >> On Fri, 10 Mar 2023, Raul Miller wrote: > >> >> > >> >> > > >> >> > /usr/bin/$name is the earlier standard for minimal fuss distribution. > >> >> > > >> >> > Given that most J users are going to be in some IDE, I don't see that > >> >> > the /usr/bin/env approach would provide significant benefit to the J > >> >> > community. Especially if we're considering people who would be baffled > >> >> > about what to do with #!/usr/bin/ijconsole > >> >> > > >> >> > Do you think I've overlooked something important here? > >> >> > > >> >> > Thanks, > >> >> > > >> >> > -- > >> >> > Raul > >> >> > > >> >> > On Fri, Mar 10, 2023 at 7:42 PM Elijah Stone <elro...@elronnd.net> > >> >> > wrote: > >> >> >> > >> >> >> Performance is irrelevant here--the difference in either case is > >> >> >> miniscule. > >> >> >> > >> >> >> Using /usr/bin/env is standard practice in shebangs for finding > >> >> >> binaries on > >> >> >> the path. In some systems, it is conventional to put binaries that > >> >> >> did not > >> >> >> come with the system in /usr/local/bin, or in /opt; whereas, the > >> >> >> existence of > >> >> >> /usr/bin/env is mandated by posix. We should not presume any more > >> >> >> than we > >> >> >> need to about the way a user's system will be organised. > >> >> >> > >> >> >> On Fri, 10 Mar 2023, Raul Miller wrote: > >> >> >> > >> >> >> > Yes, the name ijconsole (iverson j console) was adopted to work > >> >> >> > around > >> >> >> > java's jconsole being in $PATH on many systems. > >> >> >> > > >> >> >> > This would also be an issue with /usr/bin/env > >> >> >> > > >> >> >> > But I don't see any high priority problems with /usr/bin/ijconsole > >> >> >> > as > >> >> >> > a standard location. There will be some users who cannot install J > >> >> >> > there, but it should be simple enough for them to build a tool to > >> >> >> > patch incoming J scripts with the install location that they used. > >> >> >> > > >> >> >> > (And, /usr/bin/env is going to be considerably slower than a bit of > >> >> >> > undefined verb parsing and garbage collection within J.) > >> >> >> > > >> >> >> > -- > >> >> >> > Raul > >> >> >> > > >> >> >> > On Fri, Mar 10, 2023 at 6:51 PM Elijah Stone <elro...@elronnd.net> > >> >> >> > wrote: > >> >> >> >> > >> >> >> >> Fair enough. I think the obvious thing is #!/usr/bin/env > >> >> >> >> jconsole. But I > >> >> >> >> gather 'jconsole' is also the name of a java-related program, > >> >> >> >> which might be > >> >> >> >> why debian uses 'ijconsole' (and I think I have seen 'jc' > >> >> >> >> elsewhere--probably > >> >> >> >> for the same reason). I therefore propose: > >> >> >> >> > >> >> >> >> 1. Rename jconsole to something which doesn't collide with > >> >> >> >> anything heretofore > >> >> >> >> notable > >> >> >> >> > >> >> >> >> 2. Use #!/usr/bin/env that-something > >> >> >> >> > >> >> >> >> On Fri, 10 Mar 2023, Raul Miller wrote: > >> >> >> >> > >> >> >> >> > Perhaps, but I think it would be more useful to have a portable, > >> >> >> >> > agreed on path for systems which support the #! convention. > >> >> >> >> > > >> >> >> >> > That's required for J scripts to be distributable. > >> >> >> >> > > >> >> >> >> > Thanks, > >> >> >> >> > > >> >> >> >> > -- > >> >> >> >> > Raul > >> >> >> >> > > >> >> >> >> > On Fri, Mar 10, 2023 at 12:04 AM Elijah Stone > >> >> >> >> > <elro...@elronnd.net> wrote: > >> >> >> >> >> > >> >> >> >> >> Perhaps it's simply time to tell the interpreter to start > >> >> >> >> >> ignoring the first > >> >> >> >> >> line of a script if it starts with #!... > >> >> >> >> >> > >> >> >> >> >> On Thu, 9 Mar 2023, Raul Miller wrote: > >> >> >> >> >> > >> >> >> >> >> > The recent change in directory naming from j903 to j9.4 > >> >> >> >> >> > introduces an > >> >> >> >> >> > interesting issue for shell scripts on unix-like systems. > >> >> >> >> >> > > >> >> >> >> >> > In J shell scripts, this works: > >> >> >> >> >> > > >> >> >> >> >> > #!/home/username/j903/bin/jconsole > >> >> >> >> >> > > >> >> >> >> >> > However, this fails with a spelling error: > >> >> >> >> >> > > >> >> >> >> >> > #!/home/username/j9.4/bin/jconsole > >> >> >> >> >> > > >> >> >> >> >> > Or, on OSX, the shebang line is different, but the spelling > >> >> >> >> >> > error remains: > >> >> >> >> >> > > >> >> >> >> >> > #!/Applications/j9.4/bin/jconsole > >> >> >> >> >> > > >> >> >> >> >> > That said, there's some other issues here, related to > >> >> >> >> >> > portability. One > >> >> >> >> >> > of which is that (as a general rule) a home directory is > >> >> >> >> >> > personal > >> >> >> >> >> > rather than portable. Another is that there's official java > >> >> >> >> >> > jconsole > >> >> >> >> >> > which does not understand J. > >> >> >> >> >> > > >> >> >> >> >> > But, also, for a long time now, Debian based distributions > >> >> >> >> >> > have been > >> >> >> >> >> > distributing j with /usr/bin/ijconsole as a symbolic link to > >> >> >> >> >> > the > >> >> >> >> >> > current installed location for J. (Here, the 'i' in > >> >> >> >> >> > ijconsole stands > >> >> >> >> >> > for Iverson.) > >> >> >> >> >> > > >> >> >> >> >> > So I think that now would be a good time to adopt that as > >> >> >> >> >> > "documented > >> >> >> >> >> > standard practice" for j shell scripts. > >> >> >> >> >> > > >> >> >> >> >> > FYI, > >> >> >> >> >> > > >> >> >> >> >> > -- > >> >> >> >> >> > Raul > >> >> >> >> >> > ---------------------------------------------------------------------- > >> >> >> >> >> > For information about J forums see > >> >> >> >> >> > http://www.jsoftware.com/forums.htm > >> >> >> >> >> ---------------------------------------------------------------------- > >> >> >> >> >> For information about J forums see > >> >> >> >> >> http://www.jsoftware.com/forums.htm > >> >> >> >> > ---------------------------------------------------------------------- > >> >> >> >> > For information about J forums see > >> >> >> >> > http://www.jsoftware.com/forums.htm > >> >> >> >> ---------------------------------------------------------------------- > >> >> >> >> For information about J forums see > >> >> >> >> http://www.jsoftware.com/forums.htm > >> >> >> > ---------------------------------------------------------------------- > >> >> >> > For information about J forums see > >> >> >> > http://www.jsoftware.com/forums.htm > >> >> >> ---------------------------------------------------------------------- > >> >> >> For information about J forums see > >> >> >> http://www.jsoftware.com/forums.htm > >> >> > ---------------------------------------------------------------------- > >> >> > For information about J forums see http://www.jsoftware.com/forums.htm > >> >> ---------------------------------------------------------------------- > >> >> For information about J forums see http://www.jsoftware.com/forums.htm > >> > ---------------------------------------------------------------------- > >> > For information about J forums see http://www.jsoftware.com/forums.htm > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
