Re: slpath v0.001

From: Stephane CHAZELAS (this.address_at_is.invalid)
Date: 11/11/05 

Date: Fri, 11 Nov 2005 08:39:43 +0000

2005-11-10, 14:39(-05), John Kelly:
> On 10 Nov 2005 18:16:01 GMT, Stephane Chazelas
> <stephane_chazelas@yahoo.fr> wrote:
>
>
>>> *//////) _SLPATH=${_SLPATH%//////}; continue ;;
>
>
>>Or simply:
>>
>>*/) _SLPATH=${_SLPATH%"${SLPATH##*[!/]}"};;
>
>
> That's good, Stephane
>
> But since the subexpression always evaluates a string of trailing
> slashes, why do you have quotes enclosing the subexpression?.

For the same reason as for instance in perl, I write
print "foo" instead of print foo, not because there's a risk
that foo may once become a valid function or keyword, but
because print "foo" says my intention.

Without the quotes above, that would mean my intention was to
consider ${SLPATH##...} as a pattern. And that's not true. My
intention was to consider it as a simple string, even if, as you
pointed out, in that very case, that would be the same given
that the pattern would consist only in normal characters.

> Seems like the quotes should enclose the entire RHS of the variable
> assignment.
>
> Strangely though, I tested it without any quotes at all on the RHS,
> and cannot produce a failure even when there are embedded blanks in
> the names.
>
> I've gotten in the habit of quoting the RHS of a variable assignment
> for fear there could be word splitting on the RHS.
>

Your assigning something to a scalar variable, not to an array,
how could word splitting ever occur, there. Word splitting (and
filename generation) can only take place where parameter
expansion can resolve to several words (in list contexts, I
would say), such as in

cmd -- $files
for f in $files
files=($files)

In

(( $var ))
[[ $var ]]
case $var in
foo=$var

They are not necessary, because they are not list contexts.

In

cmd > $files

YMMV.

> But after testing this, I see that RHS quoting is only necessary when
> there is more than one variable (or other text), separated by spaces
> on the RHS. If that is true, then it must also be true that word
> splitting is performed before parameter expansion. I once had a bash
> book with that flowchart in it, but gave it away.
>
> Can anyone verify whether that sequence is correct, or not?

I don't understand that sentence. Word splitting (and filename
generation) is part of the expansion process. A variable may
expand into several words (actually file names) where
applicable, when not quoted.

Note that

foo=$var

doesn't work correctly with some old versions of zsh when the
globsubst option is enabled (i.e. when zsh emulates the other
Bourne like shell bug such as in sh emulation).

foo="$var"

fixes it.

But then, there's a bug in some old versions of bash in:

foo="${var#"$bar"}" 

-- 
Stéphane

Relevant Pages

  • Re: find errors "paths must precede expression: %d" ..., "missing argument to `-exec"
    ... Unless you WANT the word splitting. ... There exist circumstances under which quotes are necessary, ... think of a single circumstance under which braces break anything. ... I tend to view always-bracing shell variables as like always-bracing the ...
    (comp.unix.shell)
  • Re: shell quoting around script output
    ... behaves like this (double quotes around $(..) replaced by single quotes): ... which is prevented from word splitting or globs because it ... That the script that is output from $ ... $ for x in $(echo two words); do echo $x; done ...
    (comp.unix.shell)
  • Re: shell quoting around script output
    ... behaves like this (double quotes around $(..) replaced by single quotes): ... which is prevented from word splitting or globs because it ... causing it to be passed to awk as one argument. ... That the script that is output from $ ...
    (comp.unix.shell)
  • Re: differecnce between ${IFS} and "${IFS}"
    ... when using double quotes, word splitting does not happen. ... single space (they are actually replaced with the first character of $IFS, ... The shell treats each character of IFS as a delimiter, ...
    (comp.unix.shell)
  • Re: Eval variable syntax problem
    ... for foo in $lst; do ... # just to make it clear that it is word splitting that is ... "$foo" as there's no point asking the shell to split the content ...
    (comp.unix.shell)