Hello All, > 2. POSIX: section 3.5 Parameters and Variables: sh_05 293: > When a variable has been assigned a value (including the null > value), then the variable is set and can only be unset by use of > the unset special built-in. > Test: BUG: Expecting ' set | grep "an_unset_var" ' to return 1 as > exit status indicating an_unset_var is in fact unset. However, > grep will catch lots of false positives this way. The correct way > is to grep for '^an_unset_var='. > Bash: > Type: 1 > >The chances of the grep matching the name or contents of another >shell variable are very small given that the variable name used >is "sh5_293_var". The test is almost certainly failing because bash >is including function definitions in the output of "set". If this >non-compliance of bash is fixed then the test should pass.
I will pass this on to Chet. >11. POSIX: GA10 sh_05 378: > GA10 - When a file is newly created by the $CATCREATEOUT utility, > then the file attributes are set as follows: > (1) The file's user ID is set to the effective user ID of the > creating process. > (2) The file's group ID is set to either the effective group ID of > the creating process or to the group ID of the directory in which > the file is created. > (3) The file's permission bits are set to > S_IROTH|S_IWOTH|S_IRGRP|S_IWGRP|S_IRUSR|S_IWUSR except that the > bits set in the creating processes file mode creation mask are > cleared. > (4) The st_atime, st_ctime and st_mtime fields of the file are > updated > (5) When the file is a directory, then the directory is created > empty. > (6) When the file is not a directory, then it has zero length. > (7) When the file type is not specified, then a regular file is > created. > Test: BUG: unable to locate GetFileData which is supposed to come > with the test suite. > Bash: > Type: 1 > >[Note this test is in sh_06 not sh_05] Agree. I will change this in my doc. > 23. POSIX: section 3.9.3.1 Asynchronous Lists: sh_08 461: > The special parameter $! expands to the process ID of the last > command in an asynchronous list. > Test: BUG: 1) use print command in a script. > 2) invoke a shell script directly without putting the dot/sh > command in front (e.g., sh8_461_2sh& instead of sh sh8_461_2sh& ). > Bash: > Type: 1 > >I assume the "Type: 1" only applies to the first part (use of "print"), >since Chet's list says this test "works with bash-2.05 when `print' >changed to `echo'". Ignore the second part. I did notice "Chet's list says this test "works with bash-2.05 when `print' changed to `echo'""; however, invoking a script the way this test did, sh8_461_2sh&, still looks suspicious to me. I was just trying to be helpful by pointing it out so we all can look at it. >28. POSIX: section 3.9.5 Function Definition Command: sh_09 517: > When a word expansion error occurs during a call to a function, > then a non-interactive shell aborts. Redirection error shall not > cause non-interactive shell to abort. > Test: BUG: expects non-interactive shell to abort when redirection > error is encountered. > Bash: works. > Type: 1 > >This classification as a test bug doesn't match Chet's list, which says >the test works with bash-2.05. > >I believe the test is correct, as the redirection is applied to a >special built-in command (eval), and according to POSIX and XCU it >should cause a non-interactive shell to abort in this case. You are right. Redirection error shall cause non-interactive shell to abort, when applied to special built-in command. I mis-understood the redirection was applied to function, which this testcase is testing, and not the 'eval' command. Andrew H. Pham [EMAIL PROTECTED] IBM Linux Technology Center Voice: (512)838-9473 T/L 678-9473
