Re: [tlug] Rsync exclusion question

[Doug McLean <dmclean635@example.com>]

Agreed.  I may be interpreting the situation wrong, but I can say for
sure that since switching that one line in my script to using
single-quotes, problems cleared up immediately.  No more sync errors
in the last 72 hours.

Point is: keep it simple, Doug^H^H^HStupid  :)

On Fri, Jun 12, 2009 at 10:09 AM, Josh Glover<jmglov@example.com> wrote:
> 2009/6/12 John Fremlin <john@example.com>:
>
>> Josh Glover wrote:
>>
>>> I think the Best Practise to always use non-interpolating quotes
>>> unless you know you need interpolation is the way to go. That way,
>>> you don't need to understand the interpolation rules of your
>>> programming language all the way down to the metal.
>>
>> I don't know how you can include not understanding the language you are
>> using in a Best Practice ;-)
>
> I hope you know what I meant. Interpolation in the shell can quickly
> devolve from "simple rules" to a recursively nastier situation, when
> you have scripts calling programs calling scripts.
>
> Of course one *should* understand the basics of interpolation in any
> language one uses. But the Best Practice is about avoiding
> interpolation altogether unless you *know* you want it in a string,
> and then understanding the rules as they apply to that string.
>
> I've seen old Unix hands tripped up by shell interpolation many times.
>
>> (Both over- and under- quoting cause problems.)
>
> This statement is significantly general enough to be true. :)
>
>> I don't understand why the problem was allegedly fixed by changing
>> between " and ' quotes; perhaps we haven't heard the full story.
>
> Me neither, but I think it has to do with how Doug is invoking his
> script. I'll walk over to his desk later as time allows and see if I
> can understand what is happened.
>
>>  From the Bash manpage
> [...]
>>>        The  special  parameters  *  and  @ have special meaning when in double
>>>        quotes (see PARAMETERS below).
>
> PARAMETERS
> [...]
>   Positional Parameters
>       A positional parameter is a parameter denoted by one  or  more
> digits,  other
>       than  the single digit 0.  Positional parameters are assigned
> from the shell's
>       arguments when it is invoked, and may be reassigned using the
> set builtin com‐
>       mand.   Positional  parameters  may  not be assigned to with
> assignment state‐
>       ments.  The positional parameters are temporarily replaced when
> a shell  func‐
>       tion is executed (see FUNCTIONS below).
>
>       When  a  positional  parameter  consisting  of  more  than  a
> single digit is
>       expanded, it must be enclosed in braces (see EXPANSION below).
>
>   Special Parameters
>       The shell treats several parameters specially.  These
> parameters may  only  be
>       referenced; assignment to them is not allowed.
>       *      Expands  to  the  positional  parameters,  starting from
> one.  When the
>              expansion occurs within double quotes, it expands to a
> single word with
>              the value of each parameter separated by the first
> character of the IFS
>              special variable.  That is, "$*" is equivalent to
> "$1c$2c...", where  c
>              is  the  first  character  of the value of the IFS
> variable.  If IFS is
>              unset, the parameters are separated by spaces.  If  IFS
> is  null,  the
>              parameters are joined without intervening separators.
>
>
> But what Doug was doing shouldn't have triggered any magic with *, AFAICT.
>
> I'll leave it at, this: huh.
>
> --
> Cheers,
> Josh
>
> --
> To unsubscribe from this mailing list,
> please see the instructions at http://www.tlug.jp/list.html
>
> The TLUG mailing list is hosted by the award-winning Internet provider
> ASAHI Net.
> Visit ASAHI Net's English-language Web page: http://asahi-net.jp/en/



-- 
Doug McLean

Blog: http://nihonshukyo.wordpress.com/