How to get table output in `dnf search`?

I’ve just installed https://download.fedoraproject.org/pub/fedora/linux/releases/test/40_Beta/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-40_Beta-1.10.iso after using openSUSE Tumbleweed for some years (due to Unable to install OSTW ISO via USB storage device - Install/Boot/Login - openSUSE Forums) and I intend to stay, considering what a pleasant experience installation was, and how new the package selection is.

However, I am surprised at how unreadable dnf’s output appears to be by default:

dnf search nextcloud
Last metadata expiration check: 0:03:44 ago on Tue 26 Mar 2024 19:20:59 GMT.
============================================================================================================================================= Name Exactly Matched: nextcloud ==============================================================================================================================================
nextcloud.noarch : Private file sync and share server
============================================================================================================================================ Name & Summary Matched: nextcloud =============================================================================================================================================
nextcloud-client.x86_64 : The Nextcloud Client
nextcloud-client-debuginfo.x86_64 : Debug information for package nextcloud-client
nextcloud-client-debugsource.x86_64 : Debug sources for package nextcloud-client
nextcloud-client-devel.x86_64 : Development files for nextcloud-client
nextcloud-client-devel-debuginfo.x86_64 : Debug information for package nextcloud-client-devel
nextcloud-client-dolphin-debuginfo.x86_64 : Debug information for package nextcloud-client-dolphin
nextcloud-client-libs.x86_64 : Common files for nextcloud-client
nextcloud-client-libs-debuginfo.x86_64 : Debug information for package nextcloud-client-libs
nextcloud-client-nautilus.x86_64 : nextcloud client nautilus extension
nextcloud-httpd.noarch : Httpd integration for NextCloud
nextcloud-mysql.noarch : MySQL database support for NextCloud
nextcloud-nginx.noarch : Nginx integration for NextCloud
nextcloud-postgresql.noarch : PostgreSQL database support for NextCloud
nextcloud-sqlite.noarch : SQLite 3 database support for NextCloud
================================================================================================================================================= Name Matched: nextcloud ==================================================================================================================================================
nextcloud-client-caja.x86_64 : Caja overlay icons
nextcloud-client-dolphin.x86_64 : Dolphin overlay icons
nextcloud-client-nemo.x86_64 : Nemo overlay icons
================================================================================================================================================ Summary Matched: nextcloud ================================================================================================================================================
merkuro.x86_64 : A calendar application using Akonadi to sync with external services (Nextcloud, GMail, ...)
qownnotes.x86_64 : Plain-text file markdown note taking with Nextcloud integration

The : delimination seems markedly inferior to https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/zypper-1.14.70-1.1.x86_64.rpm 's table output:

zypper search zypper
Loading repository data...
Reading installed packages...

S  | Name                         | Summary                                     | Type
---+------------------------------+---------------------------------------------+--------
   | microos_base_zypper          | openSUSE MicroOS using Zypper               | pattern
   | monitoring-plugins-zypper    | Check for software updates via zypper       | package
   | patterns-microos-base-zypper | openSUSE MicroOS using Zypper               | package
i+ | zypper                       | Command line software manager using libzypp | package
   | zypper-aptitude              | aptitude compatibility with zypper          | package
   | zypper-changelog-plugin      | Changelog listing tool                      | package
   | zypper-keys-plugin           | Zypper plugin to manage RPM keys            | package
   | zypper-lifecycle-plugin      | Zypper subcommand for lifecycle information | package
i+ | zypper-log                   | CLI for accessing the zypper logfile        | package
i+ | zypper-needs-restarting      | needs-restarting compatibility with zypper  | package

Is there a way to make it possible to read the attributes of multiple search results simultaneously without needing to constantly move my eyes horizontally, or is there at least an issue tracking this?

Added fedora-kde

One workaround is to use the column command to generate table-like output by specifying “:” as the separator.

dnf search nextcloud | column -t -s ':'
2 Likes

