6 ms·

Hey, original author here. Thanks for sharing this and making it rise to the front page! :) By the way, the title probably deserves a (2020) and it would be nic

by jmmv 3y ago

Hey, original author here. Thanks for sharing this and making it rise to the front page! :) By the way, the title probably deserves a (2020) and it would be nice if "test" wasn't capitalized, because it actually refers to the command. Here is something related from 2021 that also touches on bash's [[ operator and that I think you might enjoy in this context: https://jmmv.dev/2021/08/useless-use-of-gnu.html https://jmmv.dev/2021/08/useless-use-of-gnu.html

o11c 3y ago
[[ is not really a builtin, it's fundamentally syntactical (but presumably uses a mostly-inaccessible builtin internally). Fun fact, `]]` is also a reserved word despite never being allowed in a context where reserved words matter. In some non-bash shells, the `function` keyword is needed to declare certain types of function. For make `$(shell)`, if you're building a lot of targets the performance difference can be measurable. Still, it loses in the nop case, so you should actually usually do `include` to trigger re-making. GNU is completely right to ignore POSIX, since POSIX is not useful for solving most real problems.
- account42 3y ago
  > In some non-bash shells, the `function` keyword is needed to declare certain types of function. In shells that aren't POSIX-compliant [0], maybe. In which case: yes, there are many wildly different scripting languages with REPLs. [0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_05 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
- pmarreck 3y ago
  > since POSIX is not useful for solving most real problems POSIX, being a standard that can be tested, is at least a specification or agreement that can be met by multiple products to enable them to interact
dang 3y ago
Ok, I've lowercased the leading 't'. We never do that but for this, ok :)
- edanm 3y ago
  As per the Zen of Python: > Special cases aren't special enough to break the rules. > Although practicality beats purity. :)
- deleted 3y ago
  [deleted]
gnfargbl 3y ago
This article complains that using the extended GNU features (--ignore-case, set -o pipefail etc) makes scripts less portable. Fair enough. What it doesn't explain is why a Linux user should much care about portability. OpenBSD and FreeBSD are alive and well, but the number of users seems so small that they aren't a particular concern. Maybe you could argue that we "should" consider these OSes out of a sense of fairness, but where does that stop? Do I also need to consider something obscure like vxWorks? BusyBox (Alpine) is more interesting, but the changes there are so significant that a port will almost always be needed anyway. Are there other compelling reasons to care about the non-GNU ecosystem?
- kqr 3y ago
  Is your comment best read in Internet Explorer 6? ---- What I'm trying to say is that open standards (and the portability that comes with them) is not something that just happens on its own. It takes active maintenance, and part of that maintenance is opting to adhere to the standard even when it would be more convenient to use extensions available in the most popular systems. Will you personally suffer from liberally using Bashisms? Not in the first order. But if we encourage that sort of thinking as a rule, the standards become meaningless. I believe that would be a net negative change for the world, but there are many intelligent people who would disagree.
  - dspillett 3y ago
    I don't disagree with you in the context of public scripts, but the vast majority of what I do with bash is local-only (where local is ${DayJob} and my own infrastructure/projects) so the fact that extensions to the standard make my work in those areas quicker to string together and easier to maintain afterwards means I'm happy to lock myself into bash. From my PoV it is generally portable anyway: almost everywhere I use a shell of that nature bash is present. The exceptions to this are things that need to run in small environments, like anything which may end up in initrd (where busybox us generally providing shell/script support). Though I do wish people would make sure they specify bash in the #!/bin/bash in scripts unless trying to stick to the standard, as using #!/bin/sh causes problems when extensions are used and something lighter than bash is the default script runner (i.e. dash in Debian, and again busybox commonly in small environments). Only use #!/bin/sh if you lnow you are making an effort to be compliant.
account42 3y ago
A lot of the GNUisms described in https://jmmv.dev/2021/08/useless-use-of-gnu.html https://jmmv.dev/2021/08/useless-use-of-gnu.html are very useful in interactive use. Search the current directory without an explcit . - useful. Append an option to a command you just typed - heck yeah, always annoyed when commands don't support that. For scripts though, sticking to POSIX sh often makes sense, yeah. You should at least be aware if you use of Bash-isms.
a1369209993 3y ago
> https://jmmv.dev/2021/08/useless-use-of-gnu.html https://jmmv.dev/2021/08/useless-use-of-gnu.html Tangential, but your blog software seems to have mangled the headings; it's serving eg: make $(shell &mldr;) expansion instead of make $(shell ...) expansion (note that (as is correctly written in the body) that's three pediods, not one elipsis, so mldr wouldn't be correct even on it's own, meaning there's two probably-unrelated bugs affecting it).
- jmmv 3y ago
  Hmm… I’ll have to check later but right now I’m seeing the right thing in iOS. The blog is built by Hugo, so it’s all static files. But maybe something changed with the latest update. Thanks.
  - a1369209993 3y ago
    Just checked again with curl|grep, and now I'm getting: <h1 id=make-shell--expansion>make $(shell &mldr;) expansion</h1> as the actual bytes-on-the-wire, which is still wrong, but only in one way rather than two. (Note: iOS probably displays &mldr; as U+2026 "…", which often looks identical to "...", but is actually a single non-ASCII character.)
    - opello 3y ago
      The rabbit hole of why "mldr" (em length leader) is a thing vs. "hellip" (horizontal ellipsis) was pretty disappointing. I only decoded "mldr" and didn't find much in the way of an explanation for why both entities exist. I assume there's some semantic reason in which each is appropriate. I don't know what it is and am curious though!
  - jasonpbecker 3y ago
    These are default for Hugo parsing of Markdown—- https://gohugo.io/getting-started/configuration-markup/ https://gohugo.io/getting-started/configuration-markup/
hwc 3y ago
if [ a = b ] || grep -q ^hello$ /usr/share/dict/words; then echo "test failed and grep succeeded" fi > “You pick whether to be amused or horrified. I don’t know how exactly my coworker reacted when I hinted at this during a recent code review I did for them.” Isn't that normal everyday shell use?
- OJFord 3y ago
  The only thing that might 'horrify' me in code review for that is the assumption that it only evaluates true when test failed. (And I might quote '^hello$' personally just on principle for having special chars, especially dollar, and to help syntax highlighters.)

by jmmv 3y ago

o11c 3y ago

[[ is not really a builtin, it's fundamentally syntactical (but presumably uses a mostly-inaccessible builtin internally). Fun fact, `]]` is also a reserved word despite never being allowed in a context where reserved words matter. In some non-bash shells, the `function` keyword is needed to declare certain types of function. For make `$(shell)`, if you're building a lot of targets the performance difference can be measurable. Still, it loses in the nop case, so you should actually usually do `include` to trigger re-making. GNU is completely right to ignore POSIX, since POSIX is not useful for solving most real problems.

account42 3y ago
> In some non-bash shells, the `function` keyword is needed to declare certain types of function. In shells that aren't POSIX-compliant [0], maybe. In which case: yes, there are many wildly different scripting languages with REPLs. [0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_05 https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...
pmarreck 3y ago
> since POSIX is not useful for solving most real problems POSIX, being a standard that can be tested, is at least a specification or agreement that can be met by multiple products to enable them to interact

dang 3y ago

Ok, I've lowercased the leading 't'. We never do that but for this, ok :)

edanm 3y ago
As per the Zen of Python: > Special cases aren't special enough to break the rules. > Although practicality beats purity. :)
deleted 3y ago
[deleted]

gnfargbl 3y ago

This article complains that using the extended GNU features (--ignore-case, set -o pipefail etc) makes scripts less portable. Fair enough. What it doesn't explain is why a Linux user should much care about portability. OpenBSD and FreeBSD are alive and well, but the number of users seems so small that they aren't a particular concern. Maybe you could argue that we "should" consider these OSes out of a sense of fairness, but where does that stop? Do I also need to consider something obscure like vxWorks? BusyBox (Alpine) is more interesting, but the changes there are so significant that a port will almost always be needed anyway. Are there other compelling reasons to care about the non-GNU ecosystem?

kqr 3y ago
Is your comment best read in Internet Explorer 6? ---- What I'm trying to say is that open standards (and the portability that comes with them) is not something that just happens on its own. It takes active maintenance, and part of that maintenance is opting to adhere to the standard even when it would be more convenient to use extensions available in the most popular systems. Will you personally suffer from liberally using Bashisms? Not in the first order. But if we encourage that sort of thinking as a rule, the standards become meaningless. I believe that would be a net negative change for the world, but there are many intelligent people who would disagree.
- dspillett 3y ago
  I don't disagree with you in the context of public scripts, but the vast majority of what I do with bash is local-only (where local is ${DayJob} and my own infrastructure/projects) so the fact that extensions to the standard make my work in those areas quicker to string together and easier to maintain afterwards means I'm happy to lock myself into bash. From my PoV it is generally portable anyway: almost everywhere I use a shell of that nature bash is present. The exceptions to this are things that need to run in small environments, like anything which may end up in initrd (where busybox us generally providing shell/script support). Though I do wish people would make sure they specify bash in the #!/bin/bash in scripts unless trying to stick to the standard, as using #!/bin/sh causes problems when extensions are used and something lighter than bash is the default script runner (i.e. dash in Debian, and again busybox commonly in small environments). Only use #!/bin/sh if you lnow you are making an effort to be compliant.

account42 3y ago

A lot of the GNUisms described in https://jmmv.dev/2021/08/useless-use-of-gnu.html https://jmmv.dev/2021/08/useless-use-of-gnu.html are very useful in interactive use. Search the current directory without an explcit . - useful. Append an option to a command you just typed - heck yeah, always annoyed when commands don't support that. For scripts though, sticking to POSIX sh often makes sense, yeah. You should at least be aware if you use of Bash-isms.

a1369209993 3y ago

> https://jmmv.dev/2021/08/useless-use-of-gnu.html https://jmmv.dev/2021/08/useless-use-of-gnu.html Tangential, but your blog software seems to have mangled the headings; it's serving eg: make $(shell &mldr;) expansion instead of make $(shell ...) expansion (note that (as is correctly written in the body) that's three pediods, not one elipsis, so mldr wouldn't be correct even on it's own, meaning there's two probably-unrelated bugs affecting it).

jmmv 3y ago
Hmm… I’ll have to check later but right now I’m seeing the right thing in iOS. The blog is built by Hugo, so it’s all static files. But maybe something changed with the latest update. Thanks.
- a1369209993 3y ago
  Just checked again with curl|grep, and now I'm getting: <h1 id=make-shell--expansion>make $(shell &mldr;) expansion</h1> as the actual bytes-on-the-wire, which is still wrong, but only in one way rather than two. (Note: iOS probably displays &mldr; as U+2026 "…", which often looks identical to "...", but is actually a single non-ASCII character.)
  - opello 3y ago
    The rabbit hole of why "mldr" (em length leader) is a thing vs. "hellip" (horizontal ellipsis) was pretty disappointing. I only decoded "mldr" and didn't find much in the way of an explanation for why both entities exist. I assume there's some semantic reason in which each is appropriate. I don't know what it is and am curious though!
- jasonpbecker 3y ago
  These are default for Hugo parsing of Markdown—- https://gohugo.io/getting-started/configuration-markup/ https://gohugo.io/getting-started/configuration-markup/

hwc 3y ago

if [ a = b ] || grep -q ^hello$ /usr/share/dict/words; then echo "test failed and grep succeeded" fi > “You pick whether to be amused or horrified. I don’t know how exactly my coworker reacted when I hinted at this during a recent code review I did for them.” Isn't that normal everyday shell use?

OJFord 3y ago
The only thing that might 'horrify' me in code review for that is the assumption that it only evaluates true when test failed. (And I might quote '^hello$' personally just on principle for having special chars, especially dollar, and to help syntax highlighters.)