Re: Has a Debian developer ever unintentionally wiped out user files like Apple?
On Tue, Nov 13, 2001 at 04:11:04PM +1100, Brian May wrote:
> scrooge:~# A="A B"
> scrooge:~# cat $A
> cat: A: No such file or directory
> cat: B: No such file or directory
So you quote $A:
# A="A B"
# cat "$A"
> zsh, on the other hand, won't split the environment variable after it
> is substituted:
>
> 0. "cat $FILE"
> 2. "cat","$FILE" (split spaces)
> 1. "cat","A B" (substitute $FILE)
> 3. execlp("cat","A B",NULL) (execute)
>
> [501] [scrooge:bam] ~ >FILE="A B"
> [502] [scrooge:bam] ~ >cat $FILE
> cat: A B: No such file or directory
bash once defaulted to this behaviour on Debian a few years back too
> For why this might be important, consider the special $* variable...
This is why we have "$@"...
# for ARG in "$@"; do echo "$ARG"; done
Sometimes it is usefull to use "$*", but usually you'll want "$@".
I rarely ever use $*, personally I think it's bad coding practice
(kinda like using the goto command instead of a returning function).
> I never use spaces, partly because I don't trust my computer to cope
> <grin>, and partly because it is harder to type the filenames in at
> the command prompt.
Not harder for me, but then I make much use of [Tab] completion.
If an mp3 player or a doc (kwd, abw, etc.) editor doesn't understand
spaces in the names then it is a *serious* bug (also usually a very
simple one to fix, no matter what the application). Just like a good
programmer would make every effort to avoid infinite loops, (s)he
should also make every effort to fix all other bugs (s)he can think
of (especially the simple ones, such as allowing spaces in filenames).
-Ralph
Reply to: