The problem is described at https://bugzilla.redhat.com/show_bug.cgi?id=1135573
There is a small testcase attached to the report: https://bugzilla.redhat.com/attachment.cgi?id=932746 and my proposed patch is inlined here for easier visualization: ---%<--- diff -up ksh-20120801/src/cmd/ksh93/sh/path.c.orig ksh-20120801/src/cmd/ksh93/sh/path.c --- ksh-20120801/src/cmd/ksh93/sh/path.c.orig 2014-09-01 15:08:06.738969962 -0300 +++ ksh-20120801/src/cmd/ksh93/sh/path.c 2014-09-01 15:13:51.321459978 -0300 @@ -229,13 +229,12 @@ static pid_t path_xargs(Shell_t *shp,con /* * make sure PWD is set up correctly * Return the present working directory - * Invokes getcwd() if flag==0 and if necessary + * Invokes getcwd() if necessary * Sets the PWD variable to this value */ char *path_pwd(Shell_t *shp,int flag) { register char *cp; - register char *dfault = (char*)e_dot; register int count = 0; if(shp->pwd) return((char*)shp->pwd); @@ -254,11 +253,6 @@ char *path_pwd(Shell_t *shp,int flag) cp = "/"; break; case 3: - cp = (char*)e_crondir; - if(flag) /* skip next case when non-zero flag */ - ++count; - break; - case 4: { if(cp=getcwd(NIL(char*),0)) { @@ -269,8 +263,6 @@ char *path_pwd(Shell_t *shp,int flag) } break; } - case 5: - return(dfault); } if(cp && *cp=='/' && test_inode(cp,e_dot)) break; ---%<--- Basically I removed case 3 (e_crondir) because it does not match any recent Linux system file system layout, but that is mostly cosmetic. What it really does is to not return "." as the current directory, and always do a getcwd if stat of "." and predefined test directory do not match. This effectively removes use of the flag argument, to prevent calling getcwd, that exists probably to not fail in ksh if the current directory is something like a stale nfs handle or some really slow filesystem, e.g. a tape. But I may be missing something. The problem is hard to reproduce because if any subshell is executed or if the pwd builtin is executed, it would call path_pwd with a 0 flag, and "fix" the contents of $PWD. Thanks, Paulo _______________________________________________ ast-users mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-users
