[opensuse-factory] openSUSE:LEAP:15.1 missing dependency /usr/bin/bash for testssl.sh
Hi, not sure if this is the right place but ... I tried to install https://build.opensuse.org/package/show/network%3Autilities/testssl.sh on a Leap 15.1 box and it complained about a missing dependency on /usr/bin/bash Contrary to tumbleweed, bash in Leap 15.1 is only found at /bin/bash Ignoring the dependency and then fixing the shebang in /usr/bin/testssl.sh seems to work. Regards mararm -- A pedestal is as much a prison as any small, confined space. -- Gloria Steinem -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Freitag, 3. April 2020, 20:50:35 CEST schrieb mararm:
not sure if this is the right place but ... I tried to install https://build.opensuse.org/package/show/network%3Autilities/testssl.sh on a Leap 15.1 box and it complained about a missing dependency on /usr/bin/bash Contrary to tumbleweed, bash in Leap 15.1 is only found at /bin/bash Ignoring the dependency and then fixing the shebang in /usr/bin/testssl.sh seems to work.
Usually my recommendation would be to open a bugreport (or a submit request ;-) - the testssl.sh script needs to change the shebang to /bin/bash when built for Leap 15.x or older. However, this was so simple that I just submitted the fix myself ;-) https://build.opensuse.org/request/show/791269 Regards, Christian Boltz -- [wMware/VirtualBox] It's even better with KVM, all inside the kernel :-) at least now we can have new kind of war, emacs versus vim start to be outdated :D [Bruno Friedmann in opensuse-factory]d -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Christian, On Friday, 2020-04-03 22:15:01 CEST Christian Boltz wrote:
Contrary to tumbleweed, bash in Leap 15.1 is only found at /bin/bash Ignoring the dependency and then fixing the shebang in /usr/bin/testssl.sh seems to work.
Usually my recommendation would be to open a bugreport (or a submit request ;-) - the testssl.sh script needs to change the shebang to /bin/bash when built for Leap 15.x or older.
However, this was so simple that I just submitted the fix myself ;-) https://build.opensuse.org/request/show/791269
Thanks very much. I just had a look at the patch and it made me curious. What is wrong with #!/usr/bin/env bash as a shebang, why not keep it that way? It was exactly what I put into /usr/bin/testssl.sh ;-) Regards mararm -- Que faz o peixe, afinal?... Nada. -- Aparício Torelly, o Barão de Itararé -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Freitag, 3. April 2020, 23:42:43 CEST schrieb mararm:
On Friday, 2020-04-03 22:15:01 CEST Christian Boltz wrote:
Contrary to tumbleweed, bash in Leap 15.1 is only found at /bin/bash Ignoring the dependency and then fixing the shebang in /usr/bin/testssl.sh seems to work.
Usually my recommendation would be to open a bugreport (or a submit request ;-) - the testssl.sh script needs to change the shebang to /bin/bash when built for Leap 15.x or older.
However, this was so simple that I just submitted the fix myself ;-) https://build.opensuse.org/request/show/791269
Thanks very much.
I just had a look at the patch and it made me curious. What is wrong with #!/usr/bin/env bash as a shebang, why not keep it that way? It was exactly what I put into /usr/bin/testssl.sh ;-)
/usr/bin/env bash has some disadvantages: - it adds a level of indirection - rpm requirement autodetection "breaks" (untested guess: the package will require /usr/bin/env, but not bash) - worst: the script might get a "random" bash (possibly /usr/local/bin/ bash) which is not expected by the packaged script, and might or might not work That's why packaged scripts should avoid /usr/bin/env and have the interpreter in the shebang. (I'd have to search for it, but I'm quite sure that our packaging guidelines and/or rpmlint discourage usage of /usr/bin/env) Regards, Christian Boltz -- Nun, wenn man so einen schwachen Rechner hat, kann man halt nur einen von beiden zur Zeit laufen lassen. Man braucht trotzdem beide. Der Elektroherd wird sich ja auch nicht, blos weil nur eine Steckdose da ist, erbarmen und plötzlich zu mixen beginnen, oder? [Adalbert Michelic in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Christian, On Saturday, 2020-04-04 00:06:02 CEST Christian Boltz wrote:
What is wrong with
#!/usr/bin/env bash
as a shebang, why not keep it that way? It was exactly what I put into /usr/bin/testssl.sh ;-)
/usr/bin/env bash has some disadvantages: - it adds a level of indirection - rpm requirement autodetection "breaks" (untested guess: the package will require /usr/bin/env, but not bash) - worst: the script might get a "random" bash (possibly /usr/local/bin/ bash) which is not expected by the packaged script, and might or might not work
Ah, makes sense. Thanks for the clarification. Regards mararm -- Don't go around saying the world owes you a living. The world owes you nothing. It was here first. -- Mark Twain -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2020-04-04 00:06, Christian Boltz wrote:
/usr/bin/env bash has some disadvantages: - worst: the script might get a "random" bash (possibly /usr/local/bin/ bash) which is not expected by the packaged script, and might or might not work
That's actually not a "disadvantage". The *programmer* clearly requested a random bash - and, computers being what they are, deliver what was asked for. Garbage in, garbage out. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 04.04.20 um 08:38 schrieb Jan Engelhardt:
On Saturday 2020-04-04 00:06, Christian Boltz wrote:
/usr/bin/env bash has some disadvantages: - worst: the script might get a "random" bash (possibly /usr/local/bin/ bash) which is not expected by the packaged script, and might or might not work
That's actually not a "disadvantage". The *programmer* clearly requested a random bash - and, computers being what they are, deliver what was asked for. Garbage in, garbage out.
And it actually lets the admin take control by putting the bash he likes most further up $PATH, so I personally think it would be much better fixing rpm dependency scanners instead of forbidding usage of env. But another, related question: Why would anyone ever put /usr/bin/bash into a script shebang? The /bin/bash symlink certainly is there to stay forever. So just using "#!/bin/bash" is not going to break anytime soon... -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2020-04-04 10:00, Stefan Seyfried wrote:
Am 04.04.20 um 08:38 schrieb Jan Engelhardt:
On Saturday 2020-04-04 00:06, Christian Boltz wrote:
/usr/bin/env bash has some disadvantages: - worst: the script might get a "random" bash (possibly /usr/local/bin/ bash) which is not expected by the packaged script, and might or might not work
That's actually not a "disadvantage". The *programmer* clearly requested a random bash - and, computers being what they are, deliver what was asked for. Garbage in, garbage out.
And it actually lets the admin take control by putting the bash he likes
I had hoped you recognized the joke here. As a sensible programmer, I would not want non-deterministic behavior in my program. I want the one true bash that behaves the same everywhere, not something the admin likes. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Samstag, 4. April 2020, 10:32:56 CEST schrieb Jan Engelhardt:
On Saturday 2020-04-04 10:00, Stefan Seyfried wrote:
Am 04.04.20 um 08:38 schrieb Jan Engelhardt:
On Saturday 2020-04-04 00:06, Christian Boltz wrote:
/usr/bin/env bash has some disadvantages: - worst: the script might get a "random" bash (possibly /usr/local/bin/
bash) which is not expected by the packaged script, and might or might not work
That's actually not a "disadvantage". The *programmer* clearly requested a random bash - and, computers being what they are, deliver what was asked for. Garbage in, garbage out.
And it actually lets the admin take control by putting the bash he likes
I had hoped you recognized the joke here.
As a sensible programmer, I would not want non-deterministic behavior in my program. I want the one true bash that behaves the same everywhere, not something the admin likes.
Hey, *non deterministic* behavior is not an disadvantage. It boldly imitates how our world ticks at the moment, and that's been called the SNAFU principle. In fact, /usr/bin/env appears to be *too* deterministic to cope with this. This is further complicated by the shebang single argument limit. So, what's missing is a tool that selects a *real* *random* executable to replace /usr/ bin/env, but that tool should take care of selecting a high quality entropy source. Not sure, if the latest Linux kernel modifications are sufficient in this regard, though. SCR, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Apr 4 11:22 Hans-Peter Jansen wrote (excerpt):
Am Samstag, 4. April 2020, 10:32:56 CEST schrieb Jan Engelhardt:
On Saturday 2020-04-04 10:00, Stefan Seyfried wrote:
Am 04.04.20 um 08:38 schrieb Jan Engelhardt:
On Saturday 2020-04-04 00:06, Christian Boltz wrote:
/usr/bin/env bash has some disadvantages: - worst: the script might get a "random" bash (possibly /usr/local/bin/ bash) which is not expected by the packaged script, and might or might not work
That's actually not a "disadvantage". The *programmer* clearly requested a random bash - and, computers being what they are, deliver what was asked for. Garbage in, garbage out.
And it actually lets the admin take control by putting the bash he likes
I had hoped you recognized the joke here.
As a sensible programmer, I would not want non-deterministic behavior in my program. I want the one true bash that behaves the same everywhere, not something the admin likes.
Hey, *non deterministic* behavior is not an disadvantage. It boldly imitates how our world ticks at the moment, and that's been called the SNAFU principle.
Perhaps you confuse non deterministic behavior with non predictable (unpredictable) behaviour? When you introduce real random you get non deterministic behavior. But I think how nowadays computers often behave is unpredictable where unpredictable behaviour means what the user perceives. Of course for computer experts things are perfectly predictable because they always predict the unpredictable ;-) By the way: I think the topmost root cause for unpredictable behaviour is RFC 1925 item 6a: "It is always possible to add another level of indirection." I think most issues that are called "bugs" nowadays are in the end unpredictable behaviour (for the user) so RFC 1925 item 6a is the topmost root cause for bugs. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 4 Apr 2020 10:00:59 +0200, Stefan Seyfried
Am 04.04.20 um 08:38 schrieb Jan Engelhardt:
On Saturday 2020-04-04 00:06, Christian Boltz wrote:
/usr/bin/env bash has some disadvantages: - worst: the script might get a "random" bash (possibly /usr/local/bin/ bash) which is not expected by the packaged script, and might or might not work
That's actually not a "disadvantage". The *programmer* clearly requested a random bash - and, computers being what they are, deliver what was asked for. Garbage in, garbage out.
And it actually lets the admin take control by putting the bash he likes most further up $PATH, so I personally think it would be much better fixing rpm dependency scanners instead of forbidding usage of env.
But another, related question:
Why would anyone ever put /usr/bin/bash into a script shebang?
Because I have to (also) work on extremely old and sometime non-POSIX compliant boxes that do not even have bash installed. I sometimes need #!/bin/sh and sometimes #!/usr/bin/sh I put #!/usr/bin/bash on the she-bang to make the script unable to execute on systems that do not have bash, and "which bash" shows me /usr/bin/bash. That is why.
The /bin/bash symlink certainly is there to stay forever. So just using "#!/bin/bash" is not going to break anytime soon...
-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
participants (7)
-
Christian Boltz -
H.Merijn Brand -
Hans-Peter Jansen -
Jan Engelhardt -
Johannes Meixner -
mararm -
Stefan Seyfried