4 ms·

This would be a significantly better resource if it explained the underlying "why's" inline. In it's current form, it comes off as cargo culting / magic spell

This would be a significantly better resource if it explained the underlying "why's" inline. In it's current form, it comes off as cargo culting / magic spell recital. For example, why "./*" rather than "*". Not helpful to understand the core principal and reality. Personally I don't tend to fuck about with "*" and instead use `find . -print0 | xargs -0 -n1'. Hasn't bitten me yet, across a few thousand shell scripts (!). Why should I prefer this magic incantation compared to my own battle-tested proven one? And this is why, IMHO, the explanations should be inline.

dwheeler 3y ago
Sadly you can't please everyone :-). The explanation is further down on the page. If I wrote in that recommended order, many other developers would complain "I don't want all the details, just tell me what to do". I wrote it this way because some developers just want the tl;dr version, that is, they "just want the answer"
- eviks 3y ago
  What do you think the chances are of removing the bag of bytes filename design bug in another decade?
  - dwheeler 3y ago
    Low. It wouldn't be hard to create an LSM for Linux to reject file creation of certain filenames, though. Then at least sone security-minded people could enable it. The POSIX folks are finally adding formal support for null terminated filenames in filename lists (which is what a lot of people are doing). So that's something.
semiquaver 3y ago
I found it to be quite thorough and lucid in its explanation of the rationales behind each suggestion, including the one you mentioned. Perhaps you are referring to the first section which is introduced as being a brief tl;dr: > Here’s a quick summary about how to do it correctly, for the impatient who “just want the answer”. The full document below that tldr includes for example this explanation of the reason for using ./* over *. Namely, flag injection: > This is important because almost all commands will interpret a string beginning with dash as an option, not as a filename, until they see something that does not begin with dash. Globs are expanded by the shell into a list of filenames, and dash is earlier in the sort order compared to before alphanumerics, so it is easy for attackers to make this happen.
unixhero 3y ago
Can you elaborate? Do you prefix the find line there eith a backtick? It looks robust, and I am interested in using this technique
- metadat 3y ago
  Here are a few examples of how I safely traverse filesystem contents in bash: find . -print0 | xargs -0 -n1 ./sub_script.sh find . -mindepth 1 -maxdepth 1 -name '*some*pattern' -print0 \ | xargs -0 -n1 -I{} /usr/bin/env bash -c \ 'printf "%s" "$*"' _ {}
tyingq 3y ago
Another approach is adding filenames after a "--" terminating option. Most, though not all, commands support it, like: ls -l -- -file-name-with-dash cat -- -file-name-with-dash
- Anthony-G 3y ago
  This is discussed in the featured article: https://dwheeler.com/essays/filenames-in-shell.html#dashdash https://dwheeler.com/essays/filenames-in-shell.html#dashdash As you point out, not all commands support this convention and the author feels that it would be hard to enforce this consistently among maintainers. I agree that it would be easier (for me) to remember to prefix globs with `./`.
  - tyingq 3y ago
    I'd argue it's not quite as terrible as the author suggests. Getopt(3), for example, uses it, so many programs pick it up from there. As do many popular getopt() variations for other languages...Golang's "flag" built-in, for example. So it's not universal, but it's also more common than you might imagine.

dwheeler 3y ago

Sadly you can't please everyone :-). The explanation is further down on the page. If I wrote in that recommended order, many other developers would complain "I don't want all the details, just tell me what to do". I wrote it this way because some developers just want the tl;dr version, that is, they "just want the answer"

eviks 3y ago
What do you think the chances are of removing the bag of bytes filename design bug in another decade?
- dwheeler 3y ago
  Low. It wouldn't be hard to create an LSM for Linux to reject file creation of certain filenames, though. Then at least sone security-minded people could enable it. The POSIX folks are finally adding formal support for null terminated filenames in filename lists (which is what a lot of people are doing). So that's something.

semiquaver 3y ago

I found it to be quite thorough and lucid in its explanation of the rationales behind each suggestion, including the one you mentioned. Perhaps you are referring to the first section which is introduced as being a brief tl;dr: > Here’s a quick summary about how to do it correctly, for the impatient who “just want the answer”. The full document below that tldr includes for example this explanation of the reason for using ./* over *. Namely, flag injection: > This is important because almost all commands will interpret a string beginning with dash as an option, not as a filename, until they see something that does not begin with dash. Globs are expanded by the shell into a list of filenames, and dash is earlier in the sort order compared to before alphanumerics, so it is easy for attackers to make this happen.

unixhero 3y ago

Can you elaborate? Do you prefix the find line there eith a backtick? It looks robust, and I am interested in using this technique

metadat 3y ago
Here are a few examples of how I safely traverse filesystem contents in bash: find . -print0 | xargs -0 -n1 ./sub_script.sh find . -mindepth 1 -maxdepth 1 -name '*some*pattern' -print0 \ | xargs -0 -n1 -I{} /usr/bin/env bash -c \ 'printf "%s" "$*"' _ {}

tyingq 3y ago

Another approach is adding filenames after a "--" terminating option. Most, though not all, commands support it, like: ls -l -- -file-name-with-dash cat -- -file-name-with-dash

Anthony-G 3y ago
This is discussed in the featured article: https://dwheeler.com/essays/filenames-in-shell.html#dashdash https://dwheeler.com/essays/filenames-in-shell.html#dashdash As you point out, not all commands support this convention and the author feels that it would be hard to enforce this consistently among maintainers. I agree that it would be easier (for me) to remember to prefix globs with `./`.
- tyingq 3y ago
  I'd argue it's not quite as terrible as the author suggests. Getopt(3), for example, uses it, so many programs pick it up from there. As do many popular getopt() variations for other languages...Golang's "flag" built-in, for example. So it's not universal, but it's also more common than you might imagine.