[dev] less lines of code suck less

[Greg Reagle]

Would sbase suck less if the program head, which is currently a C program of 77 lines, were replaced with something like
#!/bin/sh
sed "$1"q

I know that it would need to be a bit more elaborate than that to handle the -n flag, but still. Is there any advantage to having a separate C program?

[Greg Reagle]

I'm sorry I forgot to include this in my initial message. I found no difference in performance time or memory usage (with a small file), so that does not seem to be an advantage.

And I am serious about this--I really want to know. Is there any good reason to have a separate C program?

Post by Greg Reagle
Would sbase suck less if the program head, which is currently a C
program of 77 lines, were replaced with something like
#!/bin/sh
sed "$1"q
I know that it would need to be a bit more elaborate than that to
handle the -n flag, but still. Is there any advantage to having a
separate C program?

[Jeremy]

Post by Greg Reagle
Would sbase suck less if the program head, which is currently a C program of 77 lines, were replaced with something like
#!/bin/sh
sed "$1"q

Great job.

Post by Greg Reagle
I know that it would need to be a bit more elaborate than that to handle the -n flag, but still. Is there any advantage to having a separate C program?

The spec gets a bit tricky when handling multiple files - see:
seq 3 | awk '{ print $1 > $1 }'
head -n1 $(seq 3)

This is simple enough to do in awk, with very few lines of code.

I'd argue that requiring awk to use `head` would create more
complexity(for the end user) than it would solve for the developer.

Jeremy

[Greg Reagle]

Post by Jeremy
I'd argue that requiring awk to use `head` would create more
complexity(for the end user) than it would solve for the developer.

I assume that you mean requiring head to use awk. I cannot imagine how it would have any effect at all on the end user. And if it has less lines, in a higher level language, sounds like a win.

[Страхиња Радић]

Post by Greg Reagle
And if it has less lines, in a higher level language, sounds like a win.

Higher level languages usually mean more complexity and less control. Having
less lines in a higher level language doesn't mean much if the language adds
unnecessary overhead "behind the scenes". Ideally, the least bloat and the most
control is achieved by directly programming machine code. That's what
performance-critical code is written in. It isn't considered as "practical" for
most things, though.

[Greg Reagle]

Post by Greg Reagle
Would sbase suck less if the program head, which is currently a C
program of 77 lines, were replaced with something like
#!/bin/sh
sed "$1"q

Here it is in 37 lines of glorious rc shell code. Note that head.c also depends on several functions in libutil, so it is more than 77 lines really.

#!/usr/bin/env rc

fn usage {printf '%s [-n num] [file ...]\n' $0; exit $1}
fn numeric {printf '%s' $1 | grep -Eq '^[0-9]+$'}
fn positive {expr $1 '>' 0 > /dev/null}
lines=10
while (! ~ $#* 0 && ~ $1 -* && ! ~ $1 --) {
switch($1) {
case -n
if (~ $2 ?*) {
if (numeric $2 && positive $2) {
lines=$2
shift
}; if not { # else
usage 1
}
}; if not {
usage 2
}
case -*; usage 3
}
shift
}
if (~ $1 --) {shift}
switch($#*) {
case 0
echo sed $lines^q
case 1
echo sed $lines^q $1
case *
while (! ~ $#* 0) {
printf '==> %s <==\n' $1
echo sed $lines^q $1
shift
}
}
true # otherwise script will exit with error

[Quentin Rameau]

On Mon, 03 May 2021 19:40:04 -0400

Post by Greg Reagle

Post by Greg Reagle
Would sbase suck less if the program head, which is currently a C
program of 77 lines, were replaced with something like
#!/bin/sh
sed "$1"q

Not really because although head is pretty simple, it's a bit more
complex than that, you need to handle command parameters, have a
default line numbers, and print filenames if several of them are passed
(IIRC that's all).

Post by Greg Reagle
Here it is in 37 lines of glorious rc shell code. Note that head.c also depends on several functions in libutil, so it is more than 77 lines really.
#!/usr/bin/env rc

And how many “lines” for env and rc dependencies?

[Hiltjo Posthuma]

Post by Greg Reagle
Would sbase suck less if the program head, which is currently a C program of 77 lines, were replaced with something like
#!/bin/sh
sed "$1"q

No

Post by Greg Reagle
I know that it would need to be a bit more elaborate than that to handle the -n flag, but still. Is there any advantage to having a separate C program?

Yes

[Cág]

Post by Greg Reagle
Would sbase suck less if the program head, which is currently a C
program of 77 lines, were replaced with something like
#!/bin/sh
sed "$1"q

Plan 9 doesn't have head(1), neither do I in my sbase, not even a wrapper.
`sed 10q` emulates the default behavior of head, which is enough for most
cases.

[Mateusz Okulus]

Post by Greg Reagle
Would sbase suck less if the program head, which is currently a C program of 77 lines, were replaced with something like
#!/bin/sh
sed "$1"q
I know that it would need to be a bit more elaborate than that to handle the -n flag, but still. Is there any advantage to having a separate C program?

It's for performance or/and convenience reasons. It could be a shell
script.

head is a utility as defined by POSIX

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_22

A utility can be a shell script and there shouldn't be a difference in
behavior.

I think it's easier to write and maintain a POSIX compliant head when
it's written in C, because it has to handle -n option and multiple files
with a special output header.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/head.html

Post by Greg Reagle
Although it is possible to simulate head with sed 10q for a single
file, the standard developers decided that the popularity of head on
historical BSD systems warranted its inclusion alongside tail.
Many early versions of Unix did not have this command, and

You could write POSIX compliant head in POSIX compliant shell and it
would be correct.

Of course if you don't need to be POSIX compliant you could drop head
altogether.

I would say most people write these tools in C for performance reasons.
For example look at GNU cat code.

Regards,
mat