On Tue, May 25, 2010 at 10:06 PM, Andres P <aepd87@gmail.com> wrote:
On Sat, May 22, 2010 at 2:18 AM, Allan McRae <allan@archlinux.org> wrote:
In fact, thinking about this more. Bash-4.1 was released on 2010-01-03 so it will have been out for ~6 months before the next pacman release. Anyone upgrading their package manager from 3.3 -> 3.4 will upgrade bash from 4.0 -> 4.1 so this is probably a non-issue.
So I will accept this patch when the comment above and "stray" ! is removed with it.
Allan
I was about to do that, but first I think I should talk about another change.
`type -p foo` has a return val, so consider this: $ time for i in {1..1000}; do [[ $(type -p sh) ]]; done real 0m1.564s user 0m0.160s sys 0m0.337s
$ time for i in {1..1000}; do type -p sh &>/dev/null; done real 0m0.166s user 0m0.060s sys 0m0.103s
Even though there is a negligible perfomance difference in makepkg, this is the correct way to check for $?.
I don't understand this sentence. negligible = 10x ? And if your "correct" way is 10x faster, why do you say "even though" ? This makes it sound like we need to accept a compromise (like worse perf) for a correct behavior. But from my understanding of your mail, you are saying that using type -p directly is both more correct and faster.
If the redir to /dev/null becomes to much of a burden to type, it could become a function. Not to mention that the whole series of checking for vcs in PATH, which is where most of `type p` gets used, could be changed in to a more platable chunk.
Would there be interest in making this change?
I really think that throwing away the return val and making a string check is poor practice.
So the only downside of using type -p sh &>/dev/null directly without [/[[ and a subshell is that we need to type &>/dev/null ? It does not seem like a big deal to me. And yeah if it's used a lot, like more than 5 times, just make a function.