what do you mean? jq is great!

Don’t want to sound unappreciative, but the apps you refer to (and others in these threads) are not actually CLI’s but TUI’s.

• CLI (command line interface) is when all interaction actually happens in the command line, ie. command + arguments. CLI’s are much simpler to implement, have little dependencies (pretty much just argument list, two data streams—stdout and stderr–and exit status) and typically one invocation means one independent task. All this makes CLI’s ideal as building building blocks of (semi-)automated workflows, but many CLI’s are also optimized for direct invocation from interactive shell, eg. by adding features such as output coloring, interactive yes/no steps or command completion (although that part is actually driven by the shell, and is quite independent from the execution of the app.)

• TUI (text user interface, i think) on the other hand, is more like GUI but replicated within the confines of terminal emulator. The interaction heavily depends on terminal features such as moving cursor, resize notifications, etc. Also when TUI is ran, it’s normally used for zero to may tasks: e.g. I could start htop and investigate no process, 1 process or many, before quitting. Unlike CLI’s, TUI’s pretty much make no sense within automation.

Don’t get me wrong: I love TUI’s (htop is one of my favorite and thanks for recommending nmon, i’ll have a look)–and often prefer them to GUI’s (eg. my text editor is nvim, which is a TUI app!), but in my post I was specifically interested in exploring CLI’s. I would actually love a similar post to mine but focusing explicitly on TUI’s as opposed to CLI’s.

Sorry for long post – I hope it can kind of serve as explanation for people who are new to this and stumble upon this thread and aren’t quite familiar with the distinction.

Did not want to respond but this is hilarious.

To be fair, really old CLI’s, like from the time when X.org was the new stuff, this style used to be more common. That was before “GNU style” (using single dash for single-letter bundle-able options and double dash for long options) became prevalent.

But yeah, if you see -foo then you know the program is old enough that regular colonoscopy is recommended, and the original author is probably retired or “passed away at the ripe age of …”.

Good point.

Ironically … i’ve played exactly the same game in Proton on Steamdeck (I’m assuming that’s using Proton; i did not check TBH) just few weeks ago and it all worked just fine. Maybe they fixed it in the meantime or it depends…

(But yeah your point stands.)

then have them slowly realize over time that you’re not just going to bullshit around but actually find and incorporate viable alternatives into your workflow, even if some steps will be inconvenient, and have them feel that something like that is now expected of them and slowly start avoiding you or subconsciously marking you as extremist and feeling the need to defend MS in front of you on behalf of “but most people…”.

yeah, that’s the sweet spot.

because they want to see ads in their start menu, send their pictures to some MS servers and have their notepad.exe crawl and crash because of AI.

you know, all the fun stuf…

wow, i’ve been using bash command line extensively for over 10 years and i’ve missed this gem completely. :-D

and there’s more in help fc:

fc [-e ename] [-lnr] [first] [last]
fc -s [pat=rep] [cmd]
[...]

That’s the real linux user story.

We come for the speed, flexibility, FOSS values … but we STAY for the middle mouse paste.

Well it seems like this “Aaron Day”, for one, does.

(I hope he’s not the only one :D)

I think vipe is underrated; it takes whatever is on its stdin, shoves it in a temp file, opens your favorite text editor (EDITOR environment variable) and waits in the background until you finish editing the file and close it. Then it outputs the edited text to its stdout.

It’s useful in all kinds of pipes, but personally I use it tons of times a day in combination with xclip, in something like this:

xclip -o -selection primary | vipe | xclip -i -selection clipboard

(I actually have a bit fancier version of this pipe wrapped in a Bash function named xvxx.)

On my setup, this takes my current text selection, opens it in vim, and lets me edit it before it sends it to the “traditional” Ctrl+C clipboard. It’s super handy for editing comments like this one.

If you often find yourself writing complex Bash pipelines involving generating some output and then running set of commands per line (perhaps in a while loop), sometimes replacing the “selection part” with vipe can be easier than coming up with right filter.

find_or_ls_or_grep_something | vipe | for while read -r foo; do some_action "$foo"; done

And if you are really confident with Bash, you can go even a step further and do:

you might find something like this useful sometimes:

find_or_ls_or_grep_something | vipe | bash

