ibracorp is a great resource for the homelab and self-hosting community. I have found their discord community to be especially welcome and helpful to anyone getting started.
Your last line was very dismissive, and the first ones were a minor detail. If you had just said it as a helpful suggestion to improve compatibility, it would have been fine. Had you dismissed it because of something fundamental to the project's goals, it would probably have been fine.
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
I can see someone interpreting your argument as "shallow," at least in the sense that the project overall may still be useful. Or it might be a good start, or they need your help to improve.
Also:
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
(And I say this as someone who, just this week, forgot to change #!/bin/sh to #!/bin/bash when I started adding Bash-specifics to a script.)
If not an issue to show the own research about the points in the project first or asking for understanding in context. But that's perhaps how grown ups would do it. Some just want to have the argument to show they know better (but only presenting how little their knowledge is).
Seems to be a growing trend lately to confuse objectively and subjectively. There's no universal law of nature that says shell scripts must be named a certain way, or contain exactly a certain shebang among several alternatives. These are just people's opinions, which by definition are subjective.
And anyway I've been writing shell scripts for over two decades and can't remember the last time I've seen foo.bash, if I've ever seen it at all.
Objective truth is one (albeit important) aspect of communication.
Try to say it in a nice manner. Please consider making a PR or GitHub issue instead. Being civil makes people thrive, and easier accepting your feedback.
Don't get me wrong: I often make the same mistake you made. Its a continuing learning process, and being on the spectrum doesn't help (at least, in my case not).
Agree. I come across this all the time from people who should know better. Furthermore, eventually the actions taken by that file will outgrow bash, so if you wanted to replace it with something written in python (for example), you could with no loss of naming integrity.
> I agree that the shebang should be #!/usr/bin/env bash though.
That's not at all a given.
This will use the first "bash" that it comes across, which has its good and bad points, while `#!/bin/bash` will use that specific one (if it exists). If J. Random User has been manipulated into installing a fake bash (or if the package installer or whatever has installed a fake bash) somewhere in his path, the env method can be very bad indeed. In general, that's going to be a far easier thing to do than installing a fake bash in /bin.
In general, /bin/bash is gonna work fine, either because that's where it actually is (the overwhelming majority of *nix systems in use today, including most or all Linuxes and macOS), or the system and/or system administrator has created a link from /bin/bash to where it's actually located.
It doesn't really gain you a whole lot anyway. If there's no guarantee that bash is located at /bin/bash, there's even less of a guarantee that env is located at /usr/bin/env.
> If there's no guarantee that bash is located at /bin/bash, there's even less of a guarantee that env is located at /usr/bin/env.
i've seen way more systems that don't have a global /bin/bash than systems that don't have a /usr/bin/env
as an example, /bin/bash on macos is forever stuck at version 3.2.something, if i run across a bash script that uses crazy features like associative arrays, i definitely want it to use the modern version of bash i've installed to my $HOME/bin/bash
What is this exactly? I have clues from the site but can't seem to bring it quite together. A script to deploy a curated selection of apps or tools in containers to... local home pcs? Who is the target audience? What's the value proposition exactly?
I'm not being dismissive, but looking at the code doesn't inspire confidence. There are several minor point but the major one for me is that several variables are not quoted which will create problems sooner or later. It really should be fixed.
or to lower the burden of the previous poster who may be expecting quotes always (as it otherwise requires more concentration in review - which would produce details I'm missing in the previous original comment btw):
why selling this? i read on the code it is using ruby a lot, also better to use caprover instead, it is really open source and easy to use both command line and web based UI,
I couldn't find a list of applications it supports. That would be the first thing I'd want to know, because if major apps I'm wanting are missing it's a non starter.
Any reason to use this instead of Ansible?
The video shows that this package or script needs to be transported to the host machine before it could be executed or perhaps I understood it wrong.
(Edit)
So, I checked out the repository, I personally wouldn't use it or recommend it to anyone. It's a collection of bash scripts, it'd be a pain to debug, log and fix. Ansible playbooks are a much better option. You should be able to version control your deployments and configurations these days.
It looks like a much more specialized system than Ansible in this case.
More specialized systems may bring the burden that they are harder to debug (Ansible is also astonishing hard to read the debugs' -vvv output btw.) but with the benefit to be better suited for the specialized job.
And as long as you've got the sources, you can easily put it under version control. I fail to see why this should be only possible with python scripts and yaml files and not with shell scripts.
so i have to use a menu, to select a dozen things to setup a single system, with the non changeable defaults, they will select for me.
(why would i install node, or dos2unix or midnight commander?)
and they install as default ruby, which most of use don't use at all so giving us bloat for not much function.
it writes its alias in the global space instead of the local user
echo $insert_alias | sudo tee -a /etc/bash.bashrc
This feels like a tool for users switching from windows to linux, to be able to flatten the learning curve. For any user that is a little bit familiar with linux, this i a major downgrade to any other toolset IMO.
i would open an issue, but they don't offer that on the repo
to post feedback you have to register with a service called "Canny"
the other issues channel is discord
a few suggestions:
- run shellcheck and fix the issues and warnings
- publish tags, so people can select versions
- add customization to the installed packages
- actually document how to use the parameters, the scripts offer, instead of just not doing that
- add an uninstall script!
- add a silent command (run with parameters to automate the menu selects, why would i want to do this manually or remember what i selected on every machine?)
I mean its free and all, but reads like a product, which needs a developer who cares about a few industry standards, or just needs more time (first code commit was on Nov 27, 2022
Sounds like it fits their needs, but ansible sounds like a much better choice and also sounds like they have the "not invented here" problem
What a review! First I thought it was kinda TUI builder then maybe Ansible replacement. After you wrote about midnight commander dependency I have no idea what it is...
38 comments
[ 2.9 ms ] story [ 107 ms ] threadhttps://ibramenu.io
and your shebang line should be `#!/usr/bin/env bash`, not `#!/bin/bash`
the current state of your project does not inspire confidence
everything i've said here is objectively true
From https://news.ycombinator.com/newsguidelines.html:
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
I can see someone interpreting your argument as "shallow," at least in the sense that the project overall may still be useful. Or it might be a good start, or they need your help to improve.
Also:
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
(And I say this as someone who, just this week, forgot to change #!/bin/sh to #!/bin/bash when I started adding Bash-specifics to a script.)
so IMHO barking the wrong tree.
And anyway I've been writing shell scripts for over two decades and can't remember the last time I've seen foo.bash, if I've ever seen it at all.
Try to say it in a nice manner. Please consider making a PR or GitHub issue instead. Being civil makes people thrive, and easier accepting your feedback.
Don't get me wrong: I often make the same mistake you made. Its a continuing learning process, and being on the spectrum doesn't help (at least, in my case not).
I agree that the shebang should be #!/usr/bin/env bash though.
That's not at all a given.
This will use the first "bash" that it comes across, which has its good and bad points, while `#!/bin/bash` will use that specific one (if it exists). If J. Random User has been manipulated into installing a fake bash (or if the package installer or whatever has installed a fake bash) somewhere in his path, the env method can be very bad indeed. In general, that's going to be a far easier thing to do than installing a fake bash in /bin.
In general, /bin/bash is gonna work fine, either because that's where it actually is (the overwhelming majority of *nix systems in use today, including most or all Linuxes and macOS), or the system and/or system administrator has created a link from /bin/bash to where it's actually located.
It doesn't really gain you a whole lot anyway. If there's no guarantee that bash is located at /bin/bash, there's even less of a guarantee that env is located at /usr/bin/env.
/bin/bash is not reliably present -- there is no guarantee that bash exists on a system at all, really!
It doesn't have to be in /usr/bin.
some ancient rhel systems put it in /bin/env, i believe, but in that case they usually symlink /usr/bin/env to it, or /usr/bin to /bin at least
i've seen way more systems that don't have a global /bin/bash than systems that don't have a /usr/bin/env
as an example, /bin/bash on macos is forever stuck at version 3.2.something, if i run across a bash script that uses crazy features like associative arrays, i definitely want it to use the modern version of bash i've installed to my $HOME/bin/bash
[0] https://ericaheinz.com/notes/give-it-the-craigslist-test/
It's a trusted, proven system, that's free and open source and is easy to use. It's truly an endlessly scalable thing.
See also other subcomments.
Not exactly putting key information front and centre.
(Edit) So, I checked out the repository, I personally wouldn't use it or recommend it to anyone. It's a collection of bash scripts, it'd be a pain to debug, log and fix. Ansible playbooks are a much better option. You should be able to version control your deployments and configurations these days.
More specialized systems may bring the burden that they are harder to debug (Ansible is also astonishing hard to read the debugs' -vvv output btw.) but with the benefit to be better suited for the specialized job.
And as long as you've got the sources, you can easily put it under version control. I fail to see why this should be only possible with python scripts and yaml files and not with shell scripts.
it writes its alias in the global space instead of the local user
echo $insert_alias | sudo tee -a /etc/bash.bashrc
This feels like a tool for users switching from windows to linux, to be able to flatten the learning curve. For any user that is a little bit familiar with linux, this i a major downgrade to any other toolset IMO.
i would open an issue, but they don't offer that on the repo
to post feedback you have to register with a service called "Canny"
the other issues channel is discord
a few suggestions:
- run shellcheck and fix the issues and warnings
- publish tags, so people can select versions
- add customization to the installed packages
- actually document how to use the parameters, the scripts offer, instead of just not doing that
- add an uninstall script!
- add a silent command (run with parameters to automate the menu selects, why would i want to do this manually or remember what i selected on every machine?)
I mean its free and all, but reads like a product, which needs a developer who cares about a few industry standards, or just needs more time (first code commit was on Nov 27, 2022
Sounds like it fits their needs, but ansible sounds like a much better choice and also sounds like they have the "not invented here" problem