[1003.1(2013)/Issue7+TC1 0000877]: tail should support the -r option

[Austin Group Bug Tracker]

The following issue has been SUBMITTED.
======================================================================
http://austingroupbugs.net/view.php?id=877
======================================================================
Reported By: joerg
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 877
Category: Shell and Utilities
Type: Enhancement Request
Severity: Editorial
Priority: normal
Status: New
Name: Jörg Schilling
Organization:
User Reference:
Section: tail
Page Number: 3239
Line Number: 108597-108742
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-09-18 12:47 UTC
Last Modified: 2014-09-18 12:47 UTC
======================================================================
Summary: tail should support the -r option
Description:
UNIX systems include support for tail -r since at least 1980.
The POSIX standard should follow existing practice.
Desired Action:
Change line 108600 from:

tail [−f] [−c number|−n number] [file]
to:
tail [−f | -r] [−c number|−n number] [file]

After line 108631 add:

-r Reverse. Copies lines from the specified starting
point in the file in reverse order. The default for r
is to print the entire file in reverse order.

======================================================================

Issue History
Date Modified Username Field Change
======================================================================
2014-09-18 12:47 joerg New Issue
2014-09-18 12:47 joerg Name => Jörg Schilling
2014-09-18 12:47 joerg Section => tail
2014-09-18 12:47 joerg Page Number => 3239
2014-09-18 12:47 joerg Line Number => 108597-108742
======================================================================

[Thomas Dickey]

----- Original Message -----
| From: "Austin Group Bug Tracker" <noreply-***@public.gmane.org>
| To: austin-group-l-7882/***@public.gmane.org
| Sent: Thursday, September 18, 2014 8:47:40 AM
| Subject: [1003.1(2013)/Issue7+TC1 0000877]: tail should support the -r option

Post by Austin Group Bug Tracker
UNIX systems include support for tail -r since at least 1980.

It would be nice to have a verifiable reference for this statement.

Post by Austin Group Bug Tracker
The POSIX standard should follow existing practice.

z/OS does not document this feature.

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/tail.htm?lang=en

[Thomas Dickey]

Post by Thomas Dickey

Post by Austin Group Bug Tracker
UNIX systems include support for tail -r since at least 1980.

It would be nice to have a verifiable reference for this statement.

Post by Austin Group Bug Tracker
The POSIX standard should follow existing practice.

z/OS does not document this feature.
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa500/tail.htm?lang=en

Additionally, it does not appear in this HPUX documentation:

http://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/tail.1.html

[Joerg Schilling]

Post by Thomas Dickey
----- Original Message -----
| Sent: Thursday, September 18, 2014 8:47:40 AM
| Subject: [1003.1(2013)/Issue7+TC1 0000877]: tail should support the -r option

Post by Austin Group Bug Tracker
UNIX systems include support for tail -r since at least 1980.

It would be nice to have a verifiable reference for this statement.

Use the Source Luke...

Most UNIX people have access to UNIX sources and even if you do not have a
relation to a university, it is possible to get the CSRG source suite that
includes a SCCS history for BSD UNIX between aprox. 1977 and 1994.

If you need a recent portable SCCS to look at the history files, I recommend to
use the latest source at:

http://sourceforge.net/projects/schilytools/files/

Today,
http://sourceforge.net/projects/schilytools/files/schily-2014-09-17.tar.bz2

is recent. From time to time there are "releases" at:

http://sccs.sourceforge.net/

The history file for tail.c starts in 1980 and includes the -r option already.
Tail -r is of course also supported by all SunOS/Solaris releases.

Jörg

[Bill Bogstad]

On Fri, Sep 19, 2014 at 12:16 PM, Joerg Schilling

Post by Joerg Schilling

Post by Thomas Dickey
----- Original Message -----
| Sent: Thursday, September 18, 2014 8:47:40 AM
| Subject: [1003.1(2013)/Issue7+TC1 0000877]: tail should support the -r option

Post by Austin Group Bug Tracker
UNIX systems include support for tail -r since at least 1980.

It would be nice to have a verifiable reference for this statement.

Use the Source Luke...
Most UNIX people have access to UNIX sources and even if you do not have a
relation to a university, it is possible to get the CSRG source suite that
includes a SCCS history for BSD UNIX between aprox. 1977 and 1994.
If you need a recent portable SCCS to look at the history files, I recommend to
http://sourceforge.net/projects/schilytools/files/
Today,
http://sourceforge.net/projects/schilytools/files/schily-2014-09-17.tar.bz2
http://sccs.sourceforge.net/
The history file for tail.c starts in 1980 and includes the -r option already.
Tail -r is of course also supported by all SunOS/Solaris releases.

Which would seem to indicate that this is a BSDism which was never picked up by
"pure"System V systems. Nor does it seem to be in GNU tail which
means that it probably isn't on most Linux distributions. So "tail
-r" is current practice for Unix-like systems derived
from BSD releases, but apparently not most System V or GNU/Linux systems.

The current GNU info file manual also claims that the BSD
implementation is limited to the last 32K of a file and people should
use the "tac" command instead.

https://www.gnu.org/software/coreutils/manual/html_node/tail-invocation.html

Whether BSD alone is sufficient current practice to justify changing
POSIX, I will let others with more experience in standards wrangling
decide.

Bill Bogstad

[Joerg Schilling]

Post by Bill Bogstad

Post by Joerg Schilling
The history file for tail.c starts in 1980 and includes the -r option already.
Tail -r is of course also supported by all SunOS/Solaris releases.

Which would seem to indicate that this is a BSDism which was never picked up by
"pure"System V systems. Nor does it seem to be in GNU tail which
means that it probably isn't on most Linux distributions. So "tail
-r" is current practice for Unix-like systems derived
from BSD releases, but apparently not most System V or GNU/Linux systems.

Given the fact that tail -r is supported by all SunOS5.x releases verifies that
most System V installations support tail -r.

tac is a linux progam and not available on a typical UNIX installation. As we
did already add GNU only features to POSIX in the past, I see no problem with
adding a feature that is available on the majority of the UNIX system already.

Jörg

[Scott Lurndal]

Post by Bill Bogstad

Post by Joerg Schilling
The history file for tail.c starts in 1980 and includes the -r option already.
Tail -r is of course also supported by all SunOS/Solaris releases.

Which would seem to indicate that this is a BSDism which was never picked up by
"pure"System V systems.

It was certainly supported the SVR4.2ES/MP release, likely as
a result of the merge-in of various BSD user-level utilities
in the SVR4 timeframe.

scott

[Thomas E. Dickey]

Post by Scott Lurndal

Post by Bill Bogstad

Post by Joerg Schilling
The history file for tail.c starts in 1980 and includes the -r option already.
Tail -r is of course also supported by all SunOS/Solaris releases.

Which would seem to indicate that this is a BSDism which was never picked up by
"pure"System V systems.

It was certainly supported the SVR4.2ES/MP release, likely as
a result of the merge-in of various BSD user-level utilities
in the SVR4 timeframe.
scott

I recall reading that HPUX was the last of the (three?) systems to get SVr4.
Perhaps that is relevant.

I can test a few versions of HPUX, to be certain that the documentation is not misleading.

Post by Scott Lurndal
tail -r foobar

Usage: tail [-f] [-b number] [file]
tail [-f] [-c number] [file]
tail [-f] [-n number] [file]
Obsolescent usage: tail [+-[n][l|b|c]] [-f] [file]

(for z/OS, I’ll have to rely upon the documentation).

[Guido Berhoerster]

Post by Scott Lurndal

Post by Bill Bogstad

Post by Joerg Schilling
The history file for tail.c starts in 1980 and includes the -r option already.
Tail -r is of course also supported by all SunOS/Solaris releases.

Which would seem to indicate that this is a BSDism which was never picked up by
"pure"System V systems.

It was certainly supported the SVR4.2ES/MP release, likely as
a result of the merge-in of various BSD user-level utilities
in the SVR4 timeframe.

UnixWare 7.1.4 which is based on SVR4.2MP supports tail -r,
OpenServer 5 which is based on SVR3 does not, so that seems to be
consistent with the above.

[Garrett Wollman]

Post by Joerg Schilling
Most UNIX people have access to UNIX sources and even if you do not have a
relation to a university, it is possible to get the CSRG source suite that
includes a SCCS history for BSD UNIX between aprox. 1977 and 1994.

For those who wish to use more modern technology, see
<http://svnweb.freebsd.org/csrg/>.

-GAWollman

[Joerg Schilling]

Post by Garrett Wollman

Post by Joerg Schilling
Most UNIX people have access to UNIX sources and even if you do not have a
relation to a university, it is possible to get the CSRG source suite that
includes a SCCS history for BSD UNIX between aprox. 1977 and 1994.

For those who wish to use more modern technology, see
<http://svnweb.freebsd.org/csrg/>.

It is disputable whether svn could be seen as "modern technology".

In any way, this is a transformed copy and not the original history.
It most likely has modified or reduced meta data as svn does not suport all
SCCS features. To beable to decide on things, a correct view on the meta data
is important.

So I recommend to stay with the original. The SCCS history is on CD#4.

See e.g.:

http://www.filewatcher.com/b/ftp/ftp.mrynet.com/operatingsystems/CSRG-0.html


Jörg

[Steffen Nurpmeso]

Joerg Schilling <Joerg.Schilling-8LS2qeF34IpklNlQbfROjRvVK+***@public.gmane.org> wrote:
|Garrett Wollman <wollman-EfZU8u+***@public.gmane.org> wrote:
|> <<On Fri, 19 Sep 2014 12:16:02 +0200, Joerg Schilling <J\
|> oerg.Schilling-8LS2qeF34IpklNlQbfROjRvVK+***@public.gmane.org> said:
|>> Most UNIX people have access to UNIX sources and even if \
|>> you do not have a
|>> relation to a university, it is possible to get the CSRG \
|>> source suite that
|>> includes a SCCS history for BSD UNIX between aprox. 1977 and 1994.
|>
|> For those who wish to use more modern technology, see
|> <http://svnweb.freebsd.org/csrg/>.

Oh, how nice that is, thank you!

Why is it that such a great repository is not also mirrored like
all the other FreeBSD repos (via git(1) in my personal case)?
That would be *so* nice from you devilish ones!

|It is disputable whether svn could be seen as "modern technology".

(Now then i have found the announcement mail via a very large
search engine and downloaded the tarball pointed to therein, and
that is not so nice, as it contains -- not an exported dump, but
a myriads of intransparent files, the i think binary repository
DB.)

|In any way, this is a transformed copy and not the original history.
|It most likely has modified or reduced meta data as svn does not suport all
|SCCS features. To beable to decide on things, a correct view \
|on the meta data
|is important.
|
|So I recommend to stay with the original. The SCCS history is on CD#4.

Hrm, of course buying the CD-set is for the morally superior among us!

|See e.g.:
|
|http://www.filewatcher.com/b/ftp/ftp.mrynet.com/operatingsystems/CSRG-0.html

The hare sits snug in leaves and grass
And laughs to see the green man pass.

--steffen

[Guido Berhoerster]

Post by Steffen Nurpmeso
|> <<On Fri, 19 Sep 2014 12:16:02 +0200, Joerg Schilling <J\
|>> Most UNIX people have access to UNIX sources and even if \
|>> you do not have a
|>> relation to a university, it is possible to get the CSRG \
|>> source suite that
|>> includes a SCCS history for BSD UNIX between aprox. 1977 and 1994.
|>
|> For those who wish to use more modern technology, see
|> <http://svnweb.freebsd.org/csrg/>.
Oh, how nice that is, thank you!
Why is it that such a great repository is not also mirrored like
all the other FreeBSD repos (via git(1) in my personal case)?
That would be *so* nice from you devilish ones!

Here you go:

https://github.com/weiss/original-bsd (converted from FreeBSD SVN repo)
https://github.com/jonathangray/csrg (SCCS metadata directly converted to git)

[Joerg Schilling]

Post by Steffen Nurpmeso
|> For those who wish to use more modern technology, see
|> <http://svnweb.freebsd.org/csrg/>.
Oh, how nice that is, thank you!
Why is it that such a great repository is not also mirrored like
all the other FreeBSD repos (via git(1) in my personal case)?
That would be *so* nice from you devilish ones!
|It is disputable whether svn could be seen as "modern technology".
(Now then i have found the announcement mail via a very large
search engine and downloaded the tarball pointed to therein, and
that is not so nice, as it contains -- not an exported dump, but
a myriads of intransparent files, the i think binary repository
DB.)

Check e.g. lib/libcompat/4.3/insque.c:

/*--------------------------------------------------------------------------*/
sccs prs -a CSRG_Archive_4/lib/libcompat/4.3/SCCS/s.insque.c
CSRG_Archive_4/lib/libcompat/4.3/SCCS/s.insque.c:

D 8.1 93/06/04 16:25:04 bostic 6 3 00002/00002/00028
MRs:
COMMENTS:
4.4BSD snapshot (revision 8.1); add 1993 to copyright

R 5.5 91/03/19 19:18:44 bostic 5 4 00006/00002/00026
MRs:
COMMENTS:
define the structures, no longer defined in unistd.h

R 5.4 91/02/23 19:49:51 donn 4 3 00008/00010/00020
MRs:
COMMENTS:
Add include files to get prototype declarations, and fix bugs found.

D 5.3 90/06/01 14:11:58 bostic 3 2 00001/00011/00029
MRs:
COMMENTS:
new copyright notice

D 5.2 88/07/21 11:31:59 bostic 2 1 00014/00003/00026
MRs:
COMMENTS:
add Berkeley specific copyright; written by Robert Elz

D 5.1 87/01/27 16:07:57 mckusick 1 0 00029/00000/00000
MRs:
COMMENTS:
add to portability library
/*--------------------------------------------------------------------------*/

There are removed deltas that do not appear in svn. There may be other meta
data that also vanished.

You may also be interested in files like bin/ls/ls.c
to understand that the extracted version from the svn did not expand the file
content for %sccs.include.redist.c%

The SCCS implementation in the schilytools tar bundle includes support to
expand %sccs.filename%. Check the sccs-get(1) on how to set up the
SCCS_INCLUDEPATH environment to allow sccs to find the related include
path for "filename".

Post by Steffen Nurpmeso
|So I recommend to stay with the original. The SCCS history is on CD#4.
Hrm, of course buying the CD-set is for the morally superior among us!

In 1998, a friend who is in the FreeBSD project received a tape from the
creators of the CDs for free...

Post by Steffen Nurpmeso
|
|http://www.filewatcher.com/b/ftp/ftp.mrynet.com/operatingsystems/CSRG-0.html
The hare sits snug in leaves and grass
And laughs to see the green man pass.

The "original" is on archive.org, I just did not find the correct entry that
lists all four files. You may like to search at the web pages from Kirk
MCKusick, he officially states that the files are free to use now.

I currently have a slow internet connection, so I was not able to find the link.


Jörg

[Guido Berhoerster]

Post by Joerg Schilling
/*--------------------------------------------------------------------------*/
sccs prs -a CSRG_Archive_4/lib/libcompat/4.3/SCCS/s.insque.c
D 8.1 93/06/04 16:25:04 bostic 6 3 00002/00002/00028
4.4BSD snapshot (revision 8.1); add 1993 to copyright
R 5.5 91/03/19 19:18:44 bostic 5 4 00006/00002/00026
define the structures, no longer defined in unistd.h
R 5.4 91/02/23 19:49:51 donn 4 3 00008/00010/00020
Add include files to get prototype declarations, and fix bugs found.
D 5.3 90/06/01 14:11:58 bostic 3 2 00001/00011/00029
new copyright notice
D 5.2 88/07/21 11:31:59 bostic 2 1 00014/00003/00026
add Berkeley specific copyright; written by Robert Elz
D 5.1 87/01/27 16:07:57 mckusick 1 0 00029/00000/00000
add to portability library
/*--------------------------------------------------------------------------*/
There are removed deltas that do not appear in svn. There may be other meta
data that also vanished.
You may also be interested in files like bin/ls/ls.c
to understand that the extracted version from the svn did not expand the file
content for %sccs.include.redist.c%

Both appear to be problems with the SVN import, the direct
SCCS-to-git import at https://github.com/jonathangray/csrg is
just fine, see

https://github.com/jonathangray/csrg/commits/master/lib/libcompat/4.3/insque.c
https://github.com/jonathangray/csrg/blob/master/bin/ls/ls.c#L8

Post by Joerg Schilling
The SCCS implementation in the schilytools tar bundle includes support to
expand %sccs.filename%. Check the sccs-get(1) on how to set up the
SCCS_INCLUDEPATH environment to allow sccs to find the related include
path for "filename".

No need to bother with that.

[Steffen Nurpmeso]

Joerg Schilling <Joerg.Schilling-8LS2qeF34IpklNlQbfROjRvVK+***@public.gmane.org> wrote:
|There are removed deltas that do not appear in svn. There may be other meta
|data that also vanished.

I think such trivialisation fits absolutely perfect into our
modern time.

|You may also be interested in files like bin/ls/ls.c
|to understand that the extracted version from the svn did \
|not expand the file
|content for %sccs.include.redist.c%
|
|The SCCS implementation in the schilytools tar bundle includes support to
|expand %sccs.filename%. Check the sccs-get(1) on how to set up the
|SCCS_INCLUDEPATH environment to allow sccs to find the related include
|path for "filename".

I must admit i currently run another sccs(1) which is a bit over
half the size of Schily sccs(1), and only if i have to, and under
primary control of git(1) (sccs-inside-git). But i'm still hoping
for the overall changeset facility that you have given a talk
about (i read the paper) -- having such an improved sccs in the
toolchain would be nice. However, mostly for rather fixed text
documents, letters. I never want to go back to deal with small
loose patches lie around because of an unflexible vcs.

|>|So I recommend to stay with the original. The SCCS history is on CD#4.
|>
|> Hrm, of course buying the CD-set is for the morally superior among us!
|
|In 1998, a friend who is in the FreeBSD project received a tape from the
|creators of the CDs for free...

What a terrible situation!
..But only if it comes from the heart.
Luckily this is a situation i mostly know in reverse only!

|>|See e.g.:
|>|
|>|http://www.filewatcher.com/b/ftp/ftp.mrynet.com/operatin\
|>|gsystems/CSRG-0.html
|>
|> The hare sits snug in leaves and grass
|> And laughs to see the green man pass.
|
|The "original" is on archive.org, I just did not find the \
|correct entry that
|lists all four files. You may like to search at the web pages from Kirk
|MCKusick, he officially states that the files are free to use now.
|
|I currently have a slow internet connection, so I was not \
|able to find the link.

Yes but to me this is one more of the difficulties in between that
modern world and my emotional well-being. E.g. i buy books (in
a local store), smell it, feel it etc. This is a haptic and
physical experience. (Not talking about the bookseller, she
married in the meantime.)
And this is a BSD CD-set created by Marshall McKusick.

--steffen

[Joerg Schilling]

Post by Steffen Nurpmeso
I must admit i currently run another sccs(1) which is a bit over
half the size of Schily sccs(1), and only if i have to, and under

What SCCS implementation do you use?

I recently made some statistics and discovered that the current SCCS suite
includes aprox. 50% of code from me. Parts of this is caused by speeding up the
code (that is now aprox. 4x faster that Sun SCCS) and parts are related to new
features.

Post by Steffen Nurpmeso
primary control of git(1) (sccs-inside-git). But i'm still hoping
for the overall changeset facility that you have given a talk
about (i read the paper) -- having such an improved sccs in the
toolchain would be nice. However, mostly for rather fixed text
documents, letters. I never want to go back to deal with small
loose patches lie around because of an unflexible vcs.

The changeset facility has been designed after looking at BitKeeper and using
the best ideas. One important design goal was to be able to handle a project as
big and as active as the Linux kernel in a way that allows hardware from today
to be able to check in a new changeset in less than two seconds with the
expected constraints of the Linux repository in 50 years.

To check this, I did e.g. create a history file with 3 million deltas inside
for related benchmarks.

The nice idea with sccs is that this is adding new usability to an already
feature rich and very flexible system. While comparing features and usability,
I believe that from the OSS implementations only git, mercurial and sccs have a
future.

There may be a new step toards changeset support soon as after the pause during
the past 3 years it turned out that there is a lot of code to implement without
being 100% sure whether this will not have a bad impact on the future usability.

Post by Steffen Nurpmeso
And this is a BSD CD-set created by Marshall McKusick.

;-)

BTW: we received an image of the cover with the CD images.

Jörg

[Steffen Nurpmeso]

Hallo,

Joerg Schilling <Joerg.Schilling-8LS2qeF34IpklNlQbfROjRvVK+***@public.gmane.org> wrote:
|Steffen Nurpmeso <sdaoden-zJpx2rpV7r/QT0dZR+***@public.gmane.org> wrote:
|> I must admit i currently run another sccs(1) which is a bit over
|> half the size of Schily sccs(1), and only if i have to, and under
|
|What SCCS implementation do you use?
|
|I recently made some statistics and discovered that the current SCCS suite
|includes aprox. 50% of code from me. Parts of this is caused \
|by speeding up the
|code (that is now aprox. 4x faster that Sun SCCS) and parts \
|are related to new
|features.

At the moment it is (the Sun based)

?0[]$ sccs.sh what /Users/steffen/tmp/.sccs.sh/sccs
/Users/steffen/tmp/.sccs.sh/sccs:
sccs.sl 1.30 (gritter) 4/23/07

Of course it doesn't support recursive actions, i better use
explicit UTC etc. (etc..), but now that i have even converted my
letters, roff macros and misc scripts to git(1) even that does it.
That is, yours is of course better in practically all aspects.

A great effort, managing a complete Unix operating system with
that crude interface!

|The changeset facility has been designed after looking at \
|BitKeeper and using
|the best ideas. One important design goal was to be able to \
|handle a project as
|big and as active as the Linux kernel in a way that allows \
|hardware from today
|to be able to check in a new changeset in less than two seconds with the
|expected constraints of the Linux repository in 50 years.
|
|To check this, I did e.g. create a history file with 3 million \
|deltas inside
|for related benchmarks.
|
|The nice idea with sccs is that this is adding new usability to an already
|feature rich and very flexible system. While comparing features \
|and usability,
|I believe that from the OSS implementations only git, mercurial \
|and sccs have a
|future.

Yes, the paper was definitely quite impressive.
SCCS: i deliberately miss named branches, changesets and a safety
belt. Feature rich and flexible, hm naja, user experience is
quote painful :) and if the task gets more complicated i always
end up switching back and forth between POSIX pages.
Anyway: SCCS backend storage is pretty coherent, and almost
clear-text. Which is why i had it in use for letters etc.

|There may be a new step toards changeset support soon as after \
|the pause during
|the past 3 years it turned out that there is a lot of code \
|to implement without
|being 100% sure whether this will not have a bad impact on \
|the future usability.

I would be glad to see a furtherly improved SCCS.
Not impossible that such a free SCCS will see a renaissance.

|> And this is a BSD CD-set created by Marshall McKusick.
|
|;-)
|
|BTW: we received an image of the cover with the CD images.

Well not all software programmers etc. are dust-try and
uncreative. Of course, one of the devilish even put his cat the
words "Food-giver. Food-giver." in her mouth -- if that doesn't
miss the point completely, i really don't know! Laughable!

--steffen

[Garrett Wollman]

Post by Joerg Schilling

Post by Garrett Wollman

Post by Joerg Schilling
Most UNIX people have access to UNIX sources and even if you do not have a
relation to a university, it is possible to get the CSRG source suite that
includes a SCCS history for BSD UNIX between aprox. 1977 and 1994.

For those who wish to use more modern technology, see
<http://svnweb.freebsd.org/csrg/>.

It is disputable whether svn could be seen as "modern technology".

Most people would not dispute that it was more modern than a
35-year-old relic used by essentially nobody. Lots of people wonder
why on earth SCCS is still in the Standard anyway, but last time this
came up, we were assured that "many companies" were still using it
internally.[1]

Post by Joerg Schilling
In any way, this is a transformed copy and not the original history.

It is a *faithful* copy. The fact that it's not stored in your
favorite toy SCMS is not relevant to the discussion. The code clearly
establishes that the feature you are asking for was in 4.1BSD, back in
1980. It presumably was not in SVID back in 1990, because if it had
been, it would most likely have been included in POSIX.2.

-GAWollman

[1] I would question the ongoing usage of any code base which is still
locked in an antique VCS. For all practical purposes, if it's not in
a DVCS today, it's irrelevant.

[Geoff Clare]

Post by Garrett Wollman
It presumably was not in SVID back in 1990, because if it had
been, it would most likely have been included in POSIX.2.

I just checked the June 29, 1990 draft of SVID3 and tail -r is there.
It was not in SVID2 (which gives its copyright date as 1986).

This matches others' evidence that -r was added between SVR3 and
SVR4 (SVID3 was the interface definition for SVR4).

And POSIX.2-1992 listed SVID2 as a base document, not SVID3.

[Joerg Schilling]

Post by Geoff Clare

Post by Garrett Wollman
It presumably was not in SVID back in 1990, because if it had
been, it would most likely have been included in POSIX.2.

I just checked the June 29, 1990 draft of SVID3 and tail -r is there.
It was not in SVID2 (which gives its copyright date as 1986).
This matches others' evidence that -r was added between SVR3 and
SVR4 (SVID3 was the interface definition for SVR4).
And POSIX.2-1992 listed SVID2 as a base document, not SVID3.

This matches my previous statements: -r was added before 1990 to Solaris
and thus before the first published version of SunOS-5. It therefore can be
seen as an indice that it was in the planned interfaces for SVR4 already.

Unplanned things (other features and bugfixes from BSD/SunOS from the time
between 1980 and 1989) have been integrated to SunOS past 1993. This was e.g.
not using valloc() in dd(1) by AT&T that was the main reason for the name
"Slowlaris", that came up in 1993 and vanished a short time later due to then
unsynced (to AT&T source) fixes in SunOS-5.

Jörg