Re: The shell and my scripts

[Doug McNutt]

At 12:49 +1000 8/1/05, John Horner wrote, in part:
>Output of this script with BBEDit's "Run In Terminal":
>-
>LOGNAME == myusername
>HOST == jh.my.work
>GROUP == myusername
>SHLVL == 2
>PWD == /private/tmp/501/Cleanup At Startup

Note the SHLVL which is incremented each time a shell invokes another shell.  
BBEdit has been known to make a copy of a "script" in /tmp/ which it passes to 
Terminal, or something else, for execution. There may be an added shebang line 
at the front. In fact there needs to be because your script is obviously perl. 
Note the PWD variable; look there for such a file.

In AppleScript after 10.3 the do shell script command always takes one to "sh". 
A shebang line at the start of the script to be "done" can point to bash or 
tcsh but the SHLVL will get increased as a daughter process is started up by sh.

Note that /usr/bin/sh is a copy of /usr/bin/bash and not, as is common in the 
Linux world, a hard link to bash. In compatibility mode - sh - bash does not do 
all of the fancy things it does when called as bash. A similar arrangement 
holds for csh and tcsh.

>PATH == /bin:/sbin:/usr/bin:/usr/sbin:/opt/local/bin

It is curious that PATH contains /opt/local/bin. I don't think OS neXt ever 
does that by itself. Darwin Ports and Fink might create such things but, of 
course, you or your employer can do it too. Are you involved with Apple's X11?

Do experiment with BBEdit worksheets. They will provide yet another option for 
running the script - just select and enter.
-- 

--> Life begins at ovulation. Ladies should endeavor to get every young life 
fertilized. <--

Re: The shell and my scripts

[John Horner]

Thank you all for your help. I think I get it now.

Just to clear up some confusion, when I'm working in BBEDit, I have 
two options to run the script:


Run -- which seems to run the script in bash.
Run In Terminal -- which runs in my chosen shell

and I also run scripts from cron, using the Cronnix utility

Here's a script:

for(keys(%ENV)){
print "$_ == $ENV{$_}\n";
}

Output of this script with BBEDit's "Run":
-
USER == myusername
PATH == /usr/bin:/bin:/usr/sbin:/sbin:/Users/myusername
__CF_USER_TEXT_ENCODING == 0x1F5:0:0
HOME == /Users/myusername
SECURITYSESSIONID == 23bac080
SHELL == /bin/bash
-

Output of this script with BBEDit's "Run In Terminal":
-
LOGNAME == myusername
HOST == jh.my.work
GROUP == myusername
SHLVL == 2
PATH == /bin:/sbin:/usr/bin:/usr/sbin:/opt/local/bin
HTTP_PROXY == http://my.work.proxy:8080/
USER == myusername
HOSTTYPE == powermac
VENDOR == apple
HOME == /Users/myusername
TERM_PROGRAM_VERSION == 100.1.8
TERM_PROGRAM == Apple_Terminal
SHELL == /bin/bash
SECURITYSESSIONID == 23bac080
__CF_USER_TEXT_ENCODING == 0x1F5:0:0
_ == /usr/bin/perl
TERM == xterm-color
MACHTYPE == powerpc
PWD == /private/tmp/501/Cleanup At Startup
OSTYPE == darwin
-

output when run as cron script:

-
SHLVL == 1
SHELL == /bin/sh
HOME == /Users/myusername
PATH == /usr/bin:/bin
_ == /usr/bin/perl
LOGNAME == myusername
PWD == /Users/myusername
USER == myusername
-

But Cronnix also has a "run now" option to test ones scripts, and 
when I use that, I get the same output as when it's run in the 
Terminal.


Can you see now why I was a little confused? Not to mention my Linux 
colleague's advice that the environment variable for my favourite 
shell would be some kind of global variable.


Off I go to investigate the $HOME/.MacOSX/environment.plist idea...

Re: The shell and my scripts

[Doug McNutt]

At 08:08 -0400 7/29/05, Sherm Pendley wrote:
>On Jul 28, 2005, at 11:10 PM, John Horner wrote:
>>What about a script run from BBEdit?
>
>BBEdit is a GUI app, and GUI apps don't use your login shell. To  define 
>environment variables to be used by GUI apps, have a look at  this Q&A from 
>Apple:

BBEdit also allows BBEdit worksheets which are a bit like Apple's MPW using 
ENTER to execute selected text as shell commands. If you are using one of those 
an instance of your selected shell, tcsh, is associated with each open 
worksheet. On opening a worksheet your ~/.tcshrc is "sourced" and you can set 
environment variables there. Your tcsh login script is NOT run.

It's probably better to create a $HOME/.MacOSX/environment.plist file but watch 
out for the public tcsh startup files in /etc/. As delivered they can overwrite 
your selections in the plist especially for $PATH. The plist is read only at 
login-to-Aqua time. If you change it you must logout and login again to see the 
changes.

Things are better now that it's UNIX underneath. Just ask Steve.
-- 

-->  Halloween  == Oct 31 == Dec 25 == Christmas  <--

Re: The shell and my scripts

[Sherm Pendley]

On Jul 28, 2005, at 11:10 PM, John Horner wrote:

and it seemed to work, but leaving aside the specifics of the  
scripts, how would Perl "know" that I use tcsh, not bash?


As others have already said, Perl knows there's an environment  
variable, but it neither knows nor cares how that variable got set.



Isn't that a preference of the Terminal app, not of me as a user?


Actually, no. It's a preference of the user. If you log in by other  
means - X11's xterm, or remotely through ssh, for instance - the same  
preference will be used.


A script run as a cron job, does it run using all the environment  
variables as if I'd typed its name into the Terminal?


No. As it says in "man 5 crontab", only LOGNAME (aka USER on some  
systems), HOME, and SHELL are set. You may set others by adding  
name=value pairs to your crontab file.


See "man 5 crontab" for details.


What about a script run from BBEdit?


BBEdit is a GUI app, and GUI apps don't use your login shell. To  
define environment variables to be used by GUI apps, have a look at  
this Q&A from Apple:





What if I "su root" and run it?


It depends. If you simply "su" to root, you'll keep the same  
environment. But, if you "su -" (note the dash), it's like you're  
starting a separate new login session - root's own user login scripts  
are run, and nothing is inherited.


Sudo begins with an inherited environment, but modifies it heavily -  
have a look at the "Security Notes" section in "man sudo" for details.


sherm--

Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

Re: The shell and my scripts

[David Ledger]

More to the point, environment variables are part of every process (rather
than just a login session). A process inherits variables with values from the
environment of its parent when it starts. From then on they're independent of
the parent. They're not a bolt-on but a fundamental part of the Unix process
design.

David


Kim Helliwell <[EMAIL PROTECTED]> wrote:

> The environment variables have nothing to do with the shell.
> The only thing the shell does is give you a way to set environment
> variables, and different shells have different syntax for that. But
> environment variables are a property of your login session, not
> of the shell.
> 
> So the short answer is: Perl does not need to know or care about what
> shell you're running in (although that's available as the environment
> variable SHELL). Perl scripts just get the environment variables for
> "free" as part of the startup.
> 
> Hope that answers it.
> 
> Kim Helliwell
> [EMAIL PROTECTED]
> Homepage: http://homepage.mac.com/kimgh
> 
> On Jul 28, 2005, at 8:10 PM, John Horner wrote:
> 
> > Recently there was a change at work -- all http access now needs to  
> > go through a proxy.
> >
> > So if I have a script using LWP::UserAgent or similar, I have to add
> >
> > $UA->proxy( ['http'] , 'http://proxy.fake.com:8080' );
> >
> > to all my scripts. Which is a big pain. So a *NIX guy said "you  
> > shouldn't need to do that if you can add an environment variable to  
> > your shell".
> >
> > So, as I use tcsh, not bash, which is the default nowadays, I added  
> > this to .tcshrc:
> >
> > setenv http_proxy http://proxy.fake.com:8080
> >
> > and it seemed to work, but leaving aside the specifics of the  
> > scripts, how would Perl "know" that I use tcsh, not bash? Isn't  
> > that a preference of the Terminal app, not of me as a user? A  
> > script run as a cron job, does it run using all the environment  
> > variables as if I'd typed its name into the Terminal? What about a  
> > script run from BBEdit? What if I "su root" and run it?
> >
> > I'd really appreciate someone explaining the relationship of script  
> > to shell and user.
> >
> >
> >
> 
> 

Re: The shell and my scripts

[Kim Helliwell]

The environment variables have nothing to do with the shell.
The only thing the shell does is give you a way to set environment
variables, and different shells have different syntax for that. But
environment variables are a property of your login session, not
of the shell.

So the short answer is: Perl does not need to know or care about what
shell you're running in (although that's available as the environment
variable SHELL). Perl scripts just get the environment variables for
"free" as part of the startup.

Hope that answers it.

Kim Helliwell
[EMAIL PROTECTED]
Homepage: http://homepage.mac.com/kimgh

On Jul 28, 2005, at 8:10 PM, John Horner wrote:

Recently there was a change at work -- all http access now needs to  
go through a proxy.


So if I have a script using LWP::UserAgent or similar, I have to add

$UA->proxy( ['http'] , 'http://proxy.fake.com:8080' );

to all my scripts. Which is a big pain. So a *NIX guy said "you  
shouldn't need to do that if you can add an environment variable to  
your shell".


So, as I use tcsh, not bash, which is the default nowadays, I added  
this to .tcshrc:


setenv http_proxy http://proxy.fake.com:8080

and it seemed to work, but leaving aside the specifics of the  
scripts, how would Perl "know" that I use tcsh, not bash? Isn't  
that a preference of the Terminal app, not of me as a user? A  
script run as a cron job, does it run using all the environment  
variables as if I'd typed its name into the Terminal? What about a  
script run from BBEdit? What if I "su root" and run it?


I'd really appreciate someone explaining the relationship of script  
to shell and user.