Re: $(pwd) != $(/bin/pwd)

2010-01-07 Thread Marc Herbert
Chet Ramey a écrit : > How often does the directory change out from under a > shell process, after which it calls pwd? Depends on what you mean by "change". Very often for testing purposes I re-run some software installer that deletes and re-creates the "tested" directory. So I need to run "cd ."

Re: can't compile bash 4.1 under Solaris 8/9

2010-01-07 Thread Yann Rouillard
Chet Ramey a écrit : >> ... Description: bash 4.1 can't be compiled under Solaris 8 and Solaris 9, the compilation stops at a vsnprintf redefinition error. This happens because the vsnprintf native function is not detected as being standard compliant (it returns -1 in case of overflow) by the

Re: can't compile bash 4.1 under Solaris 8/9

2010-01-07 Thread Greg Wooledge
On Thu, Jan 07, 2010 at 12:22:12PM +0100, Yann Rouillard wrote: > ./printf.def:175: error: conflicting types for 'vsnprintf' > Maybe you could first send me the config.log/config.h generated on > Solaris 8 so I can compare with mine ? It might be more useful to compare your stdio.h header file i

Re: can't compile bash 4.1 under Solaris 8/9

2010-01-07 Thread Yann Rouillard
Greg Wooledge a écrit : On Thu, Jan 07, 2010 at 12:22:12PM +0100, Yann Rouillard wrote: ./printf.def:175: error: conflicting types for 'vsnprintf' Maybe you could first send me the config.log/config.h generated on Solaris 8 so I can compare with mine ? It might be more useful to compare you

Re: can't compile bash 4.1 under Solaris 8/9

2010-01-07 Thread Chet Ramey
On 1/7/10 8:57 AM, Yann Rouillard wrote: > "./printf.def", line 175: identifier redeclared: vsnprintf > current : function(pointer to char, unsigned int, pointer to const char, > ...) returning int > previous: function(pointer to char, unsigned int, pointer to const char, > pointer to void) return

Re: can't compile bash 4.1 under Solaris 8/9

2010-01-07 Thread Greg Wooledge
On Thu, Jan 07, 2010 at 09:03:19AM -0500, Chet Ramey wrote: > *** ../bash-4.1/builtins/printf.def 2009-11-20 15:31:23.0 -0500 > --- builtins/printf.def 2010-01-07 08:50:06.0 -0500 > *** > *** 173,177 > > #if !HAVE_VSNPRINTF > ! extern int vsnprintf __P(

Re: can't compile bash 4.1 under Solaris 8/9

2010-01-07 Thread Yann Rouillard
Also works perfectly for Solaris. I can now compile bash 4.1 under Solaris 8 or 9. Thanks for answer. Yann Greg Wooledge a écrit : On Thu, Jan 07, 2010 at 09:03:19AM -0500, Chet Ramey wrote: *** ../bash-4.1/builtins/printf.def 2009-11-20 15:31:23.0 -0500 --- builtins/printf.def 2

[PATCH] Ensure the command found in the hash table exists, not only on POSIXLY_CORRECT

2010-01-07 Thread Giuseppe Scrivano
Hello, what do you think about make this the default behavior, not only when POSIXLY_CORRECT is specified? A `stat' is very fast, the cost of a stat+fork+exec is almost the same of a fork+exec. This is the test case I used, I expect to get "hello world" twice: --

Re: [PATCH] Ensure the command found in the hash table exists, not only on POSIXLY_CORRECT

2010-01-07 Thread Chet Ramey
On 1/7/10 8:39 AM, Giuseppe Scrivano wrote: > Hello, > > what do you think about make this the default behavior, not only when > POSIXLY_CORRECT is specified? A `stat' is very fast, the cost of a > stat+fork+exec is almost the same of a fork+exec. If you want to make this your default behavior,

Re: [PATCH] Ensure the command found in the hash table exists, not only on POSIXLY_CORRECT

2010-01-07 Thread Giuseppe Scrivano
Thanks for your answer. Chet Ramey writes: >> I have a question: how bash should behave in the case you have: >> >> --- >> export PATH=a:b:$PATH >> >> mkdir a b >> >> cat > b/prog.sh << EOF >> echo b/prog.sh >> EOF >> >> chmod +x b/prog.sh >> >> prog

Re: [PATCH] Ensure the command found in the hash table exists, not only on POSIXLY_CORRECT

2010-01-07 Thread Chet Ramey
On 1/7/10 5:30 PM, Giuseppe Scrivano wrote: > the code I have attached is just a test case that actually, AFAICS, > can't be fixed without change its code. This situation can be present > in a shell script that potentially can rely on the PATH elements > precedence. > > Is there a way to disable