Tom Lane <tgl@sss.pgh.pa.us> writes:
> Aly Dharshi <aly.dharshi@telus.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