Still though, these alternatives seem great for productivity locally, even if they’re not usable in a script.
fd .log$ -x mv {} {.}.bak
(Rename *.log to *.bak)
Having some of these utilities around is a crutch that let me leverage the entire ecosystem much more when I don’t have it. And when I do log into a shared enviroment and don’t have my crutch, then it’s easy to fill in the missing puzzle piece because it’s one part that’s missing and I’ve got the rest of the environment down.
Of course if all you do is shared environments I wouldn’t suggest these, but I would encourage people to use these to get more familiar with the CLI ecosystem.
a bit more generic, `for` loops and parameter expansion are good to know for proficiency, and also I dislike typing curly braces.
No need for xargs, awk or find
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 {} \;
To list and remove all regular files named core starting in the directory /prog that are larger than 500KB, enter:
fd --type=file --size=+500k ^core$ ./prog -x rm {}
`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 ends with `+`, the results are appended until max args is reached (and then repeated). This is not always possible, but when it is, it's way easier to use. Less calls to the command, but certainly useful when appending the command after an ssh command, which would mean any number of extra `\` to escape the original `\`...
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 of the flags and bits like having to escape the semicolon don’t just make it challenging. I would argue for 99% of users they make it impossible.
In other words, I think 99% of users don’t know how to use this level of find and will never learn. That’s a problem and no amount of education is going to fix it. The tool itself is broken.
* 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...
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.
Directories. They have a size depending on the metadata list of included files they contain. And can retain their size even if their inner files are deleted (until some cleanup style process is run).
>It’s no more immediately sensible than find
Oh yes, it is.
The same nitpicking for find would take 10 days, and wont be as contrived...
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.
find . -name '*.txt' -exec rename .log .bak {} \;
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.
Aha, even on a machine with networking problems running a non-glibc set of libraries? (muslc has some problems running glibc (even static,) binaries OOTB, and most docker systems use alpine as a base which means... dealing with musl).
> 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.
I don't believe that the person in question was arguing against expanding beyond the POSIX userland -- rather that they were arguing for maintaining familiarity with POSIX tools in case you need to use them.
If you are in a small team of 5 or 6 people, with less than 100 servers to manage, sure, it's doable.
But if you are part of a very large team of 50 or more sysadmins, with a large infra in the thousands of nodes with various OSes and vintage of OSes (even if Unix only), things can get tricky quite quickly.
First a lot of people will want their favorite tools to be installed which can result in a huge mess of special toolboxes not being consistently installed (different path location, tool set varying from server to server).
Second, these tools, specially the shiny newer ones, need to be built, packaged and maintained properly which represent a significant load, specially across several OSes/Vintage of OSes.
Third, as a general rule, having an install base with as few packages as possible is generally a good thing, on one hand it reduces the surface of exposition of a server, on a second hand, it helps auditing for security vulnerabilities as "dead weight" dependencies (ex: libX11 for an editor which is both terminal based and graphical based, but only used in its terminal form on a server) will not trigger false positives in term of CVEs.
My point was more about education. I think becoming an expert in the standard tools should come before learning any custom ones, because it is a transferable skill.