In IT you always have to take history into account and make compromises.
Terminals and consoles had/have a limit of characters per line (~80). If you try to add table formatting, you will make everyone else who is restricted by character length in the console unhappy.

Fortunately, we have so many options in the terminal to write our own tools. In addition to @yuntaz’s workaround, I suggest you create a helper script that looks like this:

I named my script searchdnf and saved it in ~/bin

#!/bin/bash

if [ "$1" = "" ]; then
   echo " Please add a search string like 'searchdnf nextcloud' "
else
    	dnf search $1 | column -t -s ':'
fi

Speaking of readability, have you ever imagined what your nickname would be for those who are visually impaired and rely on screen readers?

You can here it (while pressing on the speaker icon):

You might consider a compromise too about your nickname :upside_down_face:

1 Like

@yuntaz, many thanks. I’ll use that as the basis for a PowerShell module to encapsulate dnf, probably. However, it does break the heading demarcators.


@ilikelinux, I speak to an awful lot of foreigners. However, even native English speakers seem to constantly become confused by my name - its order, pronunciation, etcetera. This at least remediates one of these issues. Additionally, because it’s Pandoc Markdown-delimited as <code>, I’ve been able to get it to render correctly in a lot of places, just not Discourse yet.

I agree that a dnf search output is difficult to read, but the zypper output - what’s with all those sticks laying around - is terrible. For a long time, I’ve been wanting to remedy the output since I am constantly doing searches. The following solutions are base: provides the functionality but needs work (that includes your personal design).

From the command-line

