alias e='echo "${@}"' Wait a second, Bash does not process arguments in alias. This is an incredible trick new to me! All the years I was writing a function to accomplish that. I wonder if there is any drawback to this technique.

Aliases themselves do not take arguments. You can write Bash function for that case. Here is a “simple” example. I leave the comments there explaining the command too:

treegrep() {
    # grep:
    #   --recursive             like --directories=recurse
    #   --files-with-match      print only names of FILEs with selected lines
    # tree:
    #   --fromfile              Reads paths from files (.=stdin)
    #   -F                      Appends '/', '=', '*', '@', '|' or '>' as per ls -F.

    grep --recursive --files-with-match "${@}" |
        tree --fromfile -F
}

# usage: yesno [prompt]
# example:
#   yesno && echo yes
#   yesno Continue? && echo yes || echo no
yesno() {
    local prompt
    local answer
    if [[ "${#}" -gt 0 ]]; then
        prompt="${*} "
    fi
    read -rp "${prompt}[y/n]: " answer
    case "${answer}" in
    [Yy0]*) return 0 ;;
    [Nn1]*) return 1 ;;
    *) return 2 ;;
    esac
}

I do write scripts and commands (and Bash aliases or functions) all the time. The scripts live in ~/.local/bin and are executable like any other program, as that directory is in my PATH variable. I have a projects directory where I archive them, and some of them are uploaded to my Github account. Some of them are later rewritten in Python and get a life on its own.

1. yt-dlp-lemon: Simple wrapper to yt-dlp with only a subset of options.
2. unwrap: Wrapper to marry GNU Parallel and 7-Zip for archive extraction.
3. biggest: List biggest files and folders.
4. ?: cheat .sh - The only cheat sheet you need. (Note, commands name is just ?)
5. woman: Preview list for man documents.

Besides my more simple scripts and aliases and functions.

alias update='eos-update --yay'
alias updates='eos-update --yay ;
  flatpak update ; 
  flatpak uninstall --unused ; 
  rustup self update ; 
  rustup update'

#!/usr/bin/env bash

for file in "${@}"; do
    output="${file%.*}.mp3"
    if [[ -f "${output}" ]]; then
        continue
    fi
    ffmpeg -i "${file}" -b:a 320k "${output}"
done

Yes. If you are a human, please try it out and tell other humans if its usable. It will be different for every human, so make sure to list reasons if it is not usable.

To sum it up:

As often with the first version in a new series, GIMP 3.2.0 had a few annoying issues, and the most problematic of these was the bug where some layer groups would not render in specific conditions (when particular filters were used). This was the main bug warranting this early bug-fix release.

It’s mostly a bug fix with a few simple improvements for import related stuff. Plus a few little UX/UI Updates.

Ah that’s a good one too. I like the tabs. After my postings, I did some changes since then. Will do some further adjustments to the tabs. Iike its taking the full height of the tab row. The main thing I changed is having only one Bookmark folder in Bookmarks Toolbar, and put it in the same line as the tabs as a menu.

“They”. That’s one sort of people who does RTFM the wrong way in my opinion. If I do RTFM, even for obvious simple ones, I most likely point to where to look at, ideally with a link. I do not RTFM literally, but saying there is some documentation and pointing to it usually. To me just saying RTFM (literally with this acronym) is rude, especially if someone already struggles and asks basic questions. Not everyone is “they”.

The idea of RTFM is that if you have questions, then we are all on same page with basic information found in the manual. I mean you expect others explain what is already said in the manual. Its like asking how to use your microwave oven, even if you have the manual right at your hand. Now, if the manual is unclear or difficult to understand, that is a different story. Then you can at least say you didn’t understand it. The point is, that you did something before (your homework) and looked at the obvious places like the manual (and maybe further websearch).

People don’t like others being lazy and asking the questions that doesn’t need to be asked. That’s why RTFM exist. As much as you might take the “RTFM” as an offending answer, those people think of you question as offending too. Now there are people who use this term loosely in places when it is not appropriate. Also it depends on the audience. If your grandma tries to use a browser to watch funny cat videos, and asks how to use it, then it would be inappropriate to say RTFM. But if you have a Linux user who asks about how to use grep, then I think it is an appropriate reply.

No problem, it’s always good idea to ask.

By convention two dashes -- are used for options with long name, such as --remove, while single dash - is used for single letter options such as -R. There can be some extra rules how options are used and combined, but that is not always true for every application. A common implementation is that options with single dash can be combined to have less to press, while double dash options cannot. Meaning if you have options -a -b -c then you could combine them into one bucket as -abc or -ab -c, all equivalent. But you cannot combine --remove -a -b into --abremove in example. There can be some extra rules and some applications handle options bit differently.

I know how subcommands work. But that is not the point I am making. Having two dashes in front of it or not like pacman remove or pacman --remove does not change how the command operates. It is literally having two dashes or not and therefore is not an issue.

I don’t think it would make ANY difference if the option was named git --pull instead git pull (you don’t have to use the single uppercase). That is NOT the same semantic difference between <b> and <h3>, because it (the pull example) operates the same as before. The only difference are the two dashes. I don’t see how this creates confusion or learning difficulties.

But its just a matter of 2 dashes. It shouldn’t be a problem.

I don’t get why that is a problem. It’s just an option name with 2 dashes in front. In fact, that is the “correct” way of handling options, as in standard option processing in GNU / Linux. I personally dislike options without dash, but on the other hand it does not bother me enough to be bothered by it. pacman --remove is almost identical to pacman remove, so I don’t know why that is a “problem”.

You can use long option names instead too, as each capital letter mode has a long option name, such as -R --remove and -S --sync.

-S stands for “sync”. You are syncing to the online database.

I hate that too. 7z does that and its horrible.

I don’t think there is some exceptional good CLI interfaces. If anything, you either notice the interface is bad or unconventional or it is cluttered, because it has lots of functionality. It also depends if it “should” fit into the Linux eco system (similar commandline system and logic) or is this tool used for any operating system. I have my own scripts as wrapper for some tools, so they are excluded from discussions here. Note I think the discussion is about commandline interfaces that operate non interactive (in other words no “live” TUIs or interactive editors), so no Vim or htop.

Tools like yt-dlp or awk or find or git are complex and overloaded with functionality, because it offers so much and has to offer all of that. Or the command works different, because of its nature of calling another command like parallel. Then there are commandlines that just deviates from the standard and bugs me a lot. One of the worst offenders to me is 7z from package extra/7zip in the Arch repositories. But it is not a standard GNU tool, therefore it does its own thing.

So in the end, I do not think there is an exceptional good CLI, only bad or complicated ones. As long as it follows Linux standards its good to go. Often the best Rust CLI tools have pretty good ones that could be listened as standouts, but none specific in particular.

There was outlier in GNOME outperforming KDE by a large amount too.

Edit: Okay, maybe not that large. I agree with you, that the outlier they had (included twice even) has a huge impact. But it is some real game and with real settings and configuration. So making an exempt just because you don’t like the results would be faking the result. They just should have included a result without the outlier, just for comparison.

I was under the impression that the desktop environment (especially GNOME vs KDE) performs about the same in gaming or graphics in general. Some of the results are pretty shocking to me how much they can differ.

So this is about NTSYNC (mostly). Based on the post title, I was wondering what changed so drastically. This is a good read to give me some understanding about the NTSYNC topic. Still reading through. What a huge difference to those random blog posts written by an Ai model.