u/ClassroomHaunting333

Hi everyone

Not sure if this is the right sub, but I already tried other subs like r/zsh , r/commandline and others, but no luck.

I am working on a personal project and while refining the functions/history matching logic to address early mutation typos like ccd instead of cd, the project faces a classic architectural trade-off between output cleanliness and edge-case coverage.

Currently, the single-character prefix filter provides reliable and clean output pool for 99% of user typos, including mutations inside trailing directory arguments:

local -a narrowed_entries=()
if [[ ${#last_typo} -ge 1 ]]; then
    local prefix="${last_typo[0,1]}"
    narrowed_entries=(${(M)hist_entries:#${prefix}*})
else
    narrowed_entries=("${hist_entries[@]}")
fi

The Dilemma I am facing

This approach goes blind if a user makes a typo on the absolute first character of a command (for example typing vcd functions instead of cd functions).

To resolve this 1% edge case, experimenting with multi-character character sets or dual-prefix lookups (matching vc*) successfully injects the intended target cd back into the array pool.
However, it introduces a significant downside. It drastically widens the filter pool, pulling in hundreds of irrelevant historical commands (like vim, vlc), or anything that happen to share those initial letters. This pollutes the fzf layout and introduces messy, unrelated suggestions that degrade the user experience.

Personal Choice of Direction

I personally lean towards sacrificing the 1% first-character typo to guarantee a completely stable, clean, and highly relevant list of suggestions for the other 99% of daily interactions. A predictable interface that behaves reliably is more valuable than an over-engineered matching layout that makes messy guesses.

Opening this up to the community: Should I stick to the strict, clean single-character baseline, or is there a performant, dependency-agnostic way to handle first-character mutations without introducing buffer noise into the interactive menu?

Hi everyone

I am working on a personal project and while refining the functions/history matching logic to address early mutation typos like ccd instead of cd, the project faces a classic architectural trade-off between output cleanliness and edge-case coverage.

Currently, the single-character prefix filter provides an exceptionally reliable and clean output pool for 99% of user typos, including mutations inside trailing directory arguments:

local -a narrowed_entries=()
if [[ ${#last_typo} -ge 1 ]]; then
    local prefix="${last_typo[0,1]}"
    narrowed_entries=(${(M)hist_entries:#${prefix}*})
else
    narrowed_entries=("${hist_entries[@]}")
fi

The Dilemma I am facing

This approach goes blind if a user makes a typo on the absolute first character of a command (for example typing vcd functions instead of cd functions).

To resolve this 1% edge case, experimenting with multi-character character sets or dual-prefix lookups (matching [vc]*) successfully injects the intended target cd back into the array pool.
However, it introduces a significant downside. it drastically widens the filter pool, pulling in hundreds of irrelevant historical commands (like vim, vlc), or anything that happen to share those initial letters. This pollutes the fzf layout and introduces messy, unrelated suggestions that degrade the daily user experience.

Personal Choice of Direction

I personally lean towards sacrificing the 1% first-character typo to guarantee a completely stable, clean, and highly relevant list of suggestions for the other 99% of daily interactions. A predictable interface that behaves reliably is arguably more valuable than an over-engineered matching layout that makes messy guesses.

Opening this up to the community: Should I stick to the strict, clean single-character baseline, or is there a performant, dependency-agnostic way to handle first-character mutations without introducing buffer noise into the interactive menu?

Thank you for your time reading this post. All suggestions and advice welcome.

Hi everyone,

I am currently working on a lightweight Zsh plugin that fixes shell typos (in one of the functions) by pulling the closest match from history and passing a filtered pool into fzf for the final selection.

The plugin calculates the matching background array by stripping unique entries out of the $history associative array and applying a standard parameter expansion filter:

local -a narrowed_entries
narrowed_entries=()
if [[ ${#last_typo} -ge 2 ]]; then
    local prefix="${last_typo[1,2]}"
    narrowed_entries=(${(M)hist_entries:#${prefix}*})
else
    narrowed_entries=("${hist_entries[@]}")
fi

This works beautifully for 99% of commands because limiting the pool via a two-character prefix constraint keeps performance rapid and slashes terminal lag.

However, I have run into an edge case when a typo happens right on the second index. For example, a user typos cd apps as ccd apps.

Because of the prefix constraint cc*, it misses the clean history candidate cd apps.

If I drop the constraint down to a single character ${last_typo[1,1]}, it catches second-character stutters perfectly but expands the pool size massively.

If a user typos the absolute first character (like vcd apps instead of cd), even a single-character prefix constraint goes blind unless I drop filtering entirely and dump the raw history file straight into fzf, which introduces bloat.

Are there any native Zsh array manipulation tricks or expansion flags that can handle approximate matches or character proximity offsets cleanly inside the script logic before hitting the UI pipe, without destroying arrays or causing visible lag on massive histories?

Thank you in advance for any suggestions or help.

Hi everyone,

I am currently working on a lightweight Zsh plugin that fixes shell typos (in one of the functions) by pulling the closest match from history and passing a filtered pool into fzf for the final selection.

The plugin calculates the matching background array by stripping unique entries out of the $history associative array and applying a standard parameter expansion filter:

local -a narrowed_entries
narrowed_entries=()
if [[ ${#last_typo} -ge 2 ]]; then
    local prefix="${last_typo[1,2]}"
    narrowed_entries=(${(M)hist_entries:#${prefix}*})
else
    narrowed_entries=("${hist_entries[@]}")
fi

This works beautifully for 99% of commands because limiting the pool via a two-character prefix constraint keeps performance rapid and slashes terminal lag.

However, I have run into an edge case when a typo happens right on the second index. For example, a user typos cd apps as ccd apps.

Because of the prefix constraint cc*, it misses the clean history candidate cd apps.

If I drop the constraint down to a single character ${last_typo[1,1]}, it catches second-character stutters perfectly but expands the pool size massively.

If a user typos the absolute first character (like vcd apps instead of cd), even a single-character prefix constraint goes blind unless I drop filtering entirely and dump the raw history file straight into fzf, which introduces bloat.

Are there any native Zsh array manipulation tricks or expansion flags that can handle approximate matches or character proximity offsets cleanly inside the script logic before hitting the UI pipe, without destroying arrays or causing visible lag on massive histories?

Thank you in advance for any suggestions or help.

Yesterday had an engineer to swap my routers as I upgraded to YouFibre 2000. All went well, he showed me everything, even the speeds on the company devices and I was OK with that.

As soon as he left I went on to the GUI and changed SSID's and passwords for wifi. Then I connected my laptop and phone and run speedtest's. To my surprise I could not get anything higher than 90MB.

Is there anything I could try on my end before I get any response from the support chat(24 hours without response).

I will be happy for any pointers as I am loosing my mind.

Thanks in advance.

[Solved] Faulty cable supplied by YouFibre. Not a first time.

Hey all,

I am new to all of this. I have a new sub with a focus on terminal flows as i would like to separate the discussions from the main subs which are flooded with sometimes meaningless and memes posts.

My main worry is when I start promoting it in the main subs it will get me banned from there as the communities there can be quite unforgiving and toxic at times.

Shall I contact the mods beforehand and ask them if it is OK to mention the new sub or just risk it and post anyway.

Thanks for any advice.

Hi all,

I’m refining a lightweight Zsh utility to map system hardware (PCI IDs) to distro-specific package names. The goal is to avoid the standard "digging through forums" on fresh installs.

I'm currently using a case statement to handle the translation between a generic hardware key (from a local text file DB) and the actual package name for different package managers (pacman, apt, dnf, zypper).

The current mapping logic:

mend_get_pkg_name() {
    local key="$1"
    case "$MEND_PM" in
        pacman)
            case "$key" in
                generic-nvidia) echo "nvidia-dkms" ;;
                generic-intel-wifi) echo "iwlwifi-db" ;;
                # ... etc
            esac
            ;;
        # ... additional PM logic
    esac
}

And the local database sample:

[10de:1c82] | generic-nvidia | NVIDIA GeForce GTX 1050 Ti
[10ec:c821] | generic-rtl8822be | Realtek RTL8822BE/8821CE
[8086:9d70] | generic-intel-audio | Intel Sunrise Point-LP HD Audio

I’m looking for feedback on:

Efficiency: Is a nested case structure the most idiomatic way to handle this in Zsh, or would an associative array (typeset -A) be cleaner for a growing database?

Filtering: I'm using lspci -nn | grep -E 'VGA|3D|Network|Ethernet|Audio|USB' to isolate the hardware. Are there any categories I’m likely missing that are essential for a headless or minimal install?

Data Collection: As I build out the hardware.db file, I'm looking for real-world data to flesh out the mappings. If you're willing to help, I'd appreciate any contributions. Just run lspci -nn | grep -E 'VGA|3D|Network|Ethernet|Audio|USB' in your terminal and paste the output.

Thank you all for any contributions.

Hi all,

It's been couple of months now when I started working on a small, distro-agnostic, Zsh tool called Mend for my own use.

The need for the database is pretty simple: to save me from spending ages on a fresh install digging through forums to figure out which driver package I actually need for my Wi-Fi, Ethernet, GPU and so on. This addition to the current functions is still in it's nappies but might grow into something more robust in the future.

I’ve set it up to use a local text file (hardware.db) that maps hardware IDs to driver packages. It works offline and doesn't rely on any cloud nonsense or AI.

I’m trying to collect a decent list of hardware, but for obvious reasons I can't test it on every bit of kit under the sun.

This is where you could help. If you have a spare minute, I’d appreciate if you could share your hardware details so I can add them to the database. I’m looking to cover the basics that usually break on a fresh install: Graphics, Wi-Fi, Ethernet, Audio, and Bluetooth.

How you can help:

Just run lspci -nn | grep -E 'VGA|3D|Network|Ethernet|Audio|USB' in your terminal.

If you could paste the output here, that’d be brilliant. I’m formatting the database like this:

[VendorID:DeviceID] | [Generic Name] | [Description]

I’m not looking to build a massive, complex project. Just a community friendly tool that, anyone who is interested, can grab to save themselves a bit of a hassle when they install a new distro or run into some error messages.

This is what I have so far:

# Format: [VendorID:DeviceID] | GenericKey | Description
# --- NVIDIA ---
[10de:1c82] | generic-nvidia | NVIDIA GeForce GTX 1050 Ti
[10de:2501] | generic-nvidia | NVIDIA GeForce RTX 3060

# --- AMD/Intel Graphics ---
[1002:743f] | generic-amd-gpu | AMD Radeon Graphics
[1002:73ff] | generic-amd-gpu | AMD Radeon RX 6600
[8086:191e] | generic-intel-graphics | Intel HD Graphics 515

# --- Networking ---
[8086:2723] | generic-intel-wifi | Intel Wi-Fi 6 AX200
[10ec:c821] | generic-rtl8822be | Realtek RTL8822BE/8821CE
[10ec:b822] | generic-rtl8822be | Realtek RTL8822BE
[10ec:8168] | generic-realtek-ethernet | Realtek RTL8111/8168 Ethernet

# --- Audio ---
[8086:9d70] | generic-intel-audio | Intel Sunrise Point-LP HD Audio
[10ec:0255] | generic-realtek-audio | Realtek ALC255/3234

# --- USB Controllers (Bluetooth/HID) ---
[8086:9d2f] | generic-usb-controller | Intel USB 3.0 xHCI
[10ec:8723] | generic-realtek-bluetooth | Realtek RTL8723BE Bluetooth

# --- Input/Touchpads ---
[8086:9d60] | generic-i2c-controller | Intel Serial IO I2C Controller

Thank you all for any contributions.

I’ve been using Arch for some time now because I value the DIY spirit and the ability to build a system that is exactly what I need. But lately, the community, especially on this sub feels like it’s going downhill fast.

I recently shared some of mine custom scripts, one of them being Bluetooth TUI script I wrote to replace some heavy, moody GUI apps.

Instead of a technical discussion about the logic integration, I was met with people calling it "AI slop" or dismissing it because it looked too polished.

When did we stop respecting the KISS principle? I thought the whole point of Arch was to ditch the bloat and build something better.

Instead, the community is gaining a reputation for being one of the most elitist and hated environments in Linux. It feels like if you don't do things the "1995 way" or install packages specifically mentioned on the Arch Wiki and your setup actually looks modern and efficient, you’re treated with suspicion or outright hostility.

This used to be a community of builders. Now it feels like a community of designers showing a big useless clock in terminals. Gatekeepers who are more interested in "calling out" others than actually improving their own setups. It’s a shame, because the Arch Wiki is still the gold standard for Linux documentation, but the people hanging around the sub are making the distro look bad.

I’ve replaced my heavy GUI apps with instant, stable fzf widgets that work better than anything I’ve found in the repos, yet the reaction is just pure cynicism.

Is anyone else tired of the ego-tripping here, or is it just me?