On 10/10/21 5:03 PM, Scott Cheloha wrote:
On Sun, Oct 10, 2021 at 02:36:32PM -0600, Theo de Raadt wrote:
Stuart Henderson <s...@spacehopper.org> wrote:
x1> On 2021/10/10 14:26, Scott Cheloha wrote:
On Sun, Oct 10, 2021 at 12:31:22PM -0600, Theo de Raadt wrote:
Bryan Steele <bry...@gmail.com> wrote:
On Sun, Oct 10, 2021 at 12:18:55PM -0500, Scott Cheloha wrote:
On Sun, Oct 10, 2021 at 10:51:29AM -0600, Theo de Raadt wrote:
did anyone ever use it this way, or are you getting ahead of yourself.
I don't understand the question.
I've only ever seen it used with -count as the first argument, can't
say it's every occoured to me to type "head file -10".
That is not what I proposed. Reread my first message:
https://marc.info/?l=openbsd-tech&m=163388435528203&w=2
i.e. "head -2 -3 somefile" is taken as -3.
This is unportable syntax, GNU head doesn't support it, current OpenBSD head
doesn't support it,
... obviously. That's why I posted the patch. :)
and it doesn't seem to be really meaningful.
Additionally I don't think we've ever had a problem with this in ports.
I think we would be better served to keep things as-is and not support it.
Seems that FreeBSD is the odd one out here?
If we're only going to support it as the first argument then we've
created a "gotcha", a special exception to the expected behavior. We
claim to support the legacy syntax but we don't actually fully support
it. The requirement that the legacy syntax be the first option
argument to head(1) in order to work as expected is undocumented.
So we could document this peculiarity...
... or we could just use my tiny patch and fully support it and
everything will work as documented today.
Indeed, the problem is our code supports this
but noone else supports it
NetBSD and FreeBSD support it. It was a standard part of the syntax
in SUSv2. I showed you in a private mail that it was supported in
1BSD through 4.3BSD, and then again in 4.4BSD some time in 1992.
Somewhere along the way between CSRG and NetBSD and our repository
the support was removed.
well, someone might accidentally use it in a script they write on OpenBSD
and... it is unportable, the behaviour is either different, or an error
condition
So who benefits? Noone, the way I see it.
If we want to have the unportable legacy syntax then it should work
like other option arguments. Option arguments can be respecified
multiple times in most other utilities. The last such appearance of
an option argument is the one the utility uses. That's how option
arguments work, for the most part.
We could remove the legacy syntax and shave a couple lines of code.
OTOH, supporting it fully is super easy. I've provided a patch.
The man page says head [-count | -n count] [file ...]
There are only two valid switches.
One, the other, or none.
Using more than one is -undefined-.
I doubt it ever has been defined.
It could be asserted that any more than 1 switch is an error.
If you have an old man page that says {[ -count | -n count ] ...}
then your argument has some merit.
geoff steckel
