Re: LSB Proposal: GNU/Linux Standard Shell
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
andpha@us.ibm.com
IBM Linux Technology Center
Voice: (512)838-9473 T/L 678-9473
Reply to: