Re: Compiling Postgresql 8.0.3 on Solaris 10

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Aly Dharshi <aly(dot)dharshi(at)telus(dot)net> writes:
> > alias ls='colorls -al'
> > alias rm='rm -i'
>
> > I don't see any aliases that are going to break the compile process.
>
> I beg to differ --- I think the ones quoted above match your symptoms
> pretty well. So the question is: why are they getting used in a
> noninteractive script?
>
> My bet is that you've defined these aliases in the wrong place.
> I'm not sure about Solaris, but on Linux one conventionally puts
> aliases like these in ~/.bashrc, which I think is not read by
> plain sh. If you've put them in ~/.profile they are very likely
> to break shell scripts.

This doesn't really seem like a sufficient explanation. Putting such things in
.profile is pretty standard too. .profile should only ever be run by login
shells -- not even all interactive shells -- in the first place.

Moreover, bash at least will not expand aliases for non-interactive shells:

Aliases are not expanded when the shell is not interactive, unless the
expand_aliases shell option is set using shopt (see the description of
shopt under SHELL BUILTIN COMMANDS below).

So either this user has this expand_aliases shell option set. Or he's using
Solaris's /bin/sh which is a non-POSIX ksh derivative and that shell is both
1) running .profile for a non-interactive shell (which is utterly bogus) and
2) expanding aliases for a non-interactive shell.

I'm skeptical that it's doing that and if it is then it would be causing
problems for virtually any /bin/sh script. *Many* users would have commands in
.profile that are intended to only run once at login time.

I suspect something stranger going on. Perhaps /bin/sh on this machine is bash
and this user has some environment variable set that enables this non-standard
behaviour?

--
greg