4 ms·

It's to deal with problematic filenames (e.g. containing a newline) and enables setting of variables within the current process. Putting multiple commands into

It's to deal with problematic filenames (e.g. containing a newline) and enables setting of variables within the current process. Putting multiple commands into the "-exec" of find is possible, but looks horrible. To be fair, my example didn't use multiple commands, so your version is okay for simple processing. Don't get me wrong, the BASH man page is great, it's just that I prefer to work with examples. For reference, here's the Greg's Wiki explanation: https://mywiki.wooledge.org/BashPitfalls#for_f_in_.24.28ls_.2A.mp3.29 https://mywiki.wooledge.org/BashPitfalls#for_f_in_.24.28ls_....

1718627440 10mo ago
On my computer touch "$(echo -en 'a\nb')" find . -type f -name '*.mp3' -exec bash -c "echo '{}'; ls '{}'" ';' works just fine, but maybe it doesn't work everywhere. If you don't like how the multiple commands look like, you can always write it like this: find . -type f -name '*.mp3' -exec bash -c " echo '{}' ls '{}' " ';'
- ndsipa_pomu 10mo ago
  Yep, you can chain multiple commands with find's "-exec", but I'm not a fan of it myself. I suspect setting variables in the current process is trickier though. (Very minor nitpick, it should be 'a\nb.mp3' to be included, but that does work fine) Incidentally, ShellCheck isn't happy with that although I don't follow their reasoning: find . -type f -name '*.mp3' -exec bash -c " ^-- SC2156 (warning): Injecting filenames is fragile and insecure. Use parameters. https://www.shellcheck.net/wiki/SC2156 https://www.shellcheck.net/wiki/SC2156
  - 1718627440 10mo ago
    > although I don't follow their reasoning I think it is sound. Imagine what happens when the filename contains: ' && shutdown now && '.mp3
    - ndsipa_pomu 10mo ago
      Of course that makes sense now. Anyhow here's an example of how I would use the while loop and process substitution in a BASH script: declare -i file_count=0 while IFS= LC_ALL=C read -r -d '' file; do file_count+=1 printf "file: %s\n" "${file}" done < <(find . -type f -name '*.mp3' -print0) printf "Processed %d files\n" "${file_count}" I think that'd be tricky to do using just a find/-exec command.
      - 1718627440 10mo ago
        I see, but now you are essentially operating on multiple files, at once, so the serialization makes some sense. Although for just this, I wouldn't write the operation in bash at all: find . -type f -name '*.mp3' | wc -l Honestly I don't really view the shell / filesystem interface as a security boundary. I use the shell mainly for (automation of) interactive use, so any screwup due to e.g. quoting issues is my own fault, maybe even of using stupid filenames. Shell is a great language to connect streams of different programs into each other, not so much for doing any work. If I do that, I would reach for C.
        ndsipa_pomu 10mo ago
        The serialisation is just to work around the fact that filenames can have any character except for \0 which is why the "-print0" is used. It doesn't by itself allow for concurrent processing. You're right about just using "wc -l", but I was just trying to demonstrate how you can set variables. A real use would be doing more than just counting files as your example would likely be quicker (assuming that calling an external programme is quicker than running a naive loop in BASH). I am guilty of using BASH for stuff that most people would use a different language for - I just find that for system admin work that BASH is just at the right level of abstraction for me and is ubiquitous.

1718627440 10mo ago

On my computer touch "$(echo -en 'a\nb')" find . -type f -name '*.mp3' -exec bash -c "echo '{}'; ls '{}'" ';' works just fine, but maybe it doesn't work everywhere. If you don't like how the multiple commands look like, you can always write it like this: find . -type f -name '*.mp3' -exec bash -c " echo '{}' ls '{}' " ';'

ndsipa_pomu 10mo ago
Yep, you can chain multiple commands with find's "-exec", but I'm not a fan of it myself. I suspect setting variables in the current process is trickier though. (Very minor nitpick, it should be 'a\nb.mp3' to be included, but that does work fine) Incidentally, ShellCheck isn't happy with that although I don't follow their reasoning: find . -type f -name '*.mp3' -exec bash -c " ^-- SC2156 (warning): Injecting filenames is fragile and insecure. Use parameters. https://www.shellcheck.net/wiki/SC2156 https://www.shellcheck.net/wiki/SC2156
- 1718627440 10mo ago
  > although I don't follow their reasoning I think it is sound. Imagine what happens when the filename contains: ' && shutdown now && '.mp3
  - ndsipa_pomu 10mo ago
    Of course that makes sense now. Anyhow here's an example of how I would use the while loop and process substitution in a BASH script: declare -i file_count=0 while IFS= LC_ALL=C read -r -d '' file; do file_count+=1 printf "file: %s\n" "${file}" done < <(find . -type f -name '*.mp3' -print0) printf "Processed %d files\n" "${file_count}" I think that'd be tricky to do using just a find/-exec command.
    - 1718627440 10mo ago
      I see, but now you are essentially operating on multiple files, at once, so the serialization makes some sense. Although for just this, I wouldn't write the operation in bash at all: find . -type f -name '*.mp3' | wc -l Honestly I don't really view the shell / filesystem interface as a security boundary. I use the shell mainly for (automation of) interactive use, so any screwup due to e.g. quoting issues is my own fault, maybe even of using stupid filenames. Shell is a great language to connect streams of different programs into each other, not so much for doing any work. If I do that, I would reach for C.
      - ndsipa_pomu 10mo ago
        The serialisation is just to work around the fact that filenames can have any character except for \0 which is why the "-print0" is used. It doesn't by itself allow for concurrent processing. You're right about just using "wc -l", but I was just trying to demonstrate how you can set variables. A real use would be doing more than just counting files as your example would likely be quicker (assuming that calling an external programme is quicker than running a naive loop in BASH). I am guilty of using BASH for stuff that most people would use a different language for - I just find that for system admin work that BASH is just at the right level of abstraction for me and is ubiquitous.