5 ms·

if you're using bash your file extension should be .bash, not .sh and your shebang line should be `#!/usr/bin/env bash`, not `#!/bin/bash` the current state o

if you're using bash your file extension should be .bash, not .sh and your shebang line should be `#!/usr/bin/env bash`, not `#!/bin/bash` the current state of your project does not inspire confidence

preseinger 3y ago
i am not sure why anyone would downvote this comment everything i've said here is objectively true
- tommiegannert 3y ago
  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. From https://news.ycombinator.com/newsguidelines.html 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.)
- hakre 3y ago
  this is a pure code style issue, with the twist you're not aware of code-style. so IMHO barking the wrong tree.
  - Turing_Machine 3y ago
    Yes. The constructive way of dealing this (IMO very minor) issue would be to open a PR, not being publicly dismissive.
    - hakre 3y ago
      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).
- bityard 3y ago
  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.
- Fnoord 3y ago
  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).
kwhitefoot 3y ago
Why do they need a file extension at all? The extension doesn't mean anything to the system. I agree that the shebang should be #!/usr/bin/env bash though.
- gjvc 3y ago
  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.
- Turing_Machine 3y ago
  > 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.
  - preseinger 3y ago
    /usr/bin/env is reliably present -- a system without this executable is basically non-functional, right? /bin/bash is not reliably present -- there is no guarantee that bash exists on a system at all, really!
    - Turing_Machine 3y ago
      > /usr/bin/env is reliably present -- a system without this executable is basically non-functional, right? It doesn't have to be in /usr/bin.

preseinger 3y ago

i am not sure why anyone would downvote this comment everything i've said here is objectively true

tommiegannert 3y ago
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. From https://news.ycombinator.com/newsguidelines.html 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.)
hakre 3y ago
this is a pure code style issue, with the twist you're not aware of code-style. so IMHO barking the wrong tree.
- Turing_Machine 3y ago
  Yes. The constructive way of dealing this (IMO very minor) issue would be to open a PR, not being publicly dismissive.
  - hakre 3y ago
    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).
bityard 3y ago
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.
Fnoord 3y ago
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).

kwhitefoot 3y ago

Why do they need a file extension at all? The extension doesn't mean anything to the system. I agree that the shebang should be #!/usr/bin/env bash though.

gjvc 3y ago
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.
Turing_Machine 3y ago
> 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.
- preseinger 3y ago
  /usr/bin/env is reliably present -- a system without this executable is basically non-functional, right? /bin/bash is not reliably present -- there is no guarantee that bash exists on a system at all, really!
  - Turing_Machine 3y ago
    > /usr/bin/env is reliably present -- a system without this executable is basically non-functional, right? It doesn't have to be in /usr/bin.