regex="PARAMETER"; dnf search $regex | sed "s/^\([^=]*\)\($regex\)\(.*\):\(.*\)/`printf '%b%s%b%s%b%s%b%s%b' "\e[38;2;144;238;144m" "\1" "\e[36m" "\2" "\e[38;2;144;238;144m" "\3" "\e[50G\e[93m" "\4" "\e[m"`/I" # NOTE: Search parameter entered into variable regex

For a sed-file (name it dnf_Search.sed)

# This is a sed script-file; not an input-file.
s/^\([^=]*\)\($regex\)\(.*\):\(.*\)/^[[38;2;144;238;144m\1^[[36m\2^[[38;2;144;238;144m\3^[[50G^[[93m\4^[[m/I

NOTE: the ESCAPE (^[) characters need to be hard-coded.
Execute with

regex="PARAMETER"; dnf search "$regex" | sed -f <(envsubst '$regex' </PATH/dnf_Search.sed) # NOTE: Search parameter is regex variable

Now output is a colored table. The search is case-insensitive. I’ve so far tried with PARAMETERS “w3m” and “emacs”. NOTE the end of the “emacs” output. As I said, it is base.

2 Likes

@ptrck4193,

I think that that output is wonderful! The colouration especially. Many, many thanks. Please mention this at the linked issue.

What do you refer to? I’m not utterly familiar with the “stick” UTF-8 character, and I don’t see anything particularly unreadable in the output I provided relating to anything stick-like, like the hyphen dashes or pipes (if they’re what you’re referring to). Looks rather like Markdown to me.

Sticks refer to characters such as _, -, /, |, \, or any similar characters. Its a personal preference that all output should be clear of unnecessary clutter. That is why I eliminated the colon in the REGEX; it is clutter in the DNF output (that is one space occupied without reason).

1 Like

@ptrck4193,

Basically, you’d prefer something like

<!DOCTYPE HTML>
<meta charset="UTF-8">

<style>
	thead { border-style : hidden; }
</style>

<table>
	<thead>
		<tr>
			<th>S</th>
			<th>Name</th>
			<th>Summary</th>
			<th>Type</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td></td>
			<td>microos_base_zypper</td>
			<td>openSUSE MicroOS using Zypper</td>
			<td>pattern</td>
		</tr>
		<tr>
			<td></td>
			<td>monitoring-plugins-zypper</td>
			<td>Check for software updates via zypper</td>
			<td>package</td>
		</tr>
		<tr>
			<td></td>
			<td>patterns-microos-base-zypper</td>
			<td>openSUSE MicroOS using Zypper</td>
			<td>package</td>
		</tr>
		<tr>
			<td>i+</td>
			<td>zypper</td>
			<td>Command line software manager using libzypp</td>
			<td>package</td>
		</tr>
		<tr>
			<td></td>
			<td>zypper-aptitude</td>
			<td>aptitude compatibility with zypper</td>
			<td>package</td>
		</tr>
		<tr>
			<td></td>
			<td>zypper-changelog-plugin</td>
			<td>Changelog listing tool</td>
			<td>package</td>
		</tr>
		<tr>
			<td></td>
			<td>zypper-keys-plugin</td>
			<td>Zypper plugin to manage RPM keys</td>
			<td>package</td>
		</tr>
		<tr>
			<td></td>
			<td>zypper-lifecycle-plugin</td>
			<td>Zypper subcommand for lifecycle information</td>
			<td>package</td>
		</tr>
		<tr>
			<td>i+</td>
			<td>zypper-log</td>
			<td>CLI for accessing the zypper logfile</td>
			<td>package</td>
		</tr>
		<tr>
			<td>i+</td>
			<td>zypper-needs-restarting</td>
			<td>needs-restarting compatibility with zypper</td>
			<td>package</td>
		</tr>
	</tbody>
</table>

to

<!DOCTYPE HTML>
<meta charset="UTF-8">

<style>
	:is(th) {
		border-bottom: 1px solid #484848; /* https://stackoverflow.com/a/16073356/9731176 */
		font-weight: bold;
		font-size: inherit;
		margin-top: 1em;
	}
	:is(th, td) {
		border: 1px solid #484848!important;
		border-collapse: collapse;
	}
</style>

<table>
	<thead>
		<tr>
			<th>S</th>
			<th>Name</th>
			<th>Summary</th>
			<th>Type</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td></td>
			<td>microos_base_zypper</td>
			<td>openSUSE MicroOS using Zypper</td>
			<td>pattern</td>
		</tr>
		<tr>
			<td></td>
			<td>monitoring-plugins-zypper</td>
			<td>Check for software updates via zypper</td>
			<td>package</td>
		</tr>
		<tr>
			<td></td>
			<td>patterns-microos-base-zypper</td>
			<td>openSUSE MicroOS using Zypper</td>
			<td>package</td>
		</tr>
		<tr>
			<td>i+</td>
			<td>zypper</td>
			<td>Command line software manager using libzypp</td>
			<td>package</td>
		</tr>
		<tr>
			<td></td>
			<td>zypper-aptitude</td>
			<td>aptitude compatibility with zypper</td>
			<td>package</td>
		</tr>
		<tr>
			<td></td>
			<td>zypper-changelog-plugin</td>
			<td>Changelog listing tool</td>
			<td>package</td>
		</tr>
		<tr>
			<td></td>
			<td>zypper-keys-plugin</td>
			<td>Zypper plugin to manage RPM keys</td>
			<td>package</td>
		</tr>
		<tr>
			<td></td>
			<td>zypper-lifecycle-plugin</td>
			<td>Zypper subcommand for lifecycle information</td>
			<td>package</td>
		</tr>
		<tr>
			<td>i+</td>
			<td>zypper-log</td>
			<td>CLI for accessing the zypper logfile</td>
			<td>package</td>
		</tr>
		<tr>
			<td>i+</td>
			<td>zypper-needs-restarting</td>
			<td>needs-restarting compatibility with zypper</td>
			<td>package</td>
		</tr>
	</tbody>
</table>

? If so, I disagree, not merely for the undermentioned, but also because I find it less legible.

It helps when programmatically parsing, since without an explicit column delimiter, there’s no way to determine where a column ends horizontally.

Either is suitable in HTML. In terminal output - less is more, but only if remaining understandable. In reference to my post, I mentioned personal design. Alter the solutions I provided to demarcate columns as you desire. As I said, the solutions are foundations.