5 ms·

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

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.

dickeytk 7y ago
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. 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.
- rhizome 7y ago
  bash/zsh: for f in *.log; do mv "$f" "${f/%log/bak}"; done a bit more generic, `for` loops and parameter expansion are good to know for proficiency, and also I dislike typing curly braces.
  - rovr138 7y ago
    Hah, thankfully I refreshed. Was about to post something similar. No need for xargs, awk or find
  - mtzet 7y ago
    This doesn't move files in subdirectories? Or am I missing something?
    - pfortuny 7y ago
      You are right, it does not. But the find command is not too complicated, or different from the one above.
      - dickeytk 7y ago
        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 hell is 1000 == 500kb? Is that a bug in my example[0]? What does `-print` do exactly? And that backslash at the end? I have no clue what that signifies. I'm never going to remember this madness. I'd probably have resorted to writing a bash script in a file by now. But with fd it becomes manageable and memorable for future tasks: 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 {} Now that's something that makes immediate sense even if you've never touched the tool before. Not to mention, it doesn't end up in my .git and other ignored directories. [0] https://kb.iu.edu/d/admm https://kb.iu.edu/d/admm
        jovdg 7y ago
        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 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 `\`...
        7y ago
- nebulous1 7y ago
  You might like zsh if you haven't tried it. Has a builtin `zmv` that does this. Check out oh-my-zsh
  - dickeytk 7y ago
    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.
    - jdc 7y ago
      How do you rename files based on contents with fd?
      - dickeytk 7y ago
        I would use rg. My original point is not that fd is a do anything tool, it’s that fd and others are a much better replacements for find, grep, etc that when I want to do something complex they’re much better starting places.
    - nebulous1 7y ago
      Cool! zsh also does a few things other than renaming files.
- jcranberry 7y ago
  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.
gameswithgo 7y ago
ripgrep is included in some linux distros standard now.
- dblotsky 7y ago
  In this case, I mean the POSIX standard. But yes, shipping by default in operating systems is how things (eventually) make it into the standard!
InafuSabi 7y ago
I don't think its old fashioned at all, the arguments are solid. It's just like `uname -a` works under freeBSD, linux, darwin et all. The standard tools rule supreme IMHO.
coldtea 7y ago
>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.
- fao_ 7y ago
  > Plus even on some unknown system, one can quickly copy or download a set of static binaries as our toolset. 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.
- kakwa_ 7y ago
  Well, it's not always so simple. 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.

dickeytk 7y ago

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. 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.

rhizome 7y ago
bash/zsh: for f in *.log; do mv "$f" "${f/%log/bak}"; done a bit more generic, `for` loops and parameter expansion are good to know for proficiency, and also I dislike typing curly braces.
- rovr138 7y ago
  Hah, thankfully I refreshed. Was about to post something similar. No need for xargs, awk or find
- mtzet 7y ago
  This doesn't move files in subdirectories? Or am I missing something?
  - pfortuny 7y ago
    You are right, it does not. But the find command is not too complicated, or different from the one above.
    - dickeytk 7y ago
      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 hell is 1000 == 500kb? Is that a bug in my example[0]? What does `-print` do exactly? And that backslash at the end? I have no clue what that signifies. I'm never going to remember this madness. I'd probably have resorted to writing a bash script in a file by now. But with fd it becomes manageable and memorable for future tasks: 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 {} Now that's something that makes immediate sense even if you've never touched the tool before. Not to mention, it doesn't end up in my .git and other ignored directories. [0] https://kb.iu.edu/d/admm https://kb.iu.edu/d/admm
      - jovdg 7y ago
        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 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 `\`...
        7y ago
nebulous1 7y ago
You might like zsh if you haven't tried it. Has a builtin `zmv` that does this. Check out oh-my-zsh
- dickeytk 7y ago
  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.
  - jdc 7y ago
    How do you rename files based on contents with fd?
    - dickeytk 7y ago
      I would use rg. My original point is not that fd is a do anything tool, it’s that fd and others are a much better replacements for find, grep, etc that when I want to do something complex they’re much better starting places.
  - nebulous1 7y ago
    Cool! zsh also does a few things other than renaming files.
jcranberry 7y ago
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.

gameswithgo 7y ago

ripgrep is included in some linux distros standard now.

dblotsky 7y ago
In this case, I mean the POSIX standard. But yes, shipping by default in operating systems is how things (eventually) make it into the standard!

InafuSabi 7y ago

I don't think its old fashioned at all, the arguments are solid. It's just like `uname -a` works under freeBSD, linux, darwin et all. The standard tools rule supreme IMHO.

coldtea 7y ago

>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.

fao_ 7y ago
> Plus even on some unknown system, one can quickly copy or download a set of static binaries as our toolset. 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.
kakwa_ 7y ago
Well, it's not always so simple. 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.