and just create a large dumb one-off script, manually curating what’s exactly done. Remember that editing large lists in vim can be made much easier by utilizing vim’s ability to invoke unix filter commands (those greps and uniqs and seds et al.) on the buffer, and /or block editing mode using Ctrl+V (that last one method goes really well with column -t).

alias lr='ls -lhrt'

FTR, <<< is a bashism. it’s a nice one, though.

FAR manager (clone of Norton Commander) might be worth giving a look. Not a GUI, though, it’s TUI but responds to mouse.

On Debian, sudo apt install far2l and then run far2l.

BTW, to add ssh-agent authenticated scp connection, press F11, go to NetRocks and create connection. in the dialog you’ll need to select the protocol to scp and then auth method in “protocol options”. you can edit an existing connection by going back to the connection “directory” and using F4 on the connection. Once you connect you can copy/move files back and forth.

Along with scp it supports eg. smb, nfs and davs.

Your question, “What features does the Windows version of Calibre have that the Linux version not have?” cannot be answered without accepting an unargued premise: that the windows version has more features than the Linux version.

Nope, it simply asks (or even expresses genuine curiosity) about a subset of features on windows which might be missing in Linux version. That’s if you want to be super logical and fussy about things. If not, you could have just answered or moved the discussion in any relevant direction you would like. That was always allowed.

Ironically, you kinda did answer it, at least in part, by mentioning the AI slop bloat. Why hide your answer behind a wall of being a jerk, though? I can only speculate. Too little sleep, too many old Rationality Rules videos? :-) Thatt’s none of my business; I just hope you feel better now.

point taken. I see how it can be a good balance of pros/cons.

re: debianland, i’m not sure i understand the question so…

Certain major version of a “traditional distro”, say debian 13 provides fixed list of libraries and apps (which get updated during the lifetime but only to necessary extent). each of those can only depend on a particular version selected by debian. eg. if for libfoo, the provided version is libfoo-1.2, then anyone who depends on libfoo must depend on libfoo-1.2. (if that can’t be achieved before release then that package is simply removed.)

note that two versions of the same package can’t co-exist on the same system. (this is basically true for debianland and fedoraland; because packages share the same filesystem it would be not feasible to make it work without huge amount of added complexity and bug surface. definitely not on a distro-wide level).

honestly i’ve never used backports; I don’t know what process they use to select versions; i would assume that it’s basically on a best effort basis.

personally if i don’t find the stable version new enough, I look for vendor repo, appimage or flatpak (roughly in that order)

I’ve found it helpful to install as much as possible as flatpak, since that decouples app updates from system updates

But doesn’t it eat all disk space? And don’t flatpak apps tend to proliferate dependencies on outdated stuff? From my experience (and that’s just maybe dozen of apps that simply don’t exist in the distro) when running flatpak update i always get deprecation warnings about some platform flatpaks that some of the apps depend on. And given that everything is few hundreds of megs, sigh…

That’s why I like distros like Debian: there’s always strong pressure for apps to converge towards newer versions of libs/frameworks. Sure, it takes work to maintain but IMHO it’s worth it: once the app is in, you know it’s playing nice at least to that extent. AFAIK one of Flatpak’s core features is to lower the barrier by allowing multiple dependencies co-existing and thus removing that pressure, but that’s when the mess is inevitable.

Sorry for the rant.

That sounds really evil, esp. if you already have low expectations and it’s not like I’m going to defend ol’Bill, but…

Do we know what he used the patents for?

Acquiring patent sounds like you want to use it as a gold mine by manufacturing the product for “best” price, which is pretty heinous, especially when it’s in conflict with saving lives. But in principle it could be the opposite. One could, entirely for altruistic reasons acquire a patent from someone with the intent to make the cure more affordable.

I mean, I don’t like Bill but let’s be honest, he’s no RFK Jr.

Damn the clickbaitines of those video titles could make an old cowboy cry.

…but “don’t judge the book by the cover”, they say…

Use as $meta in my .i3/config, so … lots of things.

OT, but I feel like I keep seeing more of these “foo 1.2.3 released” announcements here on this channel.

Is it on topic, though? Shouldn’t the channel be more about Linux specific topics, rather than place for people to discuss updates of arbitrary selection of apps which just share the fact that they also run on Linux?

Edit: Technically the “I feel like” part was true but looking at the topic post … factually I’m totally wrong; it’s like 1 in 20 at most.