On 3/11/10 4:24 AM, Marc Herbert wrote:
> Chet Ramey a écrit :
>>> On the other hand, local is not specified by POSIX. What would it hurt
>>> to redefine the exit status of local to reflect the status of any
>>> command substitutions performed during the local assignments (short of
>>> compatibili
Chet Ramey wrote:
> To Posix, assignment statements never fail -- assignment errors cause
> non- interactive shells to exit, period. In that case, it's possible
> to reflect the exit status of a command substitution in the exit
> status of a command consisting only of assignment statements,...
I
On 03/11/2010 09:27 AM, Marc Herbert wrote:
> Chet Ramey wrote:
>
>> To Posix, assignment statements never fail -- assignment errors cause
>> non- interactive shells to exit, period. In that case, it's possible
>> to reflect the exit status of a command substitution in the exit
>> status of a com
On 3/11/10 11:32 AM, Eric Blake wrote:
> If you'd like 'local' to be standardized in the next version of POSIX,
> several years from now, that would also be a good goal; help in
> submitting the proposal to the Austin group would be appreciated.
I thought an early draft of Posix.2 (in those days)
On page
http://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files
Could this sentence:
"An interactive shell is one started without non-option arguments,
unless -sis specified, without specifying the
-c option, and whose input and error output are both connected to terminals
(as de
