I have scripts that use the unix here document mechanism to do a simple
query using isql. i. e.

isql finance <<EOF
unload to "/$FASRPTDIR/category.csv" delimiter ","
select catcode,sum(initcost) InitCost,sum(accdep) AccDep
from assets
where catcode matches $sel1
group by catcode
order by catcode;

select catcode,sum(initcost) InitCost,sum(accdep) AccDep
from assets
where catcode matches $sel1
group by catcode
order by catcode;

select sum(initcost) Tot_Init_Cost,sum(accdep) Tot_Acc_Dep
from assets
where catcode matches $sel1
EOF

And if a regular user runs this script it will not create the temp
files it needs in the /tmp directory. I get error messages that say the
here document is running the bourne shell sh when all our users have
the Korn shell set in the passwd entry. On our Tru64 v5.1b unix system
users running sh can not create files in temp.
Anybody seem this?

Tom Wallin

Put

#!/bin/ksh

as the first line of your shell program.

ccwallin wrote:

>I have scripts that use the unix here document mechanism to do a simple
>query using isql. i. e.
>
>isql finance <<EOF
>unload to "/$FASRPTDIR/category.csv" delimiter ","
>select catcode,sum(initcost) InitCost,sum(accdep) AccDep
>from assets
>where catcode matches $sel1
>group by catcode
>order by catcode;
>
>select catcode,sum(initcost) InitCost,sum(accdep) AccDep
>from assets
>where catcode matches $sel1
>group by catcode
>order by catcode;
>
>select sum(initcost) Tot_Init_Cost,sum(accdep) Tot_Acc_Dep
>from assets
>where catcode matches $sel1
>EOF
>
>And if a regular user runs this script it will not create the temp
>files it needs in the /tmp directory. I get error messages that say the
>here document is running the bourne shell sh when all our users have
>the Korn shell set in the passwd entry. On our Tru64 v5.1b unix system
>users running sh can not create files in temp.
>Anybody seem this?
>
>Tom Wallin
>
>
>

I have the shebang(#!/bin/ksh) in every script. It doesn't seem to
matter. The here document is shelling out of my main script and using
the bourne shell "sh" which doesn't allow my users to open a document
in /tmp.
By-the-way /tmp's user:group is root:system with access of 1777, or
-rwxrwxrwt

Tom Wallin

Have you tried having users execute with "dot;" e.g.,

. progname

If that works then you need to address the program itself (there is no
reason that a shell program cannot write to /tmp); "dot space progname"
instructs the shell to execute the program in the current environment;
i.e., do not create a child process. You may need to insert environment
variables for users to be able to do what your program is attempting?

ccwallin wrote:

>I have the shebang(#!/bin/ksh) in every script. It doesn't seem to
>matter. The here document is shelling out of my main script and using
>the bourne shell "sh" which doesn't allow my users to open a document
>in /tmp.
>By-the-way /tmp's user:group is root:system with access of 1777, or
>-rwxrwxrwt
>
>Tom Wallin
>
>
>

Oh, yeah, try

chmod 777 /tmp

and see what happens (leave off the 1).

ccwallin wrote:

>I have the shebang(#!/bin/ksh) in every script. It doesn't seem to
>matter. The here document is shelling out of my main script and using
>the bourne shell "sh" which doesn't allow my users to open a document
>in /tmp.
>By-the-way /tmp's user:group is root:system with access of 1777, or
>-rwxrwxrwt
>
>Tom Wallin
>
>
>

ccwallin wrote:
> I have the shebang(#!/bin/ksh) in every script. It doesn't seem to
> matter. The here document is shelling out of my main script and using
> the bourne shell "sh" which doesn't allow my users to open a document
> in /tmp.
> By-the-way /tmp's user:group is root:system with access of 1777, or
> -rwxrwxrwt
>
> Tom Wallin
>
Set the SHELL variable in the script to /usr/bin/ksh and export it before
running dbaccess. This is likely an AIX problem, not Informix. I know that
the ksh on AIX is not strictly conformant and is not derived from the same
source as most System V based versions (ie Solaris, HPUX 10+, DGUX, etc.).

Art S. Kagel

Thomas Ronayne wrote:
> Oh, yeah, try
>
> chmod 777 /tmp
>
> and see what happens (leave off the 1).

And put the 1 back again as soon as possible. It prevents Fred
fromremoving Bil's files under /tmp, and vice versa.

> ccwallin wrote:
>
>> I have the shebang(#!/bin/ksh) in every script. It doesn't seem to
>> matter. The here document is shelling out of my main script and using
>> the bourne shell "sh" which doesn't allow my users to open a document
>> in /tmp.
>> By-the-way /tmp's user:group is root:system with access of 1777, or
>> -rwxrwxrwt


And originally, ccwallin wrote:
> I have scripts that use the unix here document mechanism to do a simple
> query using isql. i. e.
>
> isql finance <<EOF
> unload to "/$FASRPTDIR/category.csv" delimiter ","
> select catcode,sum(initcost) InitCost,sum(accdep) AccDep
> from assets
> where catcode matches $sel1
> group by catcode
> order by catcode;
>
> select catcode,sum(initcost) InitCost,sum(accdep) AccDep
> from assets
> where catcode matches $sel1
> group by catcode
> order by catcode;
>
> select sum(initcost) Tot_Init_Cost,sum(accdep) Tot_Acc_Dep
> from assets
> where catcode matches $sel1
> EOF
>
> And if a regular user runs this script it will not create the temp
> files it needs in the /tmp directory. I get error messages that say the
> here document is running the bourne shell sh when all our users have
> the Korn shell set in the passwd entry. On our Tru64 v5.1b unix system
> users running sh can not create files in temp.


It is not clear to me how you are running these scripts. I find it
hard to believe that /bin/sh cannot create files in /tmp -- how do you
configure your system to achieve that effect? If you are running them
from cron, then they are always run by /bin/sh - and you either have
to avoid the Korn shell syntax (not that any was visible), or you
arrange for cron to run "/bin/ksh /the/real/script". You can probably
use that trick for most of the other methods of running the script.

Are there some weird permissions on /bin/sh? For example, if it was
SUID nobody and SGID noone, you might get some odd permission errors.
Also - and this may be what Thomas was driving at - your script
seems to embed a single, constant hard-coded file name for the unload
file. Once UserA (eg root) creates the file, it may be that other
users cannot write to that file. Also, if FASRPTDIR is not set, you
are trying to write in the root directory -- you had jolly well better
not be able to write there as a normal user. Don't forget, cron
doesn't set anything more than the barest minimum environment for you
(the 'at' command does record the environment for you). Similarly,
you don't show how $sell is set - you have to be rather careful with
the quotes when you set it.


--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Thanks for the replies. I found out that I had an acl(Access Control
List) setting on the /tmp directory for the group that was using
programs creating files in /tmp. I removed the nasty acl from /tmp and
all was well. By-the-way I put the permissions back to 1777.

Tom Wallin