In <[🔎] 84lj80alu2.fsf@sauna.l.org>, Timo Juhani Lindfors wrote: >Paul E Condon <pecondon@mesanetworks.net> writes: >> I would >> have thought 'interactive' should be characterized by having a tty >> attached to sysin and sysout for communication to a 'user'. > >That is not true. If I run "bash foo.sh" then I am not running shell >interactively. Instead, the shell is interpreting commands from a file >in a completely automated fashion and not consulting me before each >command. > >However, "bash foo.sh" can very well have stdin and stdout connected >to a terminal. Having a terminal and being interactive are two >different concepts. According the the relevant specifications, being interactive is closely keyed to what types of objects are attached to stdin and stderr. In specific: "Standard input and standard error are the files that determine whether a shell is interactive when -i is not specified. For example: sh > file and: sh 2> file create interactive and non-interactive shells, respectively. Although both accept terminal input, the results of error conditions are different, as described in Consequences of Shell Errors ; in the second example a redirection error encountered by a special built-in utility will abort the shell." -- Single UNIX Specifcation, version 2: Commands and Utilities -- sh -- Application Usage. Similar wording is in SUSv3. Both the SUSv2 and SUSv3 are available in the "contrib" component of Lenny, Squeeze, and Sid. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.