6 ms·
This is a pretty suspect list. "Built-in commands" showcases [ ] vs [[ ]]. This is not an efficiency win, but a matter of using older POSIX syntax vs more mode
by staticshock 2y ago
This is a pretty suspect list.
"Built-in commands" showcases [ ] vs [[ ]]. This is not an efficiency win, but a matter of using older POSIX syntax vs more modern and richer bash syntax. The utility of the bash syntax is that it supports nicer operators, such as < > in addition to stuff like -gt / -lt.
"Efficient File Operations" showcases IFS=, which is not used for the sake of efficiency, but to change how the line is tokenized. (And what good is an efficiency claim that's not backed up by any data?)
I did not look too closely, but I suspect the rest of this list is equally eyebrow-raising.
- larntz 2y agoBoth of those examples stood out to me also. All the examples could use explanation. This reads like someone's personal cheat sheet more than an informative post. There are some good suggestions but I'd really like to know why the author has these opinions.
- MacrohardDoors 2y agoMaybe the blog writer put it up for their own reference, but personally I like learning the ‘whys’. I think I will just stick with Posix KSH.
- alganet 2y agoYou probably have the `printf` in your PATH. However, if you type `printf` on a bash script, a builtin will be used instead. Try a small benchmark to see the results of /usr/bin/printf vs printf. It really makes a difference (not invoking an external program is a huge performance win). The author is indeed confused though. `test` for example, is also a builtin. You can have an empty PATH= and still invoke printf, test, echo and some few others. The list is weird.
- kesor 2y agoType `help` in your shell to see a list of all the builtins.
- alganet 2y agoIn _some_ shells! (most user shells anyway). `dash` for example does not have help. Some form of builtin list is always on the man pages though. There's no good way of telling if a builtin exists programatically (for, let's say, feature detection). There's an almost good way with `{ PATH=; command -v isthisreallife; }` and some shells will provide a `builtin isthisreallife` that you can use without having to nuke the PATH variable.
- supriyo-biswas 2y ago> There's no good way of telling if a builtin exists programatically (for, let's say, feature detection). Doesn’t the `type` command (technically a builtin) meet your requirements?
- alganet 2y agoIt kinda does, and it is portable enough (modern bash zsh ksh dash busybox), thanks! Of the mainstream packaged shells, it fails only on `posh`, but that's fine, posh is super austere, it also lacks `command`. However, I will probably still use `command -v` for sporadic uses. That's because I don't need a subshell to capture the output: OLDPATH=$PATH;PATH= if command -v echo then echo is builtin fi PATH=$OLDPATH if test "$(type echo)" = "echo is a shell builtin" then echo is a builtin fi `type` however seems to be able to pick up more stuff, so I might use it some cases like this: case $(type echo) in 'echo is a shell builtin') do_something;; 'echo is aliased'*) do_something_else;; 'echo is /'*) do_something_else_entirely;; esac It kinda fits an early feature detection that I could put in a more sensible place (my lib init) and pay the subshell cost only once.
- flaminHotSpeedo 2y ago