[fup2 to c.u.shell]
> (1) In what situation "<>" is used? Examples?
In this case, the _older_ variant of the SUS is more informative:
| The <> operator could be useful in writing an application that
| worked with several terminals, and occasionally wanted to start up a
| shell. That shell would in turn be unable to run applications that
| run from an ordinary controlling terminal unless it could make use of
| <> redirection. The specific example is a historical version of the
| pager more, which reads from standard error to get its commands, so
| standard input and standard output are both available for their usual
| usage. There is no way of saying the following in the shell without <>:
| cat food | more - >/dev/tty03 2<>/dev/tty03
BTW: In fact even the original Bourne shell "always" accepted <>,
but it was buggy by omitting O_RDWR when open()ing. Due to the rare
usage, <> was never fixed nor documented by AT&T.
It was (AFAIK: only) fixed with SunOS 5.6 -- probably even for the
previously mentioned inittab entries.
Quote:> (2) Will read change the position for write, and vice versa?
Certainly: you would need separate entries in the "open file table"
for separate positioning; one filedescriptor can only point to one
Instead your question better applies to something like:
"exec 3>file; exec 4>&3" vs "exec 3>file; exec 4>file"
Quote:> (3) Can read/write be reposition? seek()? but in Shell?
I don't know of any shell offering a "seek" functionality to the user.
(But in principle, the shell certainly could do that.)
You could open the file several times (like in the above) and "save"
a file pointer for later use. (doesn't look extremely useful, though.)
$ exec 3>file; exec 4>file
$ echo AB 1>&3; echo CD 1>&3
$ echo 'x\c' 1>&4; cat file
Quote:> (4) Is "<>" supposed to be used for C-like programs?
This is an ambiguous question.
Quote:> (5) What is the use of "<>" in shell?
see (4) and (1)?
Quote:> (6) Suppose myprog.ksh looks like:
> read -u2 i
> print -u2 $i
> [...] And I run "myprog.ksh 2<> myfile"
But the shell already writes its prompt and diagnostics to STDERR.
Did you have this collision in mind or "exec 3<>file" instead?
The flag "-u" in ksh88 seems to be implemented by handling even more,
internal, file descriptors, which yields "unexpected" results in this
concern. And at least ksh88i-M on SunOS 5.7 even looks buggy here.
Oh, and ksh93 (apparently since the 2nd release of version "n-") keeps
file descriptor 3 to the the shell history file but fails to reopen
it with a higher FD, if you want to use FD 3.
Thus, did you actually have the following in mind?
read i 0<&4
echo $i 1>&4
Quote:> (7) what is /dev/msglog, how it is configured and where it goes?
Haven't you read msglog(7D) and sysmsg(7D) yet?
It ends up in /dev/console; see also xconsole(1) ;-)
Quote:> (8) [...] What do I do to make every start/stop script gets logged?