Discussion has strayed off J-specific territory, so migrated here.
BTW, what "networking hardware" are you running? If the vanilla kernel has your drivers, would a rolling-release distribution like Arch, Gentoo, Void, or OpenSUSE Tumbleweed work in your use case? Heck, if you're set on Debian, then we could even get you rolling with a custom-built kernel. == Boring shebang discussion below: > > Are you able to elaborate? > > Certainly -- #!/bin/sh is about as old as unix. It's a standard part > of every unix system, even systems that went obsolete back in the > 1970s. This is not a very substantive argument. Concrete examples where a hard-coded shebang works over an env-shebang would have been helpful and instructive. As it stands, cases where /bin/sh exist but /usr/bin/env don't are quite exotic Unices these days, indeed, AFAIK. > But on my bullseye system /usr/bin/env sh finds /usr/bin/sh which is a > symlink to dash, not bash. > > But even if sometimes /usr/bin/sh was bash instead of dash, that would > be an obscure approach which would only work some of the time, leading > to a confused user base when problem solving in the context of this > issue. You seem to be misinformed. Symlinking `sh' to some other shell has been common practice for so long that bash has even hard-coded support to detect this case since esentially its inception. Invoking Bash as `sh' will put it in so-called "posix mode". In fact, you seem to be using Debian, which only started using dash as the default shell in 6.0, until then `sh' was a bash symlink. Currently, systems on which sh is still bash include CentOS, Slackware, Archlinux, etc. > > If you have concrete situations in mind that back up this statement, I'm all > > ears. In my experience, if anything it's the other way around. > > Is the above enough detail? (See first comment.) > > Really, the > > issue isn't so black and white, but for modern systems and my particular > > exposure, any problems with using /usr/bin/env have always entailed minor > > fixes, while problems with using /bin/sh usually end up requiring more > > fragile > > and/or painful workarounds. > > There would be cases where that summary could have been correct. > > This is not one of them. Please reread. My comment is neither a summary nor subject to your opinions. It is a statement of fact about my experience deploying J in several environments. Condescention aside, you are giving a flat-faced rejection to a proposal that 1. Fixes bugs adjacent to the one you experienced, 2. Introduces no regressions, 3. Is no harder to fix, and 4. Adheres to "best practices" according to in-industry opinion, which I find odd. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
