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
