3 ms·

Both `[` and `test` are built-ins (they are the same command). There's nothing in-efficient about using them. You might always use `[[` for consistency, but I p

by js2 2y ago

Both `[` and `test` are built-ins (they are the same command). There's nothing in-efficient about using them. You might always use `[[` for consistency, but I personally use `if test` unless I need the functionality of `[[` since I find `if test` more legible and when I see `[[` it's a hint that, yes, I really do need its functionality. https://www.gnu.org/software/bash/manual/html_node/Bourne-Shell-Builtins.html https://www.gnu.org/software/bash/manual/html_node/Bourne-Sh... All of recommendations about efficiency seem misguided to me.

alganet 2y ago
I always prefer `if test` too, and a line break instead of semicolon: if test 1 -gt 2 then echo 123 fi if test 1 -gt 2 then echo 123 fi Much cleaner than the random symbol fiesta
- deleted 2y ago
  [deleted]
fugue88 2y ago
> All of recommendations about efficiency seem misguided to me. I've seldom had to worry about the performance of my scripts. It almost always is dominated by the performance of whatever the script is running. I did have one very notable exception, though. It's kind of embarrassing. On one project---for "reasons"---I had written several bash scripts to collect system performance metrics to push into Nagios or Graphite. A couple of these had to calculate some floating point, and I was invoking `dc` to do that, as bash only supports integer arithmetic. The script would loop once every 5 seconds or so, iirc, invoking dc each time. One small process every 5 seconds doesn't sound like a lot, but the systems also ran ClamAV---again, for "reasons"---and were already under high load, and that extra process invocation had a noticeable and significant impact on the system. My workaround was to run a single instance of dc using bash's `coproc` keyword, then redirect all the calculations through the returned descriptors. This had a drastic improvement. Except... it turns out that dc leaked 80 bytes of memory whenever it read and parsed a float. So, the long-running dc process would eventually get oom-killed. So, I added a check to restart the dc process every 5000 iterations, or something like that. Which all sounds like a big headache, but for "reasons" this was far easier than getting some other solution into that environment. I did submit a bug report (2020 Feb 19), and Ken Pizzini (dc's original author, I think) was kind enough to reply even though he wasn't the maintainer. Unfortunately, my patch never got upstreamed. Then again, who else is crazy enough to use dc as long-running math server?
saurik 2y ago
FWIW, in a tight for loop of a million executions of either test 1, [[ 1 ]], true, or :, I get: test 1 -> 2.70s true -> 2.55s : -> 2.25s [[ 1 ]] -> 2.10s Like, I don't even have a way to measure the overhead of just the for loop as [[ is faster than that. But we can do something and see the cost of that: let's do a -z $a when a=. We don't need to quote the $a with [[, but I'll do it both ways: test -z "$a" -> 3.25s [[ -z "$a" ]] -> 2.65s [[ -z $a ]] -> 2.10s So, sure: it isn't a performance difference that is likely to kill a use case, but it does exist. I also agree that it isn't necessarily worth bothering with... but I just can't get behind something -- using test -- that is both slower and more complex... like, to me, it isn't [[ that has "functionality" that I might not need, it is test: with test I can programmatically decide operators by putting them in variables, while with [[ everything must be syntax. This is an incredible amount of extra power that you get with test that I frankly don't just not need... I actively would prefer not having except in a scant handful of scenarios. It is much easier to glance at a use of [[ and know 100% for sure what it is doing than with test, where you must carefully consider all of the quoting rules, and even then the behavior might be dynamic.
- Brian_K_White 2y ago
  Now what about my own probably unjustified bash performance I mean style habit, using (( )) instead of [[ ]] whenever the arguments are all numerical. I'll even use $# or ${#a} in place of -z sometimes if it means being able to keep the whole test in a single (()) instead of needing a seperate [[]]. (also [[]] does not need -z. Just [[ $a ]] is the same.)
chubot 2y ago
Note that you've almost certainly spent your time correcting "LLM slop" - https://news.ycombinator.com/item?id=40723766 https://news.ycombinator.com/item?id=40723766
- deleted 2y ago
  [deleted]
1vuio0pswjnm7 2y ago
I do not use bash for scripting^1 but I prefer to use "if test" rather than "if [". Same reason: legibility. However I continue to see shell scripts from what I believe are probably competent scripters, i.e., scripts in tarballs of software from authors I trust, and they almost always seem to prefer using "[". Wondering if there is a reason or it is purely style. 1. Bash is too big and slow for scripting. The bash author admits it is "too big and slow" in the manpage. The world's most popular Linux distribution does not use bash as its scripting shell; it uses something smaller and faster derived from NetBSD Almquist shell. For scripting, there are more efficient shells for scripting than bash. NB. Nothing against bash. As an experiment I have been using busybox bash as an interactive shell. Normally I use NetBSD ash. I like the way busybox bash does not keep duplicates in history and its command search is quick. But like its full-sized counterpart it is too slow for scripting. Using busybox to do scripting is so slow that it is bascially useless for anything but the smallest scripts.

by js2 2y ago

alganet 2y ago

I always prefer `if test` too, and a line break instead of semicolon: if test 1 -gt 2 then echo 123 fi if test 1 -gt 2 then echo 123 fi Much cleaner than the random symbol fiesta

deleted 2y ago
[deleted]

fugue88 2y ago

> All of recommendations about efficiency seem misguided to me. I've seldom had to worry about the performance of my scripts. It almost always is dominated by the performance of whatever the script is running. I did have one very notable exception, though. It's kind of embarrassing. On one project---for "reasons"---I had written several bash scripts to collect system performance metrics to push into Nagios or Graphite. A couple of these had to calculate some floating point, and I was invoking `dc` to do that, as bash only supports integer arithmetic. The script would loop once every 5 seconds or so, iirc, invoking dc each time. One small process every 5 seconds doesn't sound like a lot, but the systems also ran ClamAV---again, for "reasons"---and were already under high load, and that extra process invocation had a noticeable and significant impact on the system. My workaround was to run a single instance of dc using bash's `coproc` keyword, then redirect all the calculations through the returned descriptors. This had a drastic improvement. Except... it turns out that dc leaked 80 bytes of memory whenever it read and parsed a float. So, the long-running dc process would eventually get oom-killed. So, I added a check to restart the dc process every 5000 iterations, or something like that. Which all sounds like a big headache, but for "reasons" this was far easier than getting some other solution into that environment. I did submit a bug report (2020 Feb 19), and Ken Pizzini (dc's original author, I think) was kind enough to reply even though he wasn't the maintainer. Unfortunately, my patch never got upstreamed. Then again, who else is crazy enough to use dc as long-running math server?

saurik 2y ago

FWIW, in a tight for loop of a million executions of either test 1, [[ 1 ]], true, or :, I get: test 1 -> 2.70s true -> 2.55s : -> 2.25s [[ 1 ]] -> 2.10s Like, I don't even have a way to measure the overhead of just the for loop as [[ is faster than that. But we can do something and see the cost of that: let's do a -z $a when a=. We don't need to quote the $a with [[, but I'll do it both ways: test -z "$a" -> 3.25s [[ -z "$a" ]] -> 2.65s [[ -z $a ]] -> 2.10s So, sure: it isn't a performance difference that is likely to kill a use case, but it does exist. I also agree that it isn't necessarily worth bothering with... but I just can't get behind something -- using test -- that is both slower and more complex... like, to me, it isn't [[ that has "functionality" that I might not need, it is test: with test I can programmatically decide operators by putting them in variables, while with [[ everything must be syntax. This is an incredible amount of extra power that you get with test that I frankly don't just not need... I actively would prefer not having except in a scant handful of scenarios. It is much easier to glance at a use of [[ and know 100% for sure what it is doing than with test, where you must carefully consider all of the quoting rules, and even then the behavior might be dynamic.

Brian_K_White 2y ago
Now what about my own probably unjustified bash performance I mean style habit, using (( )) instead of [[ ]] whenever the arguments are all numerical. I'll even use $# or ${#a} in place of -z sometimes if it means being able to keep the whole test in a single (()) instead of needing a seperate [[]]. (also [[]] does not need -z. Just [[ $a ]] is the same.)

chubot 2y ago

Note that you've almost certainly spent your time correcting "LLM slop" - https://news.ycombinator.com/item?id=40723766 https://news.ycombinator.com/item?id=40723766

deleted 2y ago
[deleted]

1vuio0pswjnm7 2y ago

I do not use bash for scripting^1 but I prefer to use "if test" rather than "if [". Same reason: legibility. However I continue to see shell scripts from what I believe are probably competent scripters, i.e., scripts in tarballs of software from authors I trust, and they almost always seem to prefer using "[". Wondering if there is a reason or it is purely style. 1. Bash is too big and slow for scripting. The bash author admits it is "too big and slow" in the manpage. The world's most popular Linux distribution does not use bash as its scripting shell; it uses something smaller and faster derived from NetBSD Almquist shell. For scripting, there are more efficient shells for scripting than bash. NB. Nothing against bash. As an experiment I have been using busybox bash as an interactive shell. Normally I use NetBSD ash. I like the way busybox bash does not keep duplicates in history and its command search is quick. But like its full-sized counterpart it is too slow for scripting. Using busybox to do scripting is so slow that it is bascially useless for anything but the smallest scripts.