Small trick for processing file names with spaces in Shell

In Shell, trick, who processes file names with spaces, finally downloaded the books in the post of the 16 Python books on the forum, I found that there were several titles with a prefix in the format of [author #123], and there were several documents with unknown operation permissions, so I decided... in Shell, trick, who processes file names with spaces, finally downloaded the books in the post of the 16 Python books on the forum, I found that there were several titles in front of which there was a [author #123] Author in automatic order ):#! /Bin/sh # Description: # if there is a file with name: [1-9]. xxx, it will be changed into 0 [1-9]. xxx for var in 'Ls'; do new = 'echo $ var | sed "s/^ \ ([1-9] \) \. /0 \ 1 \. /g "'if [$ var! = $ New]; before then mv $ var $ new fidone, this script runs normally. I plan to directly change the regular expression after sed, after the result is changed, a bunch of error messages are flushed out, saying "Can't stat file" xxx ", while the xxx file is only a section of the correct file name. I woke up with a space in the file name, the list returned by ls is incorrectly recognized by the for clause? Playing tricks? Secondary recruitment? Too many ?? Stranger .? Press the Unix Haters' Handbook to batch the problem of space in the file name. After some time google finally found the answer, a clever method, just changed row 6 to: ls * | while read var. shell can be understood, but it is not easy to think about it. So I rushed to rewrite the script and the result was as follows :#! /Bin/sh ls * | while read vardo if [-x "$ var"]; then chmod a-x "$ var" fi new = 'echo "$ var" | sed "s/^ \ [reader [#0-9] * \] \ (. * \) $/\ 1/g "'if [$ var! = $ New]; then mv "$ var" "$ new" fidone note that when calling the variable here, it must be written as "$ var ", if you shake your hand and write it as $ var, there will be a bunch of seemingly inexplicable error messages. The above script runs normally. The entire processing process encountered many strange faults, so that in fact, the time spent was much longer than manual modification. However, programmers who love programming know that such a toss is really a kind of entertainment, it is much more fun than modifying file names one by one.