Benchy - Benchmark with color !

Liso

Following suggestions taken from my previous thread, I have employ colored output as default option. It should detect whether the terminal supported 256 colors and proceed to use it if so— otherwise there will be no color at all.

If it's not too much to ask, can you test it out and give me feedback on it ?

wget -qO- benchy.pw | bash

or

curl -Ls benchy.pw | bash

Also check the Usage section to explore several variations to launch the script.

TheMister

I've just tried it and it seems to be working just fine, all colors were there

DP

Overall, it looks good, but personally, I would minimize the number of colors used.

msatt

I tend to run yabs with | tee yabs.bench
This lets me view and store the output.
Of course this also works for benchy but the output is not in colour.

Liso

@msatt said:
I tend to run yabs with | tee yabs.bench
This lets me view and store the output.
Of course this also works for benchy but the output is not in colour.

You can store the output by appending -o or --output. Like so:

wget -qO- benchy.pw | bash -s -- -o

It will save the output to file named benchy.log.

msatt

@Liso said: You can store the output by appending -o or --output. Like so:

wget -qO- benchy.pw | bash -s -- -o

It will save the output to file named benchy.log.

Thanks - I should have RTFM
Doing the above, benchy.log is not in colour however I appreciate --color=yes could be added. I would suggest if default display is in colour then file should also default to color?

saywhat13

looking cool!!

I've been using bench.im & bench.sh. Now another option.

Liso

@msatt said:

@Liso said: You can store the output by appending -o or --output. Like so:

wget -qO- benchy.pw | bash -s -- -o

It will save the output to file named benchy.log.

Thanks - I should have RTFM
Doing the above, benchy.log is not in colour however I appreciate --color=yes could be added. I would suggest if default display is in colour then file should also default to color?

Initially its behavior was like you mentioned, but the file would be filled with ansi codes and control sequence. I have embedded image to show you what I meant → https://imgur.com/a/3UHAOMw

This is why I filter the output first before outputting to log and later to sprunge.us— to remove any trace of gibberish escape codes.

If you're fine with this, I can create --color=force to have your desired result.

msatt

I understand your logic, on sprunge.us it certainly makes sense to have the 'plain' output.

When I use a local file it is purely for viewing so I would just cat benchy.log. I do however appreciate that the log file could be processed by something else and having all the escape sequences would just be a nightmare to strip out.

So my preference would be if output is displayed in colour then local file should match the display and sprunge.us should remain plain. If I need to process benchy.log then I should use --color=no

I accept it is all down to how people use the software so my requirements may be either in the minority or majority.

VPSSLIM

Looks good! Great work.

ailice

Is pipe to bash is require? and looks tput is broke on OpenBSD and script complain about /proc/cpuinfo not found.
I will do PR today, script looks nice I like it so far.

Liso

@ailice said:
Is pipe to bash is require? and looks tput is broke on OpenBSD and script complain about /proc/cpuinfo not found.
I will do PR today, script looks nice I like it so far.

No it is working on sh too, you may try that. Somebody has opened PR for OpenBSD support.

Don't know about *bsd's tput, but a quick glance on its man page show it doesn't support color-- only solution I see is to exclude color if the host machine is *BSD.

User1

Looks sweet! Great work man

Liso

@msatt said:
I understand your logic, on sprunge.us it certainly makes sense to have the 'plain' output.

When I use a local file it is purely for viewing so I would just cat benchy.log. I do however appreciate that the log file could be processed by something else and having all the escape sequences would just be a nightmare to strip out.

So my preference would be if output is displayed in colour then local file should match the display and sprunge.us should remain plain. If I need to process benchy.log then I should use --color=no

I accept it is all down to how people use the software so my requirements may be either in the minority or majority.

I just pushed this feature to upstream, you may pass --color=force or -c force argument to display outputted file in color, this doesn't affect the output sent to sprunge.us which should be colorless.

BikeHelmet

I like the colours. I would expect the output file to default to plain text, no weird control codes. No problem with there being an override, if someone might need/desire it.

Liso

@BikeHelmet said:
I like the colours. I would expect the output file to default to plain text, no weird control codes. No problem with there being an override, if someone might need/desire it.

Yep, output file only have color if you add --color=force, otherwise it will stay colorless.

ElonBezos

i love it has the option to use speedtest.net instead of iperf,
good job

jugganuts

woot benchy! love it!

ailice

@Liso said:

No it is working on sh too, you may try that. Somebody has opened PR for OpenBSD support.

Don't know about *bsd's tput, but a quick glance on its man page show it doesn't support color-- only solution I see is to exclude color if the host machine is *BSD.

I got this error when using sh

kle$ curl -Ls benchy.pw | sh
sh: <stdin>[975]: syntax error: `;;' unexpected

Liso

@ailice said:

@Liso said:

No it is working on sh too, you may try that. Somebody has opened PR for OpenBSD support.

Don't know about *bsd's tput, but a quick glance on its man page show it doesn't support color-- only solution I see is to exclude color if the host machine is *BSD.

I got this error when using sh

kle$ curl -Ls benchy.pw | sh
sh: <stdin>[975]: syntax error: `;;' unexpected

What if you download it first then manually execute it, do you encounter same problem ?

curl -Ls benchy.pw -o benchy && chmod u+x benchy.sh && sh ./benchy.sh

If the problem persist, probably very specific to *BSD line, unfortunately as I never work with *bsd machine before, I can't be of more help. Meanwhile I'll search a way to run *bsd on my vps so I can troubleshoot this problem.

@jugganuts said:
woot benchy! love it!

Thanks ! This would not have been possible without your support

lewellyn

@Liso said:
If the problem persist, probably very specific to *BSD line, unfortunately as I never work with *bsd machine before, I can't be of more help. Meanwhile I'll search a way to run *bsd on my vps so I can troubleshoot this problem.

Before you go that far, it's probably worthwhile to fix the 30 issues noted by shellcheck. Fixing those will likely expose others. But once it's no longer finding fault in your script, there's a much higher chance it will "just work".

Also, test it with ash, heirloom sh, mksh, and ksh93. ash is kinda the bare minimum shell. heirloom sh is a very traditional sh. mksh is the shell shipped by Android. ksh93 is basically the shell POSIX sh was documented against (and that bash tries/tried to mimic).

Also, I looked at line 975 and I can kind of see why a shell would be distressed by that syntax. Try moving that case into a function. I'm not entirely sure that your order of operations is guaranteed by POSIX to work as you expect them to.

Liso

@lewellyn said:

@Liso said:
If the problem persist, probably very specific to *BSD line, unfortunately as I never work with *bsd machine before, I can't be of more help. Meanwhile I'll search a way to run *bsd on my vps so I can troubleshoot this problem.

Before you go that far, it's probably worthwhile to fix the 30 issues noted by shellcheck. Fixing those will likely expose others. But once it's no longer finding fault in your script, there's a much higher chance it will "just work".

Also, test it with ash, heirloom sh, mksh, and ksh93. ash is kinda the bare minimum shell. heirloom sh is a very traditional sh. mksh is the shell shipped by Android. ksh93 is basically the shell POSIX sh was documented against (and that bash tries/tried to mimic).

Also, I looked at line 975 and I can kind of see why a shell would be distressed by that syntax. Try moving that case into a function. I'm not entirely sure that your order of operations is guaranteed by POSIX to work as you expect them to.

It is working on my end with ash, dash, mksh, ksh— except heirloom sh because I'm unable to locate their installable binary.

Have followed several shellcheck recommendation, though I left some of them (e.g. SC2046 completely broke the argument parsing). Good call on that.

lewellyn

@Liso said:

@lewellyn said:

@Liso said:
If the problem persist, probably very specific to *BSD line, unfortunately as I never work with *bsd machine before, I can't be of more help. Meanwhile I'll search a way to run *bsd on my vps so I can troubleshoot this problem.

Before you go that far, it's probably worthwhile to fix the 30 issues noted by shellcheck. Fixing those will likely expose others. But once it's no longer finding fault in your script, there's a much higher chance it will "just work".

Also, test it with ash, heirloom sh, mksh, and ksh93. ash is kinda the bare minimum shell. heirloom sh is a very traditional sh. mksh is the shell shipped by Android. ksh93 is basically the shell POSIX sh was documented against (and that bash tries/tried to mimic).

Also, I looked at line 975 and I can kind of see why a shell would be distressed by that syntax. Try moving that case into a function. I'm not entirely sure that your order of operations is guaranteed by POSIX to work as you expect them to.

It is working on my end with ash, dash, mksh, ksh— except heirloom sh because I'm unable to locate their installable binary.

Have followed several shellcheck recommendation, though I left some of them (e.g. SC2046 completely broke the argument parsing). Good call on that.

You'll likely need to build heirloom sh from the sources on sourceforge. It's very much a legacy-compatibility shell, but my experience is that getting a script to run happily in both heirloom sh and ksh93 is the lowest-effort way to hit all not-buggy shells once making shellcheck happy.

Also, make sure your distro has ksh93 as ksh and not the ancient pdksh that mksh was forked from: echo ${sh.version}

Liso

@lewellyn said: You'll likely need to build heirloom sh from the sources on sourceforge. It's very much a legacy-compatibility shell, but my experience is that getting a script to run happily in both heirloom sh and ksh93 is the lowest-effort way to hit all not-buggy shells once making shellcheck happy.

I downloaded heirloom-sh-050706.tar.bz2 from this link, extract it and found bunch of *.c file and one makefile, I do make and it produce a executable named sh and symlink to it under the name jsh. I tried sudo make install but it's not working with following error.

test -d /usr/5bin || mkdir -p /usr/5bin
/usr/ucb/install -c -m 755 sh /usr/5bin/sh
make: /usr/ucb/install: Command not found
makefile:95: recipe for target 'install' failed
make: *** [install] Error 127

