SCO shell scripts

13 views
Skip to first unread message

patr...@dopra.securicor.co.uk

unread,
Jan 12, 1999, 3:00:00 AM1/12/99
to
We have an exported function 'make' which has been defined in the $ENV file
and when we invoke ksh scripts the previously exported function has been
undefined causing make within $PATH to be used rather than the exported
function make. Thanks for any help! Patrick Saunders

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own

John DuBois

unread,
Jan 13, 1999, 3:00:00 AM1/13/99
to
In article <77fata$jmc$1...@nnrp1.dejanews.com>,

<patr...@dopra.securicor.co.uk> wrote:
>We have an exported function 'make' which has been defined in the $ENV file
>and when we invoke ksh scripts the previously exported function has been
>undefined causing make within $PATH to be used rather than the exported
>function make. Thanks for any help! Patrick Saunders

Exported functions are propogated across fork but not exec.
This means that your exported functions will not appear in #!/bin/ksh
scripts, because such scripts are recognized as executable files by the kernel
and so are executed by a separate instance of ksh, rather than being executed
by a forked instance of the ksh in which the function was defined (and it is
this that makes exported functions possible). So if you have an exported
function 'foo', a shell script that consists solely of this line will work:

foo

but a shell script that consists of these two lines will not:

#!/bin/ksh
foo

The term "exported functions" is somewhat deceptive in that it sounds as though
it would operate similarly to "exported variables" (which are propogated by
both fork and exec), but they are implemented by entirely different means.
I haven't found exported functions to be terribly useful.

John
--
John DuBois spc...@armory.com. KC6QKZ http://www.armory.com./~spcecdt/

Tony Lawrence

unread,
Jan 13, 1999, 3:00:00 AM1/13/99
to
John DuBois wrote:
>
> In article <77fata$jmc$1...@nnrp1.dejanews.com>,
> <patr...@dopra.securicor.co.uk> wrote:
> >We have an exported function 'make' which has been defined in the $ENV file
> >and when we invoke ksh scripts the previously exported function has been
> >undefined causing make within $PATH to be used rather than the exported
> >function make. Thanks for any help! Patrick Saunders
>
> Exported functions are propogated across fork but not exec.
> This means that your exported functions will not appear in #!/bin/ksh
> scripts, because such scripts are recognized as executable files by the kernel
> and so are executed by a separate instance of ksh, rather than being executed
> by a forked instance of the ksh in which the function was defined (and it is
> this that makes exported functions possible).


I think it's a bit more confusing than this.

If you define foo within your .kshrc (or whatever $ENV points at),
the function is available at the command line to any invocation of ksh.

If you then mark it for export (typeset -xf foo), it becomes available
to scripts, but it STILL not available to scripts beginning with
#!/bin/ksh.

It is THAT part that is the source of the mind-boggling confusion: you
can obviously see that as new ksh has the function, yet it won't work in
a script that begins with #!/bin/ksh . The script does not have the
function, as can easily be seen by putting "functions" into such a
script: functions listed in /.kshrc will not be there.

However- if you both define AND mark the function for export within the
$ENV file, it then IS available to those scripts, and I assumed that's
what the original poster had done:

# kshrc
function foo
{
echo "Hi there!"
}

typeset -xf foo

Perhaps he is redefining foo and expecting that to transfer to the next
ksh? Of course it wouldn't, you'd get the definition from .kshrc,
though you could arrange for that easily by writing a file containing
the function definition and the typeset, and pointing ENV at that before
invoking the script.

At any rate, he should be able to get the functionality he wants.

This stuff can drive you to Perl-and it should :-)
--
Tony Lawrence (to...@aplawrence.com)
SCO ACE
SCO articles, help, book reviews: http://www.aplawrence.com

Reply all
Reply to author
Forward
0 new messages