Very Computer

Trouble is, this limits what the script can do. I found
this out by trying to test the current contents of the
PATH with expr. Without the execute bits set, it fails,
differently on different systems, but fails nonetheless.

This holds true whether it's sourced from the command
line or another script (which does have its execute bits
set).

I'm looking for an explanation that will let me say,
"set the darn bits!" or a workaround (a way to reliably
detect whether it's been executed or sourced - I know
I can do this if it's sourced from a script, but what
about the command line?).

Any suggestions? -Wm

I have not experienced any such problems.

--
    Chris F.A. Johnson                        http://cfaj.freeshell.org
    ===================================================================
    My code (if any) in this post is copyright 2001, Chris F.A. Johnson
    and may be copied under the terms of the GNU General Public License

Quote:> OK, I know that sounds kind of obvious, but here's the
> deal. We have some environment setting scripts that must
> be sourced into the current shell (there's a bourne and
> C shell version). We want to discourage people from trying
> to execute them and force them to source 'em, hence the
> execute bits have traditionally been turned off.

> Trouble is, this limits what the script can do. I found
> this out by trying to test the current contents of the
> PATH with expr. Without the execute bits set, it fails,
> differently on different systems, but fails nonetheless.

The original line contained this:
    `expr ":$PATH:" : ".*:$TARGET/bin:"`
For whatever reason, that caused problems based on the
execute bit. This one works whatever the bit is set to:
    `expr ":\$PATH:" : ".*:$TARGET/bin:"`

I still don't know why the executable bit exposed the
problem, but it did. -Wm