termios; VMIN overlaps VEOF?
Richard A. O'Keefe
An initial apology for not Reading The Fine Standard myself:
I ordered a copy of the Fine 1003.1 Standard early this year,
but there is an administrative hitch so I haven't got it.
We recently acquired a machine which runs an operating system named after
a story by Stanislaw Lem. It's a lovely fast machine, and I used to have
an extremely high opinion of the UNIX systems shipped by its makers. But
I've run into one or two problems.
Symptom of one of these problems:
stty cooked
trashes my "eof" setting. I normally have "stty eof '^Z'" in effect.
In earlier versions of UNIX from this vendor, the eof character
setting was _never_ changed unless I _explicitly_ changed it. This
is still the case in the BSD systems we are running on some other
machines. However, EVEN WHEN THE TERMINAL IS ALREADY IN A "COOKED"
STATE, so that "stty cooked" finds nothing that needs changing, it
sets eof to '^D'.
I can find nothing whatsoever in the on-line manual page for stty
in either this allegedly SVr4 UNIX nor in IRIX (SVr3) that says
"stty cooked" has any effect on any control character setting at all.
Yet in both it trashes "eof".
QUESTION 1.
Is there anything in 1003.2 which REQUIRES "stty cooked" to change any
control character setting? Specifically VEOF and/or VEOL?
Is there anything in 1003.2 which (implicitly or explicitly) FORBIDS
"stty cooked" from changing control character settings.
Alternatively, if 1003.2 doesn't define "stty cooked", is there anything
other than an explicit reference to a control character setting
which requires or prohibits the alteration of control characters?
I believe I know why this problem exists. There was an unspeakable kluge
back in an early SysV where VMIN and VTIME were bodged into the slots that
VEOF and VEOL normally occupy, and apparently nobody has ever got around
to fixing this. So in <termios.h> on the Lem machine and the IRIX machine
VMIN == VEOF and VTIME == VEOL. This is documented in the IRIX (V.3)
manual page for termios. As far as I can see, the botch is NOT documented
in the termios or termio manual pages on the Lem machine. (The termio
page does give the values of VEOF and VEOL, but not of VMIN or VTIME.)
QUESTION 2.
Is there anything in 1003.1 which REQUIRES <termios.h> to define
VMIN == VEOF and VTIME == VEOL, or which in any other way requires
some control character to be changed when an apparently unrelated
change is made?
Is there anything in 1003.1 which FORBIDS an assignment to
x.c_cc[VMIN] and/or x.c_cc[VTIME] affecting control characters?
A further problem came up.
stty raw
leaves the terminal in a state where the VLNEXT character is
*still* processed.
I find that the stty manual page in IRIX says that
-isig ignores INTR, QUIT, and SWTCH
-icanon ignores ERASE and KILL
-ixon ignores START and STOP
"raw ...(no ERASE, KILL, INTR, QUIT, SWTCH, EOT, or output post processing)"
Presumably EOT here should read EOF.
It doesn't actually promise anything about LNEXT, WERASE, RPRNT, or FLUSH.
The stty manual page on the Lem machine (SVr4) makes the same claim about
-isig, -icanon, and -ixon, and exactly the same statement about "raw".
Again, nothing is said about the behaviour of LNEXT, WERASE, RPRNT, FLUSH
in "raw" mode.
I was _staggered_ to find LNEXT processed in what was allegedly "raw" mode.
That's not how "raw" mode is expected to work!
EOF doesn't have to be trashed to get cooked mode, but
LNEXT processing _does_ have to be inhibited to get true "raw" mode.
QUESTION 3.
Is there anything in 1003.2 which addresses the effect of "stty raw"
on LNEXT, WERASE, or RPRNT processing?
I expected that -icanon would switch off WERASE processing, just like
ERASE and KILL processing. Is this required, prohibited, or what?
(This is both a 1003.2 and 1003.1 question.)
I expected that -icanon would switch of LNEXT processing, it's an
"input canonicalisation" thing to me just like ERASE. Is this
required, prohibited, or what? (Again, 1003.1 termios and 1003.2 stty
might both have something to say.)
I'm not happy about the way the Lem software seems to have dropped FIONREAD
support either, but that's another story. (Yes, I know it's there in an
emulation package for terminals. That wasn't its only use.)
--
Richard A. O'Keefe; o...@goanna.cs.rmit.oz.au; RMIT, Melbourne, Australia.
Volume-Number: Volume 32, Number 24
William L. Jones
o...@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>QUESTION 1.
>
> Is there anything in 1003.2 which REQUIRES "stty cooked" to change any
> control character setting? Specifically VEOF and/or VEOL?
Good questions! This caused a bug in the earlier versions of Emacs 19.
POSOIX 1003.1-1988 says:
"The subscript values shall be unique, execpt that VMIN and VTIME
subscripts may have the same values as the VEOF and VEOL subscripts"
> Is there anything in 1003.2 which (implicitly or explicitly) FORBIDS
> "stty cooked" from changing control character settings.
I think not since VMIN and VTIME can overlap VEOF and VEOL.
If you go for raw to cooked VEOF and VEOL my have to be reset to some default
value.
>I believe I know why this problem exists. There was an unspeakable kluge
>back in an early SysV where VMIN and VTIME were bodged into the slots that
>VEOF and VEOL normally occupy, and apparently nobody has ever got around
>to fixing this. So in <termios.h> on the Lem machine and the IRIX machine
>VMIN == VEOF and VTIME == VEOL. This is documented in the IRIX (V.3)
>manual page for termios. As far as I can see, the botch is NOT documented
>in the termios or termio manual pages on the Lem machine. (The termio
>page does give the values of VEOF and VEOL, but not of VMIN or VTIME.)
Aix 3.2 does the same thing and has the same problem.
>QUESTION 2.
>
> Is there anything in 1003.1 which REQUIRES <termios.h> to define
> VMIN == VEOF and VTIME == VEOL, or which in any other way requires
> some control character to be changed when an apparently unrelated
> change is made?
It allows it. It does not FORBID it.
>A further problem came up.
>
> stty raw
>
> leaves the terminal in a state where the VLNEXT character is
> *still* processed.
My POSIX 1003.1-1988 manual is silent about VLNEXT. This would implie that
it is a (implementation defined) function and should not be used unless
IEXTEN is enabled. The rules on VLNEXT or up to the vendor unless
some newer verions of POSIX defines the behavior of VLNEXT.
>QUESTION 3.
>
> Is there anything in 1003.2 which addresses the effect of "stty raw"
> on LNEXT, WERASE, or RPRNT processing?
POSIX syas WERASE should only work if ICANON is set.
LNEXT and RPRNT look to be (implementation defined) functions. You
will have to read the vendor manual to figure out their behavior.
Bill Jones
Volume-Number: Volume 32, Number 26
Chuck Karish
o...@goanna.cs.rmit.oz.au (Richard A. O'Keefe) wrote:
>We recently acquired a machine which runs an operating system named after
>a story by Stanislaw Lem. It's a lovely fast machine, and I used to have
>an extremely high opinion of the UNIX systems shipped by its makers. But
>I've run into one or two problems.
Sounds like your system isn't as invincible as you might have hoped.
The problem you describe is worthy of an investigation.
> stty cooked
> trashes my "eof" setting.
This is System V behavior, and is not unique to Solaris. Stty does
the same thing on AIX 2.2.1 (SVR2), on SCO UNIX (SVR3) and on 386/AT
from USL (SVR4).
>QUESTION 1.
>
> Is there anything in 1003.2 which REQUIRES "stty cooked" to change any
> control character setting? Specifically VEOF and/or VEOL?
First, let's remind ourselves that Sunsoft does not claim that the
utilities provided with currently'released versions of Solaris
conform to POSIX.2.
'cooked' isn't one of the defined arguments for POSIX.2 stty.
> Is there anything in 1003.2 which (implicitly or explicitly) FORBIDS
> "stty cooked" from changing control character settings.
POSIX.2 stty is supposed to change the particular flags in the
terminal's settings that are specified on the stty command line.
Period.
Of course, since POSIX.2 doesn't specify any set of flags that
constitute the 'cooked' state, there is no such prohibition.
Complain to the vendor, if you will, on the basis that BSD
compatibility is broken. This is not a POSIX.2 issue.
>QUESTION 2.
>
> Is there anything in 1003.1 which REQUIRES <termios.h> to define
> VMIN == VEOF and VTIME == VEOL, or which in any other way requires
> some control character to be changed when an apparently unrelated
> change is made?
No. It is allowed, but not required. Of course, if you set your
terminal to non-canonical mode by 'stty -icanon', non-zero values for
EOF and EOL will set an interbyte timer that may not be what you want
for your session. And if you change these values explicitly, you'll
also have to change EOF and EOL back when you return the terminal
to canonical mode.
> Is there anything in 1003.1 which FORBIDS an assignment to
> x.c_cc[VMIN] and/or x.c_cc[VTIME] affecting control characters?
The overloading noted above is the only permitted interaction.
>I find that the stty manual page in IRIX says that
> -isig ignores INTR, QUIT, and SWTCH
> -icanon ignores ERASE and KILL
> -ixon ignores START and STOP
> "raw ...(no ERASE, KILL, INTR, QUIT, SWTCH, EOT, or output post processing)"
> Presumably EOT here should read EOF.
>It doesn't actually promise anything about LNEXT, WERASE, RPRNT, or FLUSH.
Check the 'termio' manual page, too.
The IEXTEN flag in x.c_lflag should enable or disable these
implementation-defined functions. A POSIX.2 conforming stty
accepts '-iexten' as a valid argument.
>QUESTION 3.
>
> Is there anything in 1003.2 which addresses the effect of "stty raw"
> on LNEXT, WERASE, or RPRNT processing?
No. 'stty raw' is a BSD-ism that's not addressed in POSIX.2.
> I expected that -icanon would switch off WERASE processing, just like
> ERASE and KILL processing. Is this required, prohibited, or what?
> (This is both a 1003.2 and 1003.1 question.)
Unspecified. Recognition of WERASE is an extension that's
not spelled out in either standard, though it is permitted
if IEXTEN is set.
> I expected that -icanon would switch of LNEXT processing, it's an
> "input canonicalisation" thing to me just like ERASE. Is this
> required, prohibited, or what? (Again, 1003.1 termios and 1003.2 stty
> might both have something to say.)
Prohibited. Again, use 'stty -iexten'. To get the state you're asking
for from a POSIX.2 stty, try
stty -icanon -isig -iexten
'stty -icanon' is roughly equivalent to the 4.3 BSD 'stty cbreak'.
Chuck Karish kar...@mindcraft.com
Mindcraft, Inc. (415) 323-9000 x117
Volume-Number: Volume 32, Number 27
Ian Fitchet Ian Fitchet
On 18 Aug 1993, William L. Jones wrote
> POSOIX 1003.1-1988 says:
> "The subscript values shall be unique, execpt that VMIN and VTIME
> subscripts may have the same values as the VEOF and VEOL subscripts"
Ah, mmm. I noticed this effect when playing around with some code
and thought that I was `obviously' mistaken (the usual `I must have
done something else but since what I'm doing works I'll leave it :)').
But this begs the question, if I set VMIN to 1, setting VEOF (or
whatever) to ^A, can I then set VEOF back to ^D (default on my Sun)
without affecting VMIN?
Or am I doomed to have my cake but not eat it?
--
Ian Fitchet I.D.F...@fulcrum.co.uk
Fulcrum Communications ltd., Fordrough Lane, Birmingham, B9 5LD
Volume-Number: Volume 32, Number 28
Guy Harris
>>A further problem came up.
>> stty raw
>>
>> leaves the terminal in a state where the VLNEXT character is
>> *still* processed.
This is a botch in "stty" - in *all* releases from the vendor named
after the Lem novel in question, including the SunOS 4.1.x-based Solaris
1.x releases, not just the SunOS 5.x-based Solaris 2.x releases - which
should turn IEXTEN off if you do "stty raw".
It wasn't true in SunOS 4.0[.x], because IEXTEN wasn't in 4.0[.x];
instead, it turned VLNEXT off if both ICANON and ISIG were turned off,
and "stty raw" obviously turned both of them off.
>POSIX syas WERASE should only work if ICANON is set.
Err, my 1003.1-1988 only mentions WERASE in the Rationale - B.7.1.1.6
"Canonical Mode Input Processing" - wherein it says:
4.3BSD has a WERASE character [yes, I know, they didn't call
it that until 4.3-reno or so, which wasn't out at the time -gh]
that erases the last "word" typed (but not any preceding blanks
or tabs). A word is defined as a sequence of non-blank
characters, with tabs counted as blanks. Like ERASE, WERASE
does not erase beyond the beginning of the line. This WERASE
character has not been specified in the standard because it is
difficult to define in the international environment. It is
only useful for languages where words are delimited by blanks.
and doesn't say anything about whether it should work if ICANON is set
or not.
By its absence from 1003.1-1988's main body, though, it *does* say that
it should *not* work if IEXTEN is not set - that *is*, in fact, the case
in all releases named after the Lem novel in question, whether they're
the SunOS 4.1.x-based Solaris 1.x releases or the SunOS 5.x-based
Solaris 2.x releases.
Does some later 1003.1 mention WERASE in the main body?
Those releases will *also* disable it if ICANON is not set, as one would
expect.
(My main use of WERASE is in a language where words are delimited by
blanks; it's called "the shell". :-))
>LNEXT and RPRNT look to be (implementation defined) functions. You
>will have to read the vendor manual to figure out their behavior.
Both are controlled by IEXTEN in SunOS 4.1.x and SunOS 5.x; RPRNT is
also controlled by ICANON, as one would expect.
Volume-Number: Volume 32, Number 29
Doug Gwyn
In article <24sf6v...@rodan.UU.NET> o...@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>I believe I know why this problem exists. There was an unspeakable kluge
>back in an early SysV where VMIN and VTIME were bodged into the slots that
>VEOF and VEOL normally occupy, ...
Yes, exactly! The switch from "cooked" to "raw" requires that VMIN/VTIME
be set to reasonable values, and the later attempt to rest back to "cooked"
has no record of what the original VEOF/VEOL characters were, so the UNIX
standard values are used.
I forget whether IEEE Std 1003.1 permits (but does not require) this sort of
thing, but new implementations of termios (such as on 4.4BSD) have, and
should take advantage of, the opportunity to correct this design flaw.
(Not strictly an error, since it was originally done under a strict
interface compatibility constraint.)
> Is there anything in 1003.1 which REQUIRES <termios.h> to define
> VMIN == VEOF and VTIME == VEOL, or which in any other way requires
> some control character to be changed when an apparently unrelated
> change is made?
I *am* sure that this is *not* REQUIRED. It might be ALLOWED; I left my
copy of the standard in my other trousers. (Why don't you buy a copy
rather than asking the whole net to read it for you?)
> stty raw
> leaves the terminal in a state where the VLNEXT character is
> *still* processed.
The root problem here is that "raw" is ill-defined. Should in-band
flow control still be honored in "raw" mode? How about parity stripping?
Etc. The traditional "stty raw" didn't have to deal with LNEXT etc.
so on extended systems there is no clear-cut guidance as to what should
be done. PROBABLY, *all* data interpretation (including EOT, NL mapping,
etc.) should be disabled in packaged "raw" mode. Existing stty source
code did not deal with the new features, and probably not taking care of
these extra control characters was an oversight when the old stty code was
ported onto the new tty system.
Anyway, Irix behavior and IEEE Std 1003.2 won't have much to do with
each other until SGI claims 1003.2 conformance for Irix, which I presume
they're working on..
Volume-Number: Volume 32, Number 30
Paul Eggert
gw...@smoke.brl.mil (Doug Gwyn) writes:
>I left my copy of the standard in my other trousers.
>(Why don't you buy a copy rather than asking the whole net to read it for you?)
Asking an academic why he doesn't buy a copy of a Posix standard is a
bit insensitive, since the standards aren't cheap. Many academics are
short of personal funds, and getting a university library to spring for
a copy often involves jumping through bureaucratic hoops that are often
time-consuming and are sometimes insurmountable. O'Keeffe's original
article mentioned this, so I'm surprised Gwyn took him to task.
The real problem here is that Posix standards are not available
electronically at a reasonable price. By insisting on publishing only
in ungreppable formats with large publication delays, and by setting
prices far above distribution costs, the IEEE and the ISO are shirking
their responsibilities to the public.
Volume-Number: Volume 32, Number 32
Jim Haynes
In article <256cup...@rodan.UU.NET> egg...@twinsun.com (Paul Eggert) writes:
>Submitted-by: egg...@twinsun.com (Paul Eggert)
>The real problem here is that Posix standards are not available
>electronically at a reasonable price. By insisting on publishing only
>in ungreppable formats with large publication delays, and by setting
>prices far above distribution costs, the IEEE and the ISO are shirking
One of my pet gripes too. Just look how successful the Internet has been
over the years. I would argue that it's due largely to the fact that the
standards are available on line, anytime, no charge.
--
hay...@cats.ucsc.edu
hay...@cats.bitnet
Volume-Number: Volume 32, Number 34
Ronald F. Guilmette
In article <256cup...@rodan.UU.NET> egg...@twinsun.com (Paul Eggert) writes:
>By insisting on publishing only
>in ungreppable formats with large publication delays, and by setting
>prices far above distribution costs, the IEEE and the ISO are shirking
>their responsibilities to the public.
I wasn't aware that these groups *had* any responsibility to the public!
They certainly have responsibilities to their members, but that's not the
same thing as the public at large.
P.S. I happen to be among those who think that making standards freely
available would be in the best interests of *all* concerned... including
IEEE and ISO members.
--
Ronald F. Guilmette
domain address: r...@netcom.com
uucp address: ...!uunet!netcom.com!rfg
Volume-Number: Volume 32, Number 35
Robin Fairbairns
In article <25b8mp...@rodan.UU.NET>, hay...@cats.ucsc.edu (Jim Haynes) writes:
>One of my pet gripes too. Just look how successful the Internet has been
>over the years. I would argue that it's due largely to the fact that the
>standards are available on line, anytime, no charge.
The RFCs were originally available on a research network to provide
impetus to the development of that network. Fair enough.
However, the RFCs are woefully inadequate when viewed by the sort of
entity that requires formally-tested software procurement. That
community (government and big business) is served by the ISO/IEC
process.
The Posix standards effort was started by IEEE, and only entered the
ISO/IEC arena after the Japanese SSI proposal on operating systems
interfaces had been shot down. IEEE and ISO/IEC make their livings by
selling paper copies of standards; unlike the internet (in the days
when it was the Arpanet) they tend not to have rich uncles to pay for
the development of standards, and hence have no tradition of free
distribution of standards.
The situation is indeed deplorable, but it's only now starting to be
rectified: various schemes for copyright release of ISO/IEC standards
are being tried. A notable example is the OSI abstract test suite
standards, which need to be available machine-readable to do the job.
--
Robin (Keep Radio 3 != Classic FM) Fairbairns r...@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge CB2 3QG, UK
Volume-Number: Volume 32, Number 36
Richard A. O'Keefe
On 18 Aug 1993, William L. Jones wrote
> POSIX 1003.1-1988 says:
> "The subscript values shall be unique, execpt that VMIN and VTIME
> subscripts may have the same values as the VEOF and VEOL subscripts"
This afternoon my copy of AS 3976.1-1991 = ISO/IEC 9945-1:1990
finally arrive. I find that s 7.1.2.6 ll 505-506 has this very same
text. This tells me several things:
(a) POSIX programs that change VMIN and/or VTIME *must* remember the
VEOF and/or VEOL settings and restore them, even though they did
not intend to change them and have no source code that appears to
change them.
(b) If you are big enough, and wait long enough, you have have your
bugs written into the standard.
> But this begs the question, if I set VMIN to 1, setting VEOF (or
> whatever) to ^A, can I then set VEOF back to ^D (default on my Sun)
> without affecting VMIN?
>
> Or am I doomed to have my cake but not eat it?
Table 7-5 in the standard makes this quite clear:
- in canonical mode, VEOF and VEOL are heeded, but VMIN and VTIME are not.
- in non-canonical mode, VMIN and VTIME are heeded, but not VEOF or VEOL.
Combine this with 7.1.2.6, and you find
- when you switch from canonical to non-canonical mode,
you must set VMIN and VTIME, because they _may_ have been holding
the EOF and EOL values.
- when you switch from non-canonical to canonical mode,
you must set VEOF and VEOL, because they _may_ have been holding
the MIN and TIME values.
In a program, you maintain and "old" and "new" struct termios anyway.
It is now clear that you have to do the same in shell scripts;
- save the current settings using
x="`stty -g`"
- when changing to the new mode, explicitly set EOF&EOL if canonical,
MIN&TIME if non-canonical
- when changing back, don't rely on undoing single changes, change
back to the full set of saved parameters
stty "$x"
(Not yet having 1003.2, I apologise if this use of stty is nonstandard.)
Certainly on a Sun running Solaris 2.2, "stty min 1" sets EOF to ^A
(this is accepted even when the resulting mode is canonical; I for one
would appreciate a warning message "min=1 meaningless combined with +icanon")
and then "stty eof '^D' sets min to 4 (again, this is accepted even when the
resulting mode is noncanonical; I would appreciate a warning message
"eof=4 meaningless combined with -icanon").
Presumably this is a quality of implementation issue.
--
Richard A. O'Keefe; o...@goanna.cs.rmit.oz.au; RMIT, Melbourne, Australia.
Volume-Number: Volume 32, Number 37
David Emery
The funding issue for IEEE is a serious question. Without the income
from sale of standards, the IEEE's Standards Department would be
either cut way back or eliminated altogether. (And, having worked
with them, most of them *do* earn their pay.) If we go to on-line
distribution of standards (which I think is an excellent idea) then we
need to come up with an alternate way to fund the IEEE Standards
Department.
dave
Volume-Number: Volume 32, Number 38
Jim Haynes
In article <25dkdr...@rodan.UU.NET> r...@cl.cam.ac.uk (Robin Fairbairns) writes:
>interfaces had been shot down. IEEE and ISO/IEC make their livings by
>selling paper copies of standards; unlike the internet (in the days
>when it was the Arpanet) they tend not to have rich uncles to pay for
>the development of standards, and hence have no tradition of free
>distribution of standards.
Well it's just this that I'm complaining about. Actually IEEE doesn't make
its living by selling copies of standards; at least I'm paying close to
$100 a year to be a member, and I still have to pay as much as anybody else
if I want a copy of a standard. Actually I believe the charges for copies
of standards don't begin to pay for the cost of the standards process:
companies that care and can afford to send their employees at company
expense to the meetings where standards are debated, so there is a lot
of money going into the process.
It's not the price of standards per se that is such an annoyance; it's
the cost of all the administration connected with it. Because money
has to change hands and paper copies have to be shipped around and
there's forms to fill out and time to wait while things are in the mail.
Then there's the costs to the whole industry when people don't know that
a standard even exists, so they invent a new non-standard way of doing
the job. Or they know the standard exists but they don't want to go
to the trouble of ordering a copy, so they get some idea what it says
through hearsay and then proceed to implement something that doesn't
quite conform.
--
hay...@cats.ucsc.edu
hay...@cats.bitnet
"Ya can talk all ya wanna, but it's dif'rent than it was!"
"No it aint! But ya gotta know the territory!"
Meredith Willson: "The Music Man"
Volume-Number: Volume 32, Number 39
Richard A. O'Keefe
In article <253fl3...@rodan.UU.NET>, gw...@smoke.brl.mil (Doug Gwyn) writes:
> I *am* sure that this is *not* REQUIRED. It might be ALLOWED; I left my
> copy of the standard in my other trousers. (Why don't you buy a copy
> rather than asking the whole net to read it for you?)
I agree that it is good manners to Read The Fine Standard, and I
apologised at the beginning of my posting for not doing so. I thought
to spare the net a recital of my misfortunes:
(0) After paying the next mortgage payment, I'll have about AUD 200
in the bank. That has to support two adults for two weeks. So
you will appreciate that more than sloth prevents me trundling
down to Standards Australia and paying for my own copy (AUD 90).
(1) Therefore, about six months ago I ordered a copy through the
otherwise admirable institution for which I work, on the grounds
that as our students have to use UNIX, it would be a good idea to
know for sure what that is supposed to mean.
(2) Notwithstanding (0), the delay was such that I _did_ trundle down
to Standards Australia (hoping to use their reading room) before
posting my request, only to find that they have moved.
(3) The copy I had ordered finally arrived this afternoon.
Now that I have it, I am reading it, and intend to refer to it
frequently. (It will replace my battered SVID.)
I actually asked about _two_ standards, 1003.1 and 1003.2. It was only
recently that we were informed in this newsgroup that 1003.2 had been
"sent to the printers". It certainly isn't available in Australia yet,
so to the best of my knowledge I currently have no alternative but to
ask in this group.
> > stty raw
> > leaves the terminal in a state where the VLNEXT character is
> > *still* processed.
>
> The root problem here is that "raw" is ill-defined. Should in-band
> flow control still be honored in "raw" mode? How about parity stripping?
It's not as ill-defined as that. The manual pages I've been working from
explicitly say that raw is 8-bit (no parity stripping) and -ixoff (no
in-band flow control). The traditional V7 "raw" mode was very simply
defined in concept: in raw mode _no_ characters are special, _all_ are
data. I have been informed by others in this group that "raw" is in
itself considered a BSD-ism, so presumably the best approximation to BSD
semantics should apply.
> Etc. The traditional "stty raw" didn't have to deal with LNEXT etc.
That stream of the tradition which had an LNEXT to deal with did deal
with it. If one is going to be BSD-compatible with respect to _having_
an LNEXT character, one would do well to be BSD-compatible with respect
to what stty raw does about it. I have been assured that stty raw
"ought" to set -iexten.
Thank you to everyone who helped with this problem.
--
Richard A. O'Keefe; o...@goanna.cs.rmit.oz.au; RMIT, Melbourne, Australia.
Volume-Number: Volume 32, Number 40
David A Willcox
hay...@cats.ucsc.edu (Jim Haynes) writes:
>Well it's just this that I'm complaining about. Actually IEEE doesn't make
>its living by selling copies of standards; at least I'm paying close to
>$100 a year to be a member, and I still have to pay as much as anybody else
>if I want a copy of a standard.
Not true. IEEE members get a price break when buying IEEE
publications. I don't have a copy of the publications catalog handy
here, but if memory serves me members pay about $20 less for POSIX.1
than nonmembers.
>Actually I believe the charges for copies
>of standards don't begin to pay for the cost of the standards process:
>companies that care and can afford to send their employees at company
>expense to the meetings where standards are debated, so there is a lot
>of money going into the process.
Participants pay about $200/meeting for the privilege of sitting
around tables to debate whether {PATH_MAX} includes the trailing null
in a pathname. That fee is supposed to cover the costs of running
the meetings: room rental (when necessary), reproduction fees,
conference organization, breakout refreshments, stuff like that.
In addition, balloters pay $25 for the privilege of reading, in fine
detail, three or four versions of a hundreds-of-pages document, picking
out glaring errors and possible misinterpretations due to shadings of
meaning, and submitting detailed reviews.
And finally, you can get a subscription to working group documentation,
paying to receive copies of all of the proposals and drafts of your
favorite collection of working groups.
[ I think this thread is about beaten to death... next topic,
anyone? -- mod ]
Volume-Number: Volume 32, Number 41
John F. Haugh II
In article <253fl3...@rodan.UU.NET> gw...@smoke.brl.mil (Doug Gwyn) writes:
>In article <24sf6v...@rodan.UU.NET> o...@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>>Is there anything in 1003.1 which REQUIRES [...]
>>some control character to be changed when an apparently unrelated
>>change is made?
>I *am* sure that this is *not* REQUIRED. It might be ALLOWED; I left my
>copy of the standard in my other trousers.
It is allowed but not required (7.1.2.6). What troubles me is that this
violates the statement in the Rationale that you should only change the
fields which you need to change. Going from raw to cooked requires that
you change VMIN/VTIME or VEOF/VEOL as well as ICANON.
--
John F. Haugh II [ PGP 2.1 ] !'s: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 251-2151 [ DoF #17 ] [ PADI ] @'s: j...@rpp386.cactus.org
Volume-Number: Volume 32, Number 42
Ronald F. Guilmette
As a member in good standard of the IEEE and the IEEE Computer Society,
I should say that I for one would be more than willing to pay some modest
increase in the Computer Society dues in order to make it possible for
me, you, and everybody else to obtain these documents on-line. Hell.
It would be worth at least a hundred bucks to me right now just to be
able to grep the POSIX 1003.1 standard! I'd also be more than happy if
the IEEE made that same document available freely, and if someone came
around next week trying to sell me an X windows based hypertext version
that gave me the ability to look at all sections relevant to a given
topic without having to stick 18 different pencils in the book to keep
track of them all! I wouldn't even mind if the vendor of such a product
wanted to charge me money for this "free" information. I'd consider a
properly cross-referenced hypertext version of the standard a valuable
serivce... one which I cannot buy for love or money at the moment.
--
Ronald F. Guilmette
domain address: r...@netcom.com
uucp address: ...!uunet!netcom.com!rfg
Volume-Number: Volume 32, Number 45
Mark
In article <25dkbt...@rodan.UU.NET> r...@netcom.com (Ronald F. Guilmette) writes:
>>By insisting on publishing only
>>in ungreppable formats with large publication delays, and by setting
>>prices far above distribution costs, the IEEE and the ISO are shirking
>>their responsibilities to the public.
>
>I wasn't aware that these groups *had* any responsibility to the public!
Anti-trust laws apply. I don't think it's wrong to require substantial
payment for what has turned out to be a document that is necessary to
participation in an industry, I think it's illegal.
Volume-Number: Volume 32, Number 46
Mark
In article <25e0q3...@rodan.UU.NET> em...@goldfinger.mitre.org (David Emery) writes:
>The funding issue for IEEE is a serious question. Without the income
>from sale of standards, the IEEE's Standards Department would be
>either cut way back or eliminated altogether...
The real question is what justifies their existence in the first place, or
(at the very least) their role in the development of software standards.
A standard created by the collective efforts of its users (on the network
itself, by the network, for the network) would have a far wider, far more
efficient, and cost-effective basis to work from and would end up being of
much higher quality.
If you can't make money conducting business in a reasonable way (meaning
by not gouging everyone), then you have no business being in that business.
Volume-Number: Volume 32, Number 47
Peter H. Salus
In article <25e0q3...@rodan.UU.NET> em...@goldfinger.mitre.org (David Emery) writes:
>The funding issue for IEEE is a serious question. Without the income
>from sale of standards, the IEEE's Standards Department would be
>either cut way back or eliminated altogether. (And, having worked
Well, gee. That's really a great idea, David. Perhaps
we could be like other countries and *not* have a professional
organization do standards. If POSIX had been run from the
start the way other standards were done internationally,
maybe we wouldn't have the bizarre number of dots nor the
insane number of people at meetings. Let's just do away
with the IEEE Standards Department. Let's let ANSI and
NIST do the job.
--
Peter H. Salus #3303 4 Longfellow Place Boston, MA 02114
+1 617 723-3092
[ Okay, I think this horse is just about beaten into juice... -- mod ]
Volume-Number: Volume 32, Number 48
Jason Zions
I know the moderator believes the issue has been pounded into the dirt, but
some frighteningly obvious facts of life have been ignored.
ma...@csd4.csd.uwm.edu (Mark) says:
>Anti-trust laws apply. I don't think it's wrong to require substantial
>payment for what has turned out to be a document that is necessary to
>participation in an industry, I think it's illegal.
Let me get this straight - $95 is too big a burden? The cheapest monitor for
a computer, also necessary for participation in this industry, costs
more. Should monitor manufacturers give them away for nothing?
How big is the market for printed versions of 1003.1-1990? At a guess - 5000
copies. Talk to a printer and ask for an estimate on 5000 copies of a
400-page book printed on A4 paper. You'll find that a substantial fraction
of the cost of a copy of 1003.1-1990 is eaten up in just the cost of
printing the thing.
A small word on that note - 1003.2-1993 is *cheaper* than it might otherwise
be, because it is large enough that the IEEE got a price break on the paper
for the book. (True fact!)
As for anti-trust, forget it; meetings are open, anyone can attend for the
cost of attendence. Anyone can play for the low cost of around $0.05 per
page in mailing fees, and you don't even need to get the mailings. Believe
me, concern about even appearing to violate anti-trust laws is strong.
>The real question is what justifies their existence in the first place, or
>(at the very least) their role in the development of software standards.
>A standard created by the collective efforts of its users (on the network
>itself, by the network, for the network) would have a far wider, far more
>efficient, and cost-effective basis to work from and would end up being of
>much higher quality.
Really? Have you examined samples of your writing lately? *Someone* has to
check for incorrect punctuation, slang, misspellings, consistency with ITTF
and ANSI guidelines for standards, etc. Someone has to be responsible for
counting ballots, checking ballot group membership, issuing calls for
ballot, etc. Up until a year ago, joining a ballot group was free - someone
had to pay the cost of photocopying the documents and mailing them. 1003.8
just came out for recirculation. Mailing cost was $2.90 in postage within
the US, doubtlessly more costly to an international balloter. This standard
is small as POSIX specs go; only 150 pages. At 4 cents per image, that's
$6.00 for the draft. Add ten cents for the envelope, and this recirc cost
nine dollars. There will be two more recircs, which will be no less
expensive; add in the original ballot round, and you get a minimum cost of
$36. It cost $25 to join in the first place.
>If you can't make money conducting business in a reasonable way (meaning
>by not gouging everyone), then you have no business being in that business.
I encourage you to do it. Follow ANSI rules to become an Accredited
Standards Committee (required by US law to make national standards). Talk to
publishers about the economics of small runs of books. Hire an editor or
two; your language skills, frankly, aren't up to the task. If you believe
you can make money and charge less, go for it!
Peter Salus says:
>Perhaps we could be like other countries and *not* have a professional
>organization do standards.
Peter, you ought to know better. Just what do you think AFNOR, DIN, BSI, and
the rest are? ANSI is far smaller than any of those organizations, precisely
because it farms the work out to any group willing to become accredited in
some subject area. These are all professional organizations, but at least in
the US the profession is related to the subject matter of the standard; in
the rest of the world, the profession practiced by the organization is that
of Standards-Making. Do you want another OSI? Thank you, no.
> If POSIX had been run from the start the way other standards were done
>internationally, maybe we wouldn't have the bizarre number of dots nor the
>insane number of people at meetings.
What bizarre number of dots? What the internal workings of the standards
committee decide to call things before they are published has nothing to do
with the actual numbers under which they are published. I suppose you think
a totally-flat numbering scheme which shows no relationship between related
documents is better? So far we have 1003.1, 1003.2, 1003.3, 1003.5, 1003.9,
2003.1 (the test methods for 1003.1 - isn't that nice?). Quick - name the
ISO standards for the lower four layers of the OSI stack. Gotta look'em up?
That's helpful. ISO standards for codesets? 8859/1, 8859/2, 8859/3, etc. Is
"/" more acceptable than "."? Oh, yes, don't forget the successor standard,
10646. (Trivially derivable from 8859, isn't it.)
> Let's just do away with the IEEE Standards Department. Let's let ANSI
>and NIST do the job.
ANSI *is* doing their job; they delegate and manage the work. As for NIST,
they're the ones who tried to shove OSI down our throats, who continue to
shove Ada down our throats, who'd like to shove Clipper down our throats,
etc. and so forth.
NIST isn't evil - they just have a different set of interests from that of
many other participants in this business. The volunteer standards system
within the US takes cognizence of this simple fact - there is a large
variety of interests involved in each standard to be made, and an
appropriate forum should be selected in which those interests can work
together to reach concensus. The model in most other countries is that the
only relevant interest is the state's interest; sometimes that interest is
defined by a single dominant vendor (Bull or IBM in France; Siemens or IBM
in Germany; get it?), and sometimes it's just the state's opinion; the
opinion of the little company is never sought, not listened to, not
relevant.
Jason Zions
(Although I am an officer of an IEEE standards project, in no way am I
speaking on behalf of the IEEE, IEEE-CS, IEEE-CS PASC, or any body or
component thereof.)
Volume-Number: Volume 32, Number 49
David Emery
If you think ANSI is free, think again! ANSI membership costs $10k,
if I remember right. I think ANSI is having some financial problems,
in part because companies are becoming less willing to fork out the
$10k for membership. Besides, I think you have to pay for copies of
ANSI standards, too. Many of the ANSI standards have been developed
by other groups such as the IEEE, and ANSI provides the U.S. Member
Body adoption of the standard.
NIST is *not* a standards developer. It is a government agency that
adopts selected standards developed by standards developers, such as
ANSI and IEEE, for government use. Should NIST become the tax-funded
standards development body for the U.S.? I don't think so, but that's
another topic...
I don't know exactly how other country's standards bodies are funded,
but I do know that these are non-trivial organizations that have to be
funded somehow.
And, if you think that POSIX has "bizarre number of dots [and] the
insane number of people at meetings", then you haven't looked at the
work programs for ISO/IEC JTC1 or ANSI X3. The big difference between
POSIX and the other standards activities that I've been associated
with, is that the POSIX effort provides an umbrella for getting people
working on related standards to work together. The more common model
is for each group to meet independently, and any coordination/commonality
between standards groups is purely accidental. I'm not a fan of the
various POSIX Steering Committees, but I am a big fan of the 'joint
meeting/BOFs' that take place just because POSIX.n (for all n in
POSIX) happen to be meeting in the same hotel.
dave
Volume-Number: Volume 32, Number 57
Andrew Hume
jason makes several good points but i'll quibble with a couple.
In article <25upa4...@rodan.UU.NET>, ja...@hal.com (Jason Zions) writes:
> Submitted-by: ja...@hal.com (Jason Zions)
> Let me get this straight - $95 is too big a burden? The cheapest monitor for
> a computer, also necessary for participation in this industry, costs
> more. Should monitor manufacturers give them away for nothing?
of course $95 isn't too much -- if that was the only one
you needed and you were able to determine the exact number first off.
the trouble is, as has been pointed out many times, we don't often
know exactly which standard to get. (as a different example, what
standards (or ccitt recommendations) do you need to program
a fax modem to recieve group 3 fax and parse the group 3 fax?)
> How big is the market for printed versions of 1003.1-1990? At a guess - 5000
> copies. Talk to a printer and ask for an estimate on 5000 copies of a
> 400-page book printed on A4 paper. You'll find that a substantial fraction
> of the cost of a copy of 1003.1-1990 is eaten up in just the cost of
> printing the thing.
bollocks. i am co-editor of teh 10th edition of the Reserach Unix manuals.
it consists of two 700-odd page volumes printed on roughly 7x9 pages
photoreduced down from 8.5x11 originals. this is a slight tradeoff of
quality but the reduced bulk, weight and cost is well worth it.
i believe, but cannot be held to, the cost to the publisher of printing
thses manuals (and the run was only 2-3000 i think, may be 5000 at most),
was about $3 per volume. of course, storage and other overhead counts
for some too but if you provide camera-ready originals and sell
the books yourself, the answer is at most $5 per volume.
> [in repsonse to standards created on network, for network]
> Really? Have you examined samples of your writing lately? *Someone* has to
> check for incorrect punctuation, slang, misspellings, consistency with ITTF
> and ANSI guidelines for standards, etc. Someone has to be responsible for
> counting ballots, checking ballot group membership, issuing calls for
> ballot, etc. ....
there is no additional problem. there are three aspects to a standard:
the first part is establishing technical content (RFCs are fine examples)
in whatever format (informal, such as man pages, are fine), the second
is rewriting these in very precise language (standardese to some but the
goal is precision, not obfuscation) and adding necessary things like
conformances clauses, and the third is recasting this content in some
essentially arbitrarily syntactically different format for various
destination standards processes.
the network collaboration will work fine for the first part
(although i have seen several issues that could only be worked out
face to face). the second is hard but the job of one editor and
diligent reviewers (this is true in both committee and network cases).
all the editors i have seen in committees are volunteers.
the third aspect is (i think) largely bullshit work, conforming
your document to some beauracrat's idea of what standards should look like
(although very occasionally, there is something of interest).
> Peter, you ought to know better. Just what do you think AFNOR, DIN, BSI, and
> the rest are? ANSI is far smaller than any of those organizations, precisely
> because it farms the work out to any group willing to become accredited in
> some subject area. These are all professional organizations, but at least in
> the US the profession is related to the subject matter of the standard; in
> the rest of the world, the profession practiced by the organization is that
> of Standards-Making. Do you want another OSI? Thank you, no.
and
> ANSI *is* doing their job; they delegate and manage the work. ....
well, i just wish ANSI was professional. it is a total nightmare
to be involved with internation issues through ANSI. they lose stuff,
delay stuff, and generally act as a clogged pipe. most of the time,
the 6 month ISO balloting period allows technical committees within X3
about 2 weeks to respond, sometimes to quite large documents. this is
caused by the delays in passing documents from ISO to ANSI to X3 to committee
and then having to submit to process and ballot reponses and pass responses
all teh way back up (and lord help you if teh ISO draft involves multiple
US committees and all those reposnses have to be coordinated).
while OSI is justifiably teh modern day equivalent of teh bogey man,
it is not the result of being expert at standards-making. it has more
to do with managing 100s of people wanting to do communication standards.
Volume-Number: Volume 32, Number 58