Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Linux tools

ikrima.dev

Post reply on HN
Print view View original

151–160 of 219 posts

Re: Modern Linux tools

#151

Post by qustrolabe »

fergie wrote: post #14

I basically live in the terminal. However, every single one of these tools offers a solution to a problem that I don't have; aren't installed on my system; and mysteriously have many tens of thousands of github stars. I genuinely don't know what is going on here.

You never use fzf? What a tough life in terminal then huh. It's not as useful to run it directly, but pretty much any shell has plugin for fzf support that let's you Ctrl+R to fuzzy search over bash_history (or fish_history or whatever) and Ctrl+T let's you fuzzy search files in current directory.

Re: Modern Linux tools

#152

Post by drob518 »

maeln wrote: post #57
drob518 wrote: post #50

Earlier quoted context omitted.

No. The differentiator is whatever benefits such an implementation might deliver (e.g., performance, reliability, etc.). Customers don’t start whipping out checkbooks when you say, “Ours is written in Go.”

That is what the post you responding to is saying

I’m still responding to the first sentence. It’s not a differentiator, even to smart engineers who understand the programming language in question (e.g., Go or Rust). Whenever an engineer leads with the programming language, I know that it’s just their favorite. You can write great Python, Ruby, Go or Rust, or you can write crappy Python, Ruby, Go, or Rust. Yes, some languages make more sense for certain environments (probably don’t want to do kernel programming in Ruby, for instance), but the programming language is never the differentiator itself. It’s what you make happen with it.

Re: Modern Linux tools

#153

Post by esafak »

Johanx64 wrote: post #115
antegamisou wrote: post #92

Earlier quoted context omitted.

I find the opposite to be true. Most of these are really just reinventing the wheel of foundational GNU tools that are really powerful provided one has spent some time on them.

It's like people dont even know why people use or want these "modern" tools. It's called "sane defaults", and improved UX. Those "foundational GNU tools" just suck, sure, people are familiar with them and they are everywhere, but they just plain suck. For many common operations you'd want to do by default with grep/find and so on, you have to type mountains of random gibberish to get it done. And that random gibberis…

Some people just like torturing themselves with spells like

   perl -ne 'map{$h{lc$_}++}/(\w+)/g;END{map{print"$h{$_} $_\n"}sort{$h{$b}$h{$a}}keys%h}'

Re: Modern Linux tools

#155

Post by mcswell »

oniony wrote: post #121

qq should be on this list. It's like jq but works with multiple file formats, including JSON, YAML, XML, &c. and has a really cool interactive TUI mode. https://github.com/JFryy/qq

THAT looks like something worthwhile; I'll be looking into it.

I was going to top-post that the Unix/Linux command line tools were designed back in the day when data was pretty much line-oriented, e.g. one database record per line. Since then XML, and more recently JSON, have been invented, and tools like grep and sed just don't work for those formats. But you ninja'd me, sort of.

Re: Modern Linux tools

#156

Post by maeln »

maleldil wrote: post #137
maeln wrote: post #53

Every time such a list is posted, it tends to generate a lot of debate, but I do think there is at least 2 tools that are really a good addition to any terminal : `fd`: first I find that the argument semantic is way better than `find`, but that is more a bonus than a real killer feature. Now, it being much, much faster than `find` on most setup, I would consider a valuable feature. But the killer feature for me is th…

> Like, searching for `isLoading` on my frontend (~3444 files) is instant with rg (less than 0.10s) but takes a few minutes with grep. grep will try to search inside .git. If your project is Javascript, it might be searching inside node_modules, or .venv if Python. ripgrep ignores hidden files, .gitignore and .ignore. You could try using `git grep` instead. ripgrep will still be faster, but the difference won't be as…

No i specifically made sure to run it in a dir without a .git, node_modules, etc. It is just that slow

Re: Modern Linux tools

#157

Post by munchlax »

mprovost wrote: post #143
pjmlp wrote: post #12

Earlier quoted context omitted.

I know well enough my way around vi, because although XEmacs was my editor during the 1990's when working on UNIX systems, when visiting customers there was a very high probability that they only had ed and vi installed on their server systems. Many folks nowadays don't get how lucky they are, not having to do UNIX development on a time-sharing system, although cloud systems kind of replicate the experience.

Ed is the standard text editor.

And not installed by default in many distros. FML.

Re: Modern Linux tools

#158

Post by mcswell »

oneeyedpigeon wrote: post #27
anthk wrote: post #15

Modern doesn't always mean better. A better replacement for mplayer was mpv, and in some cases mplayer was faster than mpv (think about legacy machines). - bat it's a useless cat. Cat concatenates files. ANSI colour breaks that. - alias ls='ls -Fh' , problem solved. Now you have * for executables, / for directories and so on. - ncdu it's fine, perfect for what it does - iomenu it's much faster than fzf and it almost…

> bat it's a useless cat. Cat concatenates files. ANSI colour breaks that. It's useless as a cat replacement, I agree. The article really shouldn't call it that, although the program's GitHub page does self-describe it as "a cat clone". It's more of a syntax highlighter combined with a git diff viewer (I do have an issue with that; it should be two separate programs, not one).

I have two uses for 'cat':

1) Piping the contents of some file into a process.

2) Showing the contents of some short file.

Now (1) is better done with redirection (). The only time I use cat is when I'm testing some pipeline where I only want a few lines of input, so I use 'head' or something similar. Once I have the pipeline working right, I edit the command line to replace 'head' with 'cat'. Easier than re-arranging whole words.

And it's rare that (2) is the right solution--too often I find that the file was longer than I thought, and I have to use 'more' (actually 'less').

So a replacement for 'cat' that does color coding sounds pretty much useless to me.

Re: Modern Linux tools

#159

Post by maeln »

149765 wrote: post #109
maeln wrote: post #62

Earlier quoted context omitted.

`find` only support `{}`, it does not support `{/}`, `{//}`, `{.}` etc, which is why you often need to do some parsing magic to replicate basic thing such has "the full path without the extension`, `only the filename without the extension` etc

I think GNU parallel has similar placeholders, but I do prefer to just use `fd`.

I think it does, and tbf, `fd` is bascially `find` + `parallel`, but I do find that it is nice that it is just one tool and I don't need GNU parrallel :)

Re: Modern Linux tools

#160

Post by oneeyedpigeon »

mcswell wrote: post #158
oneeyedpigeon wrote: post #27

Earlier quoted context omitted.

> bat it's a useless cat. Cat concatenates files. ANSI colour breaks that. It's useless as a cat replacement, I agree. The article really shouldn't call it that, although the program's GitHub page does self-describe it as "a cat clone". It's more of a syntax highlighter combined with a git diff viewer (I do have an issue with that; it should be two separate programs, not one).

I have two uses for 'cat': 1) Piping the contents of some file into a process. 2) Showing the contents of some short file. Now (1) is better done with redirection ( ). The only time I use cat is when I'm testing some pipeline where I only want a few lines of input, so I use 'head' or something similar. Once I have the pipeline working right, I edit the command line to replace 'head' with 'cat'. Easier than re-arrangi…

Right, don't think of it as a cat replacement, think of it as a coloriser. If you never want a coloriser, fair enough, ignore bat! But I find it quite nice when I'm reading through source code or Markdown.
Post reply on HN