Then I just type ./sh, it bring me to new shell session (is this heirloom ?), I execute benchy on it— finished without any issue. So does this mean it passes the compatibility check ?

hostnamaste

@Liso said:
Following suggestions taken from my previous thread, I have employ colored output as default option. It should detect whether the terminal supported 256 colors and proceed to use it if so— otherwise there will be no color at all.

If it's not too much to ask, can you test it out and give me feedback on it ?

wget -qO- benchy.pw | bash

or

curl -Ls benchy.pw | bash

Also check the Usage section to explore several variations to launch the script.

Wow looking great, loving it!

lewellyn

@Liso said:

@lewellyn said: You'll likely need to build heirloom sh from the sources on sourceforge. It's very much a legacy-compatibility shell, but my experience is that getting a script to run happily in both heirloom sh and ksh93 is the lowest-effort way to hit all not-buggy shells once making shellcheck happy.

I downloaded heirloom-sh-050706.tar.bz2 from this link, extract it and found bunch of *.c file and one makefile, I do make and it produce a executable named sh and symlink to it under the name jsh. I tried sudo make install but it's not working with following error.

test -d /usr/5bin || mkdir -p /usr/5bin
/usr/ucb/install -c -m 755 sh /usr/5bin/sh
make: /usr/ucb/install: Command not found
makefile:95: recipe for target 'install' failed
make: *** [install] Error 127

Then I just type ./sh, it bring me to new shell session (is this heirloom ?), I execute benchy on it— finished without any issue. So does this mean it passes the compatibility check ?

You probably don't want to make install it as the heirloom tools make certain assumptions about your system which almost certainly aren't true if you're not trying to run a lot of old tools, and if you're on Linux.

But did you change the shebang of benchy or run ./sh benchy? If you just run benchy as-is, you will not be testing the newly-compiled shell.

If it's working for you in even heirloom sh, @ailice will probably need to provide more information to ensure that it's made to work for them. Like which OpenBSD version and which architecture.

I'd call the observed behavior an OpenBSD bug, honestly, from what I'm seeing. Granted, it'd only be a bug in practice rather than in theory, as I came up with a few "valid" ways to parse the line in question aside from the accepted way.

cybersurfer

@Liso Not working on AlmaLinux release 8.7 (Stone Smilodon). No error either. Same with yabs.sh . bench.sh is working fine though.

Liso

@lewellyn said:

@Liso said:

@lewellyn said: You'll likely need to build heirloom sh from the sources on sourceforge. It's very much a legacy-compatibility shell, but my experience is that getting a script to run happily in both heirloom sh and ksh93 is the lowest-effort way to hit all not-buggy shells once making shellcheck happy.

I downloaded heirloom-sh-050706.tar.bz2 from this link, extract it and found bunch of *.c file and one makefile, I do make and it produce a executable named sh and symlink to it under the name jsh. I tried sudo make install but it's not working with following error.

test -d /usr/5bin || mkdir -p /usr/5bin
/usr/ucb/install -c -m 755 sh /usr/5bin/sh
make: /usr/ucb/install: Command not found
makefile:95: recipe for target 'install' failed
make: *** [install] Error 127

Then I just type ./sh, it bring me to new shell session (is this heirloom ?), I execute benchy on it— finished without any issue. So does this mean it passes the compatibility check ?

You probably don't want to make install it as the heirloom tools make certain assumptions about your system which almost certainly aren't true if you're not trying to run a lot of old tools, and if you're on Linux.

But did you change the shebang of benchy or run ./sh benchy? If you just run benchy as-is, you will not be testing the newly-compiled shell.

If it's working for you in even heirloom sh, @ailice will probably need to provide more information to ensure that it's made to work for them. Like which OpenBSD version and which architecture.

I'd call the observed behavior an OpenBSD bug, honestly, from what I'm seeing. Granted, it'd only be a bug in practice rather than in theory, as I came up with a few "valid" ways to parse the line in question aside from the accepted way.

Well I spoke too soon, I tried changing the shebang to sh file on heirloom dir, it immediately spouting this error: benchy: syntax error at line 24:cred=$' unexpected`.

Looks like heirloom doesn't support $() syntax. I'll see if there's anything more.

Liso

@cybersurfer said:
@Liso Not working on AlmaLinux release 8.7 (Stone Smilodon). No error either. Same with yabs.sh . bench.sh is working fine though.

What do you mean no error ? Is there no output at all ?

cybersurfer

@Liso said:

@cybersurfer said:
@Liso Not working on AlmaLinux release 8.7 (Stone Smilodon). No error either. Same with yabs.sh . bench.sh is working fine though.

What do you mean no error ? Is there no output at all ?

Yes, that's right. No output at all.

ailice

@lewellyn said:

@ailice will probably need to provide more information to ensure that it's made to work for them. Like which OpenBSD version and which architecture.

Its OpenBSD 7.2 amd64, AFAIK sh was symlink with ksh on OpenBSD. I also have ksh on Alpine but script running fine.
This probably some OpenBSD stuff