Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-20 Thread Martin Cracauer
In <[EMAIL PROTECTED]>, Brian Fundakowski Feldman wrote: > > Is there something substantially you'd like to contribute to the > > discussion, like - say - an example where bash-2.03 doesn't work well? > > It's definitely broken on some of my scripts before. If you want me > to go try to find o

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-20 Thread Brian Fundakowski Feldman
> > Over the last year, I did an extensive amount of testinging on bourne > shell behaviour. bash2 was the only free sh clone that I never had to > complain over. I'm surprised. > > Is there something substantially you'd like to contribute to the > discussion, like - say - an example where bas

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-20 Thread Brian Fundakowski Feldman
On Fri, 17 Dec 1999, Martin Cracauer wrote: > > I still think we should *seriously* consider switching to pdksh. > > As I said before, pdksh has other bugs. > Also we would loose all the PRs we received in the past. This testing > effort by our user base is a valuable resource. From the tests I

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-20 Thread Martin Cracauer
In <[EMAIL PROTECTED]>, Brian Fundakowski Feldman wrote: > On Fri, 17 Dec 1999, Martin Cracauer wrote: > > > > I still think we should *seriously* consider switching to pdksh. > > > > As I said before, pdksh has other bugs. > > > Also we would loose all the PRs we received in the past. This t

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-17 Thread Martin Cracauer
In <[EMAIL PROTECTED]>, David O'Brien wrote: > On Thu, Dec 16, 1999 at 03:40:20PM +0100, Martin Cracauer wrote: > > You can also fool sh into running the *wrong* binary if if you have > > two in showdowed paths: > > pdksh does not suffer from either this problem or the problem that > started thi

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-16 Thread David O'Brien
On Thu, Dec 16, 1999 at 03:40:20PM +0100, Martin Cracauer wrote: > You can also fool sh into running the *wrong* binary if if you have > two in showdowed paths: pdksh does not suffer from either this problem or the problem that started this thread (and does not coredump). We've shown in the past

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-16 Thread Martin Cracauer
You can also fool sh into running the *wrong* binary if if you have two in showdowed paths: #! /bin/sh test -d foo1 || mkdir foo1 test -d foo2 || mkdir foo2 test -d foo2 || mkdir foo3 echo 'echo :one' > foo1/run echo 'echo :two' > foo2/run echo 'echo :three' > foo2/run3 chmod a+x */run* hash -r

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-15 Thread Mike Smith
> In <[EMAIL PROTECTED]>, Marcel Moolenaar wrote: > > Sheldon Hearn wrote: > > > > > > On Tue, 14 Dec 1999 15:42:11 +0100, Marcel Moolenaar wrote: > > > > > > > > You set all those variables for the first make command, but not for the > > > > > second. What did you expect to happen? > > > > >

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-15 Thread Martin Cracauer
In <[EMAIL PROTECTED]>, Marcel Moolenaar wrote: > Martin Cracauer wrote: > > > > In <[EMAIL PROTECTED]>, Marcel Moolenaar wrote: > > > It seems to me that when there's a PATH= assignment you don't want to > > > add anything to the cache or alternatively, clear the cache after > > > execution of

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-15 Thread Marcel Moolenaar
Martin Cracauer wrote: > > In <[EMAIL PROTECTED]>, Marcel Moolenaar wrote: > > It seems to me that when there's a PATH= assignment you don't want to > > add anything to the cache or alternatively, clear the cache after > > execution of the command having a PATH= assignment. > > The first solutio

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-15 Thread Martin Cracauer
In <[EMAIL PROTECTED]>, Marcel Moolenaar wrote: > It seems to me that when there's a PATH= assignment you don't want to > add anything to the cache or alternatively, clear the cache after > execution of the command having a PATH= assignment. The first solution is better, but the source messes wi

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-15 Thread Marcel Moolenaar
Martin Cracauer wrote: > > OK, the problem is real. > > BTW, its worse: > > #! /bin/sh > hash -v > PATH=/sbin:/bin > PATH=/foo:/bar:/bin ls > hash -v > ls > > => coredump It seems to me that when there's a PATH= assignment you don't want to add anything to the cache or alternatively, clear th

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-15 Thread Martin Cracauer
OK, the problem is real. BTW, its worse: #! /bin/sh hash -v PATH=/sbin:/bin PATH=/foo:/bar:/bin ls hash -v ls => coredump Working on it. -- % Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/ BSD User Group Hambur

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-15 Thread Marcel Moolenaar
Martin Cracauer wrote: > > In <[EMAIL PROTECTED]>, Marcel Moolenaar wrote: > > Sheldon Hearn wrote: > > > > > > On Tue, 14 Dec 1999 15:42:11 +0100, Marcel Moolenaar wrote: > > > > > > > > You set all those variables for the first make command, but not for the > > > > > second. What did you expec

Re: sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-15 Thread Martin Cracauer
In <[EMAIL PROTECTED]>, Marcel Moolenaar wrote: > Sheldon Hearn wrote: > > > > On Tue, 14 Dec 1999 15:42:11 +0100, Marcel Moolenaar wrote: > > > > > > You set all those variables for the first make command, but not for the > > > > second. What did you expect to happen? > > > > > > That make(1)

sh(1) broken caching [was: Re: Broken sh(1)?]

1999-12-14 Thread Marcel Moolenaar
Sheldon Hearn wrote: > > On Tue, 14 Dec 1999 15:42:11 +0100, Marcel Moolenaar wrote: > > > > You set all those variables for the first make command, but not for the > > > second. What did you expect to happen? > > > > That make(1) would execute. > > But what was the PATH set to _before_ you se