Live data from Hacker News

An Illustrated Guide to Useful Command Line Tools

wezm.net

81–90 of 108 posts

Re: An Illustrated Guide to Useful Command Line Tools

#81
post #76

Earlier quoted context omitted.

While I agree that find has weird quirks to my liking, your example is not a great one. I would write the find as follows: `find /prog -type f -size +500k -name core -delete` Alternative: `find /prog -type f -size +500k -name core -exec rm -v {} +` For extra context: `-print` will just show you the results before `rm`'ing. When the command ends with `\;`, the command will be repeated for every match. If the command e…

TIL, but that’s my point. If after many years of doing this and leading the development on one of the top utilities on homebrew I don’t immediately know the answer to these things, how could anyone. UX is FAR more important in the CLI than even on the web. Users don’t just have to be able to learn what they want to do, for these common tools they have to memorize it or they won’t use it. Minor things like the order o…

I can't entirely agree with you. Some points:

* The find syntax for this use case is almost identical to the syntax for fd (you may nitpick about "file" vs "f")

* Education would certainly help! How do you think anyone (me, as a data point) learned?

* Tab completion in the shell goes a long way. You will find yourself using the same flags often.

That being said, `find` brings with it a long legacy, which we don't all care for. Many of the options are practically unused, certainly by regular developers.

I find myself using ripgrep instead of grep, but still use find instead of fd.

And I still have a hell of the time as soon as I want to `prune`. I'd much rather `grep -v` at that point, but then I probably need to invoke `xargs` in the next step...

Re: An Illustrated Guide to Useful Command Line Tools

#82

I’m gonna sound like an old person here. As much as these tools are gorgeous and ergonomic, remember that the others are standard, which means they’re available (almost) everywhere. Still though, these alternatives seem great for productivity locally, even if they’re not usable in a script.

I’ve actually found myself using these to get me much more proficient in the Shell overall. fd in particular is so much easier to use I find myself doing things like: fd .log$ -x mv {} {.}.bak (Rename *.log to *.bak) Can I do that with xargs, awk, and find? Yes, but every time I have to look up the man page to at least one of them and it’s enough friction that I might just open it in finder if it’s a handful of files…

Doing this with find is only marginally more difficult.

  find . -name '*.txt' -exec rename .log .bak {} \;
If your rename is prename by default you can use sed style replacement. Not to disagree with your overall point.

Re: An Illustrated Guide to Useful Command Line Tools

#83
post #58

Earlier quoted context omitted.

in your example it is not cat who "interprets" the escapes, but echo

Neither one interprets the sequence, but cat will print the file unfiltered to stdout, and stdout is processed by your terminal, and then the terminal will interpret it. less filters before printing to the terminal.

I meant that "echo -e" transforms the four characters "\033" into a single byte, for example. Thus, the sequence is "interpreted" by echo. Then, the cat program just copies the bytes without looking at them. If you want "cat" to escape these bytes so that they are not seen by the terminal you can use the "-v" option.

Re: An Illustrated Guide to Useful Command Line Tools

#84

Earlier quoted context omitted.

You are right, it does not. But the find command is not too complicated, or different from the one above.

find has awful ergonomics that are completely unlike any other common unix tool. I can never remember the syntax, how the flags work, or what order things need to be in. Let's use an example I just dug up of using find: To list and remove all regular files named core starting in the directory /prog that are larger than 500KB, enter: find /prog -type f -size +1000 -print -name core -exec rm {} \; OK first, how in the…

Your fd command:

Why type=file and a size? What else has size in 500k range on a filesystem, except files?

=+500 isn’t how math works, that’s implying it could be -500 or using equals for an inequality because the commonly used greater than symbol is off limits, it’s a learned bodge.

500kwhats? Bits? Bytes? Base2? Base10? Can I put a suffix on, is it kB and kb case sensitive?

Why is your filename on the left of the folder you want to look in? That’s so backwards to the left to right order /folder/files are normally written.

Why do you have some arguments with double dash, some with single dash, some with no arg name at all, what’s the pattern for any of that?

