Re: Non-portable shell code in pg_upgrade tap tests

Moin,

On Sat, July 21, 2018 12:47 pm, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
>> "Tels" <nospam-pg-abuse(at)bloodgate(dot)com> writes:
>>> + *) if [ `find ${PGDATA} -type f ! -perm 640 | wc -l` -ne 0 ]; then
>>
>>> Shouldn't ${PGDATA} in the above as argument to find be quoted,
>>> otherwise
>>> the shell would get confused if it contains spaces or other special
>>> characters?
>>
>> Hmm. Yeah, probably. I don't think this script is meant to be run with
>> arbitrary values of PGDATA, but most of the other uses are quoted, so
>> for consistency's sake this should be too.
>
> PGDATA is built from `pwd`, so it breaks if the build directory has a
> space in it. Because it's testing for the absence of files, it doesn't
> actually break the test, but would fail to detect the bugs it's trying
> to.

Thanx for the fix. But perhaps I should have been a bit more specific in
my first message, spaces are not the only character this can break at.

Looking at your new patch, I notice you used "" for quoting, not ''. (Not
sure which variant Tom used when pushing a patch).

I'm not a shell expert, but I think '' are safer, as "" still has some
interpolation from the shell (at least on the systems I use regulary):

te(at)pc:~$ mkdir 'test$test'
te(at)pc:~$ touch 'test$test/test'
te(at)pc:~$ find 'test$test/test' -type f
test$test/test
te(at)pc:~$ find "test$test/test" -type f
find: ‘test/test’: No such file or directory

So I've grown the habit to always use '' instead of "". Not sure if this
is specific to bash vs. sh or PC vs Mac, tho.

Best wishes,

Tels