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