What’s -x and why is it short for a word beginning with E?

Why is the find command executing anything at all?

It’s no more immediately sensible than find, it’s inconsistent scribble and workarounds you’ve learned instead of the same that you haven’t learned.

Re: An Illustrated Guide to Useful Command Line Tools

#85

Earlier quoted context omitted.

You might like zsh if you haven't tried it. Has a builtin `zmv` that does this. Check out oh-my-zsh

This suggestion is exactly why fd is so helpful. With zmv I can rename files in a directory. Great. But what if I want to count the number of total files within each directory? Create tarballs out of each directory? Rename files that contain the word "FOOBAR" in them? I can do this with fd and similar tools with slight modifications. With zmv I can rename files.

Cool! zsh also does a few things other than renaming files.

Re: An Illustrated Guide to Useful Command Line Tools

#86
post #48

No mention of things that have gained a lot of traction, like `ag` and `fzf` ag: - silver searcher, fast parallelized recursive grep that can abide by things like `.gitignore` fzf: - fuzzy finder powerline-shell - $PS1 on steroids

It does mention rg which is in the same category as ag and, maybe this is my own bias, seems to have more mindshare now.

Re: An Illustrated Guide to Useful Command Line Tools

#87

in order to avoid having to unlearn commands like cat and ls, I use aliases to invoke bat and exa. Here's a screenshot of my fish config: https://twitter.com/mxschumacher/status/1168993005744918528

I would do alias ls "exa" alias ll "exa -ll" That way you get the nice shorter output which comes in handy for piping ls things like: ls -d | xargs ls Lists the files in subdirectories.

good idea - thank you!

Re: An Illustrated Guide to Useful Command Line Tools

#88
post #61
post #18

I quite like this list, there are a number of utilities here that I already use on a daily basis. There are also a few utilities that I like that weren't on this list, or some alternatives to what was shown. Some off the top of my head: - nnn[0] (C) - A terminal file manager, similar to ranger. It allows you to navigate directories, manipulate files, analyze disk usage, and fuzzy open files. - ncdu[1] (C) - ncurses d…

And regarding ncdu, there are static binaries for Linux. Just put them in a folder and use them.

Nice. I've missed the static binaries on the homepage and should have tried static compilation myself. Now my little python2 and find-based scripts exporting ncdu-compatible outputs[1] on systems without ncdu seem a bit redundant. On the other hand, there are some examples of filtering the output with jq.

[1]: https://github.com/wodny/ncdu-export

Re: An Illustrated Guide to Useful Command Line Tools

#89

in order to avoid having to unlearn commands like cat and ls, I use aliases to invoke bat and exa. Here's a screenshot of my fish config: https://twitter.com/mxschumacher/status/1168993005744918528

For clearing the screen, try 'Ctrl-l' (lowercase L)

A quick lookup suggests fish handles some of these differently than bash (apparently fish clears the buffer with this shortcut, so your scroll back is gone?).

There are a quite a few of these for anyone interested: https://kapeli.com/cheat_sheets/Bash_Shortcuts.docset/Conten...

Re: An Illustrated Guide to Useful Command Line Tools

#90

I’m gonna sound like an old person here. As much as these tools are gorgeous and ergonomic, remember that the others are standard, which means they’re available (almost) everywhere. Still though, these alternatives seem great for productivity locally, even if they’re not usable in a script.

>I’m gonna sound like an old person here. As much as these tools are gorgeous and ergonomic, remember that the others are standard, which means they’re available (almost) everywhere.

Well, I, for one, don't work "almost anywhere", I work with specific servers. I ain't gonna get a new server out of the blue. And if some teams works with the same N servers, they can mandate that the tools are present on all of them.

Plus even on some unknown system, one can quickly copy or download a set of static binaries as our toolset.

So unless someone is a sysadmin for heterogenous networks, or is called to go to random clients and fix unseen before systems, or some corporate mandate prevents them from having their tools installed, there's no reason not to expand beyond standard POSIX userland.

Post reply on HN