4 ms·

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

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 `\`...
      - dickeytk 7y ago
        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 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.
        jovdg 7y ago
        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...

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 `\`...
    - dickeytk 7y ago
      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 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.
      - jovdg 7y ago
        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...