Correct shebang #99

Please see issue https://github.com/smxi/inxi/issues/98

In my opinion Fedora should patch inxi downstream instead of breaking projects for other distributions/operating systems.

I am know that use of /usr/bin/env has some advantages and disadvantages. I think it should be changed to good linux-style.

Good style is making it as portable as possible, not changing it to suit one specific Linux distribution.

OK. I already correct it in Fedora spec file. Report to you about it was my debt.

Vascom, again, as with issue 98, you need to learn about other non fedora operating systems, inxi runs on most BSDs, heck, it will even start on OSX, though it won't do much in that crippled OS, and the entire purpose of the cross platform method is to be cross platform. Also, of course, it future proofs inxi, against any possible changes to the bash path, etc. Any distro can place bash anywhere they want, and as long as they have env, it will be found without issue. This is in fact exactly why I changed that, because I test changes routinely on a FreeBSD box.

/usr/bin/env has as far as I know no disadvantages that are real or substantial, and allow all platforms to work as expected, unlike the fedora only method preferred. Since it's cross platform, it's obviously the superior method, not a bug or defect.

This seems symptomatic of a certain redhat corporate cultural blindness to all things non rpm or redhat based, and this isn't the only example I could mention, but I'll leave it at that.

It's stupid to take care of other operating systems and distributions being maintainer of Fedora. I acted according to the rules - send a bug report and patch upstream. Your right it does not take. Nor any complaints I have.

"It's stupid to take care of other operating systems and distributions being maintainer of Fedora."

Ummm, no, that's completely wrong, but as I indicated, I've seen this problem in redhat/fedora for a few years now, being unaware of external realities. Personally I'd consider that a bug to be resolved internally in the project, because the more one understands other systems, the better one tends to be oneself. if you'd like to see the counter example to that, look at for example microsoft or apple, who also follow the corporate concept you are pointing to, being unaware of all external options. Debian, for example, is extremely aware of other options.

However, don't take this wrong, while of course I won't sabotage or break inxi in order to follow a technically wrong request, I am always happy to add or improve inxi with specific requirements that help end users, or that make inxi better, more flexible, accurate, etc.

It is not problem of Fedora, but recommendation.
Also about all my changes to inxi package I should inform you so it will not surprise. For example if someone report about this changes (or make bugreport) here.

And thank you for good tool.

If your package works on redhat/fedora, then there would be no issues to report, and since changing shebang on a fedora only package would impact only redhat/fedora, and couldn't possibly fail, that's fine. If you made an actual substantive change it would be good to know about, though I've found I can usually add flags that allow features to be enabled or disabled so maintainers don't have to patch stuff every release.

If I were fedora I'd remove such non cross platform requirements from the rpmlint recommendations however, there's a LOT Of cross platform tools out there, and no reason to create obstacles for fedora package maintainers.

OK.
What about remove execute bit from inxi.changelog and README.txt files?

the execute bit? is that there, that would be a good example of something that's correct to fix, I wasn't even aware of that.

Yeah, the changelog, README, and manpage all have the exec bit set.

those are now corrected.

inxi.changelog is still has exec bit.

so it does, as well as inxi.1, for some reason cp did not copy the corrected permissions, that's now fixed, or should be.