openssh unix dev - May 2020 - [PATCH] Use POSIX standardized options for head(1) and tail(1)

Hi Damien,

Damien Miller <djm at mindrot.org> writes:
> Thanks, but I don't think we're going to merge this one because
I'm
> somewhat worried that some systems we currently build on do not support
> the -n syntax. Conversely, AFAIK everything* supports -number.
Michael Forney said that he was trying to run on a system that did NOT
support head -number and tail +number old-style format.

This is why I suggested use of 'sed' instead of 'head' and
'tail'. The
sed command predates both head and tail and the following idiom in sed
should be common going back to at least 1984 when I used sed in this way
on the following systems:

   Berkeley Software Distribution (4.4 BSD-Lite).
   Mt Xinu 4.3
   AIX 3 (1989) - AIX 4 (1994)
   HP/UX System V (1989)
   SunOS 3.0Beta1 (1986) thru Soliars 11
   FreeBSD 2.2.6 thru FreeBSD/11
   OpenBSD 2.7
   Cray X/MP

I recommend the change from

     (head -2 .depend; tail +3 .depend | sort) >.depend.tmp

to

     (sed 2q .depend; sed 1,2d .depend | sort) > .depend.tmp

should do the job correctly for all instances of sed I have ever used.

Failing this solution, coming up with a 'configure' script test might be
possible that provides for a compatibility test for using of -n options
for head and tail

	Be safe, stay healthy,
	-- Mark

On 2020-04-30, Mark D. Baushke <mdb at juniper.net>
wrote:
> Michael Forney said that he was trying to run on a system that did NOT
> support head -number and tail +number old-style format.
The tail implementation I'm using is from sbase. It does support the
old-style -number, but not +number.
> I recommend the change from
>
>      (head -2 .depend; tail +3 .depend | sort) >.depend.tmp
>
> to
>
>      (sed 2q .depend; sed 1,2d .depend | sort) > .depend.tmp
>
> should do the job correctly for all instances of sed I have ever used.
This works for me.
> Failing this solution, coming up with a 'configure' script test
might be
> possible that provides for a compatibility test for using of -n options
> for head and tail
I don't think this would be necessary. The 'depend' rule is usually
only used by the openssh developers to regenerate .depend, so it
really only needs to work on the systems they are using. I only ran it
because I was experimenting with some local changes and wanted to
update .depend. There were no problems with a normal build. I know my
system is rather unusual, so it doesn't make sense to alter these
maintenance commands for it if it would break on other systems.

Anyway, I apologize for the commotion. I support Mark's suggested
change if that is acceptable, but if not, it's really not a big deal.

-Michael

Michael Forney <mforney at mforney.org> writes:
> The tail implementation I'm using is from sbase. It does support the
> old-style -number, but not +number.
Hmmm.... sbase as in https://git.suckless.org/sbase/ ?

	Be safe, stay healthy,
	-- Mark

On Fri, 1 May 2020 at 18:19, Michael Forney <mforney at mforney.org>
wrote:
> On 2020-04-30, Mark D. Baushke <mdb at juniper.net> wrote:
> > Michael Forney said that he was trying to run on a system that did NOT
> > support head -number and tail +number old-style format.
>
> The tail implementation I'm using is from sbase. It does support the
> old-style -number, but not +number.
[...]
> I don't think this would be necessary. The 'depend' rule is
usually
> only used by the openssh developers to regenerate .depend, so it
> really only needs to work on the systems they are using. I only ran it
> because I was experimenting with some local changes and wanted to
> update .depend.
I admit that I didn't put any thought into the portability of those
lines because I didn't expect anyone else to ever use them.  Anyway it
turns out "#" sorts asciibetically[1] before any of our source files,
so I've just removed the invocations of tail.

[1] anyone running "make depend" after adding a file named
"!anything"
or on an EBCDIC platform is on their own.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.