On Mon, Oct 11, 2010 at 07:19:14PM -0700, David O'Brien wrote: > At $WORK we hit a bug where ${var%/*} was not producing the correct > expansion. There are two patches to fix this. I prefer the first > as I feel it is cleaner from an API perspective. I've also added > a regression testcase that shows the problem. > Thoughts? Thank you, I think this is the mysterious bug I encountered a while ago while making changes to arithmetic expansion, heavily using the stack string. It only failed when /etc/rc.d/nfsserver was called from /etc/rc on boot. Your patch looks good (the first one) and works for me. The second patch indeed seems a hack rather than fixing the problem properly. Style bug: > +growstrstackblock(int n) { The opening brace should be on its own line. Your test is too fragile: it often fails to detect the bug. Calling like sh -c '. expansion/trim4.0' gives the correct output even with a buggy sh. I propose something like this, or perhaps with an additional string comparison: # $FreeBSD$ v1=/homes/SOME_USER v2= v3=C123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 while [ ${#v2} -lt 2000 ]; do v4="${v2} ${v1%/*} $v3" if [ ${#v4} -ne $((${#v2} + ${#v3} + 8)) ]; then echo bad: ${#v4} -ne $((${#v2} + ${#v3} + 8)) fi v2=x$v2 v3=y$v3 done -- Jilles TjoelkerReceived on Wed Oct 13 2010 - 19:42:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:08 UTC