Re: $(pwd) != $(/bin/pwd)
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 ." each time. The irony of this command compensates for the hassle of it. But this is possibly not relevant to the current discussion, sorry about that.
Re: can't compile bash 4.1 under Solaris 8/9
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 configure script, hence bash redefine the function at compile time. Bash compiles and runs fine under Solaris 8 and Solaris 9 using gcc. In fact, I test on those platforms before release. I don't have or use the Sun C compiler. Chet Strange, I have the same error with gcc 4: ./mkbuiltins -D . printf.def /opt/csw/gcc4/bin/gcc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I.. -I../include -I../lib -I. -DSOLARIS -I/opt/csw/include -O2 -pipe -mcpu=v8 printf.c || ( rm -f printf.c ; exit 1 ) ./printf.def:175: error: conflicting types for 'vsnprintf' gmake[3]: *** [printf.o] Error 1 and gcc 3: ./mkbuiltins -D . printf.def /opt/csw/gcc3/bin/gcc -c -DHAVE_CONFIG_H -DSHELL -I. -I.. -I.. -I../include -I../lib -I. -DSOLARIS -I/opt/csw/include -O2 -pipe -mcpu=v8 printf.c || ( rm -f printf.c ; exit 1 ) ./printf.def:175: error: conflicting types for 'vsnprintf' ./printf.def:175: error: conflicting types for 'vsnprintf' gmake[3]: *** [printf.o] Error 1 Maybe you could first send me the config.log/config.h generated on Solaris 8 so I can compare with mine ? Yann
Re: can't compile bash 4.1 under Solaris 8/9
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 instead. If I recall correctly, your original Sun cc error message had the exact file name and line number, along with a strange human-readable rendition of the function prototype arguments.
Re: can't compile bash 4.1 under Solaris 8/9
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 your stdio.h header file instead.
If I recall correctly, your original Sun cc error message had the
exact file name and line number, along with a strange human-readable
rendition of the function prototype arguments.
The error message was:
"./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) returning int : "/usr/include/stdio.h", line 227
vsnprintf is declared in printf.def with the following prototype:
extern int vsnprintf __P((char *, size_t, const char *, ...))
__attribute__((__format__ (printf, 3, 4)));
and is declared with the following prototype in the /usr/include/stdio.h
file of the build machine:
extern int vsnprintf(char *, size_t, const char *, __va_list);
I attached the full stdio.h file.
Yann
/* Copyright (c) 1988 AT&T */
/* All Rights Reserved */
/* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T */
/* The copyright notice above does not evidence any */
/* actual or intended publication of such source code. */
/*
* Copyright (c) 1993-1999, by Sun Microsystems, Inc.
* All rights reserved.
*/
/*
* User-visible pieces of the ANSI C standard I/O package.
*/
#ifndef _STDIO_H
#define _STDIO_H
#pragma ident "@(#)stdio.h 1.78 99/12/08 SMI" /* SVr4.0 2.34.1.2 */
#include
/*
* If feature test macros are set that enable interfaces that use types
* defined in , get those types by doing the include.
*
* Note that in asking for the interfaces associated with this feature test
* macro one also asks for definitions of the POSIX types.
*/
/*
* Allow global visibility for symbols defined in
* C++ "std" namespace in .
*/
#if __cplusplus >= 199711L
using std::FILE;
using std::size_t;
using std::fpos_t;
using std::remove;
using std::rename;
using std::tmpfile;
using std::tmpnam;
using std::fclose;
using std::fflush;
using std::fopen;
using std::freopen;
using std::setbuf;
using std::setvbuf;
using std::fprintf;
using std::fscanf;
using std::printf;
using std::scanf;
using std::sprintf;
using std::sscanf;
using std::vfprintf;
using std::vprintf;
using std::vsprintf;
using std::fgetc;
using std::fgets;
using std::fputc;
using std::fputs;
using std::getc;
using std::getchar;
using std::gets;
using std::putc;
using std::putchar;
using std::puts;
using std::ungetc;
using std::fread;
using std::fwrite;
using std::fgetpos;
using std::fseek;
using std::fsetpos;
using std::ftell;
using std::rewind;
using std::clearerr;
using std::feof;
using std::ferror;
using std::perror;
#endif
#ifdef __cplusplus
extern "C" {
#endif
#if defined(_LARGEFILE_SOURCE) || defined(_XPG5)
#ifndef _OFF_T
#define _OFF_T
#if defined(_LP64) || _FILE_OFFSET_BITS == 32
typedef long off_t;
#else
typedef __longlong_t off_t;
#endif
#ifdef _LARGEFILE64_SOURCE
#ifdef _LP64
typedef off_t off64_t;
#else
typedef __longlong_t off64_t;
#endif
#endif /* _LARGEFILE64_SOURCE */
#endif /* _OFF_T */
#endif /* _LARGEFILE_SOURCE */
#ifdef _LARGEFILE64_SOURCE
#ifdef _LP64
typedef fpos_t fpos64_t;
#else
typedef __longlong_t fpos64_t;
#endif
#endif /* _LARGEFILE64_SOURCE */
/*
* XPG4 requires that va_list be defined in "as described in
* ". ANSI-C and POSIX require that the namespace of
* not be polluted with this name.
*/
#if defined(_XOPEN_SOURCE) && (_XOPEN_VERSION - 0 >= 4) && !defined(_VA_LIST)
#define _VA_LIST
typedef __va_list va_list;
#endif /* defined(_XOPEN_SOURCE) && (_XOPEN_VERSION - 0 >= 4) && ... */
#if defined(__EXTENSIONS__) || __STDC__ - 0 == 0 || \
defined(_POSIX_C_SOURCE) || defined(_XOPEN_SOURCE)
#define L_ctermid 9
#define L_cuserid 9
#endif
#if defined(__EXTENSIONS__) || ((__STDC__ - 0 == 0 && \
!defined(_POSIX_C_SOURCE))) || defined(_XOPEN_SOURCE)
#define P_tmpdir "/var/tmp/"
#endif /* defined(__EXTENSIONS__) || ((__STDC__ - 0 == 0 && ... */
#ifndef _STDIO_ALLOCATE
extern unsigned char _sibuf[], _sobuf[];
#endif
/* large file compilation environment setup */
#if !defined(_LP64) && _FILE_OFFSET_BITS == 64
#ifdef __PRAGMA_REDEFINE_EXTNAME
#pragma redefine_extname fopen fopen64
#pragma redefine_extname freopen freopen64
#pragma redefine_extname tmpfile tmpfile64
#pragma redefine_extname fgetpos fgetpos64
#pragma redefine_extname fsetpos fsetpos64
#ifdef _LARGEFILE_SOURCE
#pragma redefine_extname fseeko fseeko64
#pragma redefine_extname ftello ftello64
#endif
#else /* __PRAGMA_REDEFINE_EXTNAME */
#if defined(__STDC__)
extern FILE *fopen64(const char *, const char *);
extern FILE *freopen64(const char *, const char *, FILE *);
extern FILE *tmpfile64(void);
extern int fgetpos64(FILE *, fpos_t *);
Re: can't compile bash 4.1 under Solaris 8/9
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) returning int : "/usr/include/stdio.h", line 227 Try the attached patch to printf.def, which fixes the prototype declaration. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ *** ../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((char *, size_t, const char *, ...)) __attribute__((__format__ (printf, 3, 4))); #endif --- 173,177 #if !HAVE_VSNPRINTF ! extern int vsnprintf __P((char *, size_t, const char *, va_list)) __attribute__((__format__ (printf, 3, 0))); #endif
Re: can't compile bash 4.1 under Solaris 8/9
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((char *, size_t, const char *, ...)) > __attribute__((__format__ (printf, 3, 4))); > #endif > > --- 173,177 > > #if !HAVE_VSNPRINTF > ! extern int vsnprintf __P((char *, size_t, const char *, va_list)) > __attribute__((__format__ (printf, 3, 0))); > #endif > Looks good. HP-UX 11.11 had the same problem Yann reported on Solaris (I hadn't tested on that machine -- oops!), and this patch fixes it there. HP-UX 10.20 doesn't have a prototype for vsnprintf at all, so there was never a problem on that machine (it works either with or without the patch).
Re: can't compile bash 4.1 under Solaris 8/9
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 2010-01-07 08:50:06.0 -0500 *** *** 173,177 #if !HAVE_VSNPRINTF ! extern int vsnprintf __P((char *, size_t, const char *, ...)) __attribute__((__format__ (printf, 3, 4))); #endif --- 173,177 #if !HAVE_VSNPRINTF ! extern int vsnprintf __P((char *, size_t, const char *, va_list)) __attribute__((__format__ (printf, 3, 0))); #endif Looks good. HP-UX 11.11 had the same problem Yann reported on Solaris (I hadn't tested on that machine -- oops!), and this patch fixes it there. HP-UX 10.20 doesn't have a prototype for vsnprintf at all, so there was never a problem on that machine (it works either with or without the patch).
[PATCH] Ensure the command found in the hash table exists, not only on POSIXLY_CORRECT
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:
export PATH=a:b:$PATH
cd /tmp
mkdir a b
cat > a/prog.sh << EOF
echo hello world
EOF
chmod +x a/prog.sh
cp a/prog.sh b/prog.sh
prog.sh
rm a/prog.sh
prog.sh
It works with "POSIXLY_CORRECT=1 bash" and dash handles it too. Without
POSIXLY_CORRECT I get:
hello world
/tmp/failure.sh: line 13: a/prog.sh: No such file or directory
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.sh
cat > a/prog.sh << EOF
echo a/prog.sh
EOF
chmod +x a/prog.sh
prog.sh
---
Which prog.sh should be used in this case? a/prog.sh or b/prog.sh? The
former has a higher precedence in PATH but the latter is the hashed
value.
Thanks,
Giuseppe Scrivano
>From c786059d65fc47d6265ebde3fe88c18c381dc77b Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano
Date: Thu, 7 Jan 2010 13:52:13 +0100
Subject: [PATCH] Ensure the command found in the hash table exists, not only on
POSIXLY_CORRECT
---
findcmd.c | 19 +++
1 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/findcmd.c b/findcmd.c
index 1f05394..b8c4fbe 100644
--- a/findcmd.c
+++ b/findcmd.c
@@ -301,18 +301,13 @@ search_for_command (pathname)
hashed_file = phash_search (pathname);
/* If a command found in the hash table no longer exists, we need to
- look for it in $PATH. Thank you Posix.2. This forces us to stat
- every command found in the hash table. */
-
- if (hashed_file && (posixly_correct || check_hashed_filenames))
-{
- st = file_status (hashed_file);
- if ((st & (FS_EXISTS|FS_EXECABLE)) != (FS_EXISTS|FS_EXECABLE))
- {
- phash_remove (pathname);
- free (hashed_file);
- hashed_file = (char *)NULL;
- }
+ look for it in $PATH. */
+ st = file_status (hashed_file);
+ if ((st & (FS_EXISTS|FS_EXECABLE)) != (FS_EXISTS|FS_EXECABLE))
+ {
+ phash_remove (pathname);
+ free (hashed_file);
+ hashed_file = (char *)NULL;
}
if (hashed_file)
--
1.6.5
Re: [PATCH] Ensure the command found in the hash table exists, not only on POSIXLY_CORRECT
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, enable the `checkhash' option with shopt. > 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.sh > > cat > a/prog.sh << EOF > echo a/prog.sh > EOF > > chmod +x a/prog.sh > > prog.sh > --- > > > Which prog.sh should be used in this case? a/prog.sh or b/prog.sh? The > former has a higher precedence in PATH but the latter is the hashed > value. The hashed value should be preferred as long as it exists. If you're concerned about this being a problem, run `hash prog.sh' after creating it. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [PATCH] Ensure the command found in the hash table exists, not only on POSIXLY_CORRECT
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.sh >> >> cat > a/prog.sh << EOF >> echo a/prog.sh >> EOF >> >> chmod +x a/prog.sh >> >> prog.sh >> --- >> >> >> Which prog.sh should be used in this case? a/prog.sh or b/prog.sh? The >> former has a higher precedence in PATH but the latter is the hashed >> value. > > The hashed value should be preferred as long as it exists. If you're > concerned about this being a problem, run `hash prog.sh' after creating > it. 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 commands hashing at all? I couldn't find it. Cheers, Giuseppe
Re: [PATCH] Ensure the command found in the hash table exists, not only on POSIXLY_CORRECT
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 commands hashing at all? I couldn't find it. There is. Look at `set -h'. Since this only happens when you run a command found using a PATH lookup, causing it to be hashed, then explicitly create a command of the same name and install it in another directory in PATH, I recommend that you run `hash -r' after you install the second command. This will avoid the problem while retaining the benefits of hashing. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
