On Thu, 19 Feb 2026 07:16:49 +0000 Thomas Kupper <[email protected]> wrote:
> > > On 19.02.2026 00:26, izzy Meyer wrote: > > On Wed, 18 Feb 2026 16:53:39 -0600 > > izzy Meyer <[email protected]> wrote: > > > >> Hello ports@ > >> > >> I've been feeling really motivated lately with exfetch and added > >> some new features to it (see changelog below). I want to get this > >> out into the wild as soon as possible, so people can play around > >> and test it on their machines. > >> > >> Here's a simple update to sysutils/exfetch to a tag with these new > >> features. > >> > >> Tested on amd64, works good. > >> > >> I'd like someone to test these new changes before they commit if > >> that's ok. > > - Offset works for me: > > grumpy$ exfetch -f 7 -a OpenBSD > > USER -> [email protected] > OS -> OpenBSD > VER -> 7.8 > UPTIME -> 37 days, 11:17 > DE/WM -> unknown > TERM -> screen > SHELL -> ksh > _____ CPU -> Intel Xeon CPU E5-2630 0 @ 2.30GHz > \- -/ GPU -> unknown > \_/ .` , \ PKGS -> 175 > | , , 0 0 | LOAD -> 1m: 0.33, 5m: 0.26, 15m: 0.43 > |_ < } 3 | SWAP -> 11.43 / 1264.00 MiB > / \` . ` / MEM -> 52.32 / 1007.99 MiB > /-_____-\ Good good. Thanks for testing. > > I understand providing a negative value will raise an ArgumentError > as you mentioned in the man page. > > Is there a more elegant way than to show the whole call stack? Handle > it similar like the color (-c|--color) argument? > > grumpy$ exfetch -f -7 -a OpenBSD > Unhandled exception: ASCII offset cannot be negative. ILLEGAL > (ArgumentError) > from exfetch in '__register_frame_info' > from exfetch in '__register_frame_info' > from exfetch in 'main' > from exfetch in 'main' > from exfetch in '__start' That's one of the annoying things I don't like about crystal. raising an exception produces a near-non-debuggable callstack pushed to stdout due to crystal's runtime bogging it down. The way the ArgumentError is handled right now, in the cli.cr module: if offset < 0 raise ArgumentError.new("ASCII offset cannot be negative. ILLEGAL") end When you raise an ArgumentError, or any other exception for that mattter, it dumps the last few frames of the callstack before the exception to stdout, which I find unfavorable for non-technical end-users. It was a quick hack that I did, and it'll stay in for 1.5.2.1. I plan on axing that behavior by 1.5.3 along with some other code cleanups in these new features. Future versions will use a more typical error code return like how -c/--color with out a value handles it in option_handler.cr: p.invalid_option do |flag| STDERR.puts "Invalid option: #{flag}" STDERR.puts "See exfetch(1) or --help for usage." exit 1 end p.missing_option do |flag| STDERR.puts "Missing argument for #{flag}" STDERR.puts "See exfetch(1) or --help for usage." exit 1 end Thanks for the nit, I overlooked that myself when hacking on the codebase. > - Text-Only works as expected: > > grumpy$ exfetch -c 1 -f 1 -a OpenBSD | tee output.with.escape > grumpy$ exfetch -c 1 -T -f 1 -a OpenBSD | tee output.without.escape > > grumpy $ grep -c '\[' output.with.escape > 13 > grumpy $ grep -c '\[' output.without.escape > 0 Good good. --- Could a committer look at this now and consider commiting it? I feel satisfied with the results of people's testing. -- iz (she/her) > i like to say mundane things, > there are too many uninteresting things > that go unnoticed. izder456 (dot) neocities (dot) org
