Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ralf Fassel Newsgroups: comp.os.linux.misc Subject: Re: correct quoting for variables in bash scripts? Date: Tue, 18 Oct 2022 15:01:01 +0200 Lines: 42 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain X-Trace: individual.net GvLCPTIAVOnoVD4db03RiQ+oTuP5TsE9oYsDcKCQvQ14Al1rE= Cancel-Lock: sha1:t8akX4MIaE5ptUdkE+sWP1g5WiE= sha1:UBJaLOZNKBvpekU2KZOaEGAgF4E= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) Xref: csiph.com comp.os.linux.misc:35742 * Rich | Ralf Fassel wrote: | > | The two [[ ]] square bracket form of the test command is explicitly a | > | shell built-in, so it can recognize empty strings without help. | > | > Interesting, didn't know that difference: | > | > $ unset bar | > $ [[ $bar = x ]] && echo yes | > $ type [[ | > [[ is a shell keyword | > | > $ [ $bar = x ] && echo yes | > bash: [: =: unary operator expected | > $ type [ | > [ is a shell builtin | > | > Most probably the error thrown with "[" is to ensure compatibility with | > /usr/bin/test? > | The error thrown with "[" is because what "[" sees as its argv is "= x" | because the shell has already converted $bar into "" before "[" is | executed. I understand the problem for the case that there is a command to be called after variable substitution. But the original theory (first quotation above) why [[ did not throw an error was that "... ([[) is explicitly a shell built-in, so it can recognize empty strings without help." Since '[' is also flagged as a shell-builtin by bash itself ("type [ => shell builtin"), I wondered "can't it detect it then just the same?" There seems to be a difference between shell-keywords here and shell-builtins when it comes to the handling of empty variables. (Of course there is also /usr/bin/[ and /usr/bin/test (2 different programs on my Opensuse) but I suppose that these are not called when "[" is a shell-builtin.) R'