Working with Oracle 9.2 on Solaris 5.9, I ran into some questions about
setenv (Disclaimer: I'm a DBA, not an SA).

Product has a tool that produces a set to .sh an .sql scripts which are
used to create a new database. The produced script that drives the
process (call it mysid.sh). To demonstrate and reproduce my problem, I
have reduced the script to this:

#!/bin/sh
-set x
setenv ORACLE_SID mysid


When running the script, the setenv line returns "setenv: not found"

So I do a find on setenv, locate the directory it is in and add it to
my path. Then the command returns:

$> edstest.sh
+ setenv ORACLE_SID mysid
cp: cannot create /usr/estevens/pref/.environ: No such file or
directory
cp: cannot create /usr/estevens/pref/.environ: No such file or
directory
$>

ok, there is no directory /usr/estevens/pref but why is setenv trying
to write a file at all? And why would it try to write that file to a
directory that is not guaranteed to be there? In the above example, my
$HOME directory is /usr/estevens, but it cant' be assumed that there
will necessarily be a $HOME/pref.

Enquiring minds want to know. For my purposes I can get around this my
inserting

ORACLE_SID=mysid
export ORACLE_SID

but would like to further my knowledge of Unix.

(Another anomoly, which I need to pose to the vendor (Oracle) is that
it appears from the man page that setenv is for csh, but not sh, yet
they gen a script which specifically runs sh and calls setenv.)

Thanks.

EdStevens schrieb:


> #!/bin/sh
> -set x
> setenv ORACLE_SID mysid
>
> When running the script, the setenv line returns "setenv: not found"

setenv is a C-Shell builtin, not a Bourne Shell builtin. See "man sh"
and "man csh".
The corresponding sh command is "export". If you use csh as your login
shell, be aware of the (very) different syntax (you told your script
to use #!/bin/sh !)

> ORACLE_SID=mysid
> export ORACLE_SID

Note that "export" and "setenv" do not really setenv or export from a
sub shell
(script). If you use csh, either put setenv commands to .login or
..cshrc
and use "alias" if you want to set environment variables interactively

Put in .login

alias ods "setenv ORACLE_SID=mysid"

The you can use the "command" ods to set the environment.

If you put environment variables in a C-Shell script, you must (!)
source it:

#!/bin/csh
# -- script ods.csh
setenv SID 1
setenv X 2
The you must source this:

source ods.csh

You can also define an alias

alias ods="source ods.csh"

By the way: do not use C-Shell for serious scripts (using it as a login
shell is ok)

http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

Hubble.

"EdStevens" <quetico_man@yahoo.com> writes:

> Working with Oracle 9.2 on Solaris 5.9, I ran into some questions about
> setenv (Disclaimer: I'm a DBA, not an SA).

> #!/bin/sh
> -set x
> setenv ORACLE_SID mysid

setenv is a C shell program. The equivalent command for you using the
Bourne/POSIX shell is

ORACLE_SID=mysid
export ORACLE_SID

or more simply

export ORACLE_SID=mysid

--
Sending unsolicited commercial e-mail to this account incurs a fee of
$500 per message, and acknowledges the legality of this contract.

"EdStevens" <quetico_man@yahoo.com> writes:

> Working with Oracle 9.2 on Solaris 5.9, I ran into some questions about
> setenv (Disclaimer: I'm a DBA, not an SA).

> #!/bin/sh
> -set x
> setenv ORACLE_SID mysid

setenv is a C shell program. The equivalent command for you using the
Bourne/POSIX shell is

ORACLE_SID=mysid
export ORACLE_SID

or more simply

export ORACLE_SID=mysid

--
Sending unsolicited commercial e-mail to this account incurs a fee of
$500 per message, and acknowledges the legality of this contract.

On 27 Oct 2006 06:15:38 -0700, EdStevens
<quetico_man@yahoo.com> wrote:
> Working with Oracle 9.2 on Solaris 5.9, I ran into some questions about
> setenv (Disclaimer: I'm a DBA, not an SA).
>
> Product has a tool that produces a set to .sh an .sql scripts which are
> used to create a new database. The produced script that drives the
> process (call it mysid.sh). To demonstrate and reproduce my problem, I
> have reduced the script to this:
>
> #!/bin/sh
> -set x
> setenv ORACLE_SID mysid
>
>
> When running the script, the setenv line returns "setenv: not found"
>
setenv is a csh command. The sh equivalent is
export ORACLE_SID; ORACLE_SID=mysid
In some shells this can be written as one command
export ORACLE_SID=mysid

>
> ok, there is no directory /usr/estevens/pref but why is setenv trying
> to write a file at all? And why would it try to write that file to a
> directory that is not guaranteed to be there? In the above example, my
> $HOME directory is /usr/estevens, but it cant' be assumed that there
> will necessarily be a $HOME/pref.
>
I don't know what this setenv does, but it should have a man page.
Try "apropos setenv" to see if there is more than one setenv man page.


> Enquiring minds want to know. For my purposes I can get around this my
> inserting
>
> ORACLE_SID=mysid
> export ORACLE_SID
>
> but would like to further my knowledge of Unix.
>
> (Another anomoly, which I need to pose to the vendor (Oracle) is that
> it appears from the man page that setenv is for csh, but not sh, yet
> they gen a script which specifically runs sh and calls setenv.)
>
I'd like to know how they explain that.


--
I'll never get off this planet.
-- Luke Skywalker

EdStevens wrote:
> So I do a find on setenv, locate the directory it is in and add it to
> my path.

It's not possible for environment variable setting to be implemented as
an external command. Such commands run in their own process. In Unix, a
child process cannot manipulate the environment of the parent process.

There do exist programs which set environment variables with the
of eval.

They /print/ output such as

export FOO=BAR

and this printed output is evaluated using the shell. E.g:

eval $(echo "FOO=BAR")

echo prints "FOO=BAR" on standard output. The $(...) command
interpolates that output into the eval command line, and eval evaluates
it as a shell expression, causing BAR to be assigned to FOO.

> ok, there is no directory /usr/estevens/pref but why is setenv trying
> to write a file at all?

What else can it do? Being an external command, it cannot write to your
environment variables.

Why don't you ask whoever installed this thing? It was not even in your
regular path; you located it by running find. Maybe it was written by
some local user as a shortcut for permanently recording environment
variables in his profile.

setenv isn't a standard command that would be found in /bin or /usr/bin
on a Unix system.

> And why would it try to write that file to a
> directory that is not guaranteed to be there?

Maybe because there are some installation steps that have to be taken
when using that program?

The users of that program obviously do have that directory, right?

You have not read one shred of documentation about it; it's just
something you found lying in some path somewhere. Have you even checked
whether it's a script or a binary executable?

What if someone wrote something called "setenv" which invokes "rm -rf
*"? You would just blindly run it, right?

> (Another anomoly, which I need to pose to the vendor (Oracle) is that
> it appears from the man page that setenv is for csh, but not sh, yet
> they gen a script which specifically runs sh and calls setenv.)

But don't worry, they are getting into the Linux distribution business,
which will teach them a thing or two, even if it's by way of
acquisition.

Kaz Kylheku wrote:
> EdStevens wrote:
> > So I do a find on setenv, locate the directory it is in and add it to
> > my path.
>
> It's not possible for environment variable setting to be implemented as
> an external command. Such commands run in their own process. In Unix, a
> child process cannot manipulate the environment of the parent process.
>
> There do exist programs which set environment variables with the
> of eval.
>
> They /print/ output such as
>
> export FOO=BAR
>
> and this printed output is evaluated using the shell. E.g:
>
> eval $(echo "FOO=BAR")
>
> echo prints "FOO=BAR" on standard output. The $(...) command
> interpolates that output into the eval command line, and eval evaluates
> it as a shell expression, causing BAR to be assigned to FOO.
>
> > ok, there is no directory /usr/estevens/pref but why is setenv trying
> > to write a file at all?
>
> What else can it do? Being an external command, it cannot write to your
> environment variables.
>
> Why don't you ask whoever installed this thing? It was not even in your
> regular path; you located it by running find. Maybe it was written by
> some local user as a shortcut for permanently recording environment
> variables in his profile.
>
> setenv isn't a standard command that would be found in /bin or /usr/bin
> on a Unix system.
>
> > And why would it try to write that file to a
> > directory that is not guaranteed to be there?
>
> Maybe because there are some installation steps that have to be taken
> when using that program?

Possibly

>
> The users of that program obviously do have that directory, right?
>

Not so obviously


> You have not read one shred of documentation about it;

You assume much ....

>it's just
> something you found lying in some path somewhere.

No. It was something found in a script generated by a major, trusted
vendor. And from the context in which it was found, it's intended
function was rather obvious.

Have you even checked
>> whether it's a script or a binary executable?
>

Yes, I had. Sorry you just blindly assume that I hadn't.

> What if someone wrote something called "setenv" which invokes "rm -rf
> *"? You would just blindly run it, right?

What if someone wrote and installed something called "ls" which invokes
"rm -rf"?

>
> > (Another anomoly, which I need to pose to the vendor (Oracle) is that
> > it appears from the man page that setenv is for csh, but not sh, yet
> > they gen a script which specifically runs sh and calls setenv.)
>
> But don't worry, they are getting into the Linux distribution business,
> which will teach them a thing or two, even if it's by way of
> acquisition.

Well, it's not as if they are a bunch of bumbling boobs. The man page
does document that 'setenv' is native to some shells, so I can see
where it would be easy enough for the guy who wrote the script genning
routing to miss that it isn't universal.

EdStevens wrote:
> What if someone wrote and installed something called "ls" which invokes
> "rm -rf"?

The answer to that is that you carefully select what goes into your
PATH. That is to say, only absolute paths to trusted locations.