RE: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...

RE: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...

[Andrej Borsenkow]

>
>   The only file you can alter which is started with every zsh (unless
>   you use the -f option) is .zshenv, so this is a good place to
>   put things you want even if the shell is non-interactive: options for
>   changing the the syntax, like EXTENDED_GLOB,

I totally disagree. Anybody doing this will inevitably end up writing
nonportable zsh scripts, that, when used on other system(s), will not work
in the best or will have unpredictable side effects in the worst case.

The only use for zshenv is to setup standard environment (as name suggests).
If you would like to have interactive zsh with specific features - do it in
zshrc. Scripts should _not_ depend on particular option(s) preset or, for
that matter, on particular function(s) being available.

So, I have LD_LIBRARY_PATH in /etc/zshenv, ~/bin in .zshenv - and don't see
much more use for them.

/andrej

Re: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> >
> >   The only file you can alter which is started with every zsh (unless
> >   you use the -f option) is .zshenv, so this is a good place to
> >   put things you want even if the shell is non-interactive: options for
> >   changing the the syntax, like EXTENDED_GLOB,
> 
> I totally disagree. Anybody doing this will inevitably end up writing
> nonportable zsh scripts, that, when used on other system(s), will not work
> in the best or will have unpredictable side effects in the worst case.

I totally disagree with your total disagreement.  I use zsh from
emacs, and I need to get things like `grep *.(c|cc)(^@)' to work,
which requires extendedglob to be set somewhere (lots of other shell
calls are similar).  The only simple answer (there are plenty of
horribly complex answers --- three personal startup files is quite
enough) is in .zshenv.  I don't want or need a portable environment to
make zsh usable, I want *my* environment.

The only external way of making scripts portable is to use the -f
option.  Even then somebody has messed about with /etc/zshenv, which
happens but which I loathe.  Furthermore, lots of scripts are also
able to work as functions --- zsh was specifically written that way.
There are so many things you can do with zsh that the only safe thing
to do with scripts is make sure you are explicit about which options
are set and which aren't.  Then you're stuck with `emulate -R zsh'.
And if you're religiously into portablity, write ksh scripts and stick
[[ -n $ZSH_VERSION ]] && emulate -R ksh
at the top.

Still, I'll add a warning.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...

[Bart Schaefer]

On Feb 5,  9:40am, Andrej Borsenkow wrote:
} Subject: RE: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...
}
} >
} >   The only file you can alter which is started with every zsh (unless
} >   you use the -f option) is .zshenv, so this is a good place to
} >   put things you want even if the shell is non-interactive: options for
} >   changing the the syntax, like EXTENDED_GLOB,
} 
} I totally disagree. Anybody doing this will inevitably end up writing
} nonportable zsh scripts, that, when used on other system(s), will not work
} in the best or will have unpredictable side effects in the worst case.

We've had some discussions before about options that change the syntax,
IIRC in the context of which options could be "on" by default to better
showcase the multitude of zsh's talents.  It was concluded that the only
safe options to play with were the ones that changed purely interactive
features, like completion.

Quite obviously system administrators should be strongly discouraged from
using options that change the shell syntax in *any* of the global init
files, without extremely good reason.  An example of such a good reason:
using CSH_JUNKIE_PAREN in global files for zsh 2.5, when an incompatible
syntax change was introduced in the shell itself, which broke everyone's
personal init files.  (That option is now gone and the syntax restored.)

However, given that options to change the syntax exist at all, I can't
find fault with whichever of a users *personal* init files contain those
options.  Most users are going to write scripts and shell functions using
commands that work in their own interactive environment, and then will
expect them to work the same way in non-interactive shells started with
e.g. "rsh host command".  The only way to assure that this works is to
put the necessary settings in .zshenv.

"Writing nonportable zsh scripts" is a complete red herring.  The only way 
to write a portable zsh script is to begin the script with

    emulate -R zsh
    setopt ...		# whatever options the script needs, if any

If those lines are missing, the script is going to break eventually.  If
they're present, the script is immune to options set in the init files.
That's why the "emulate zsh" command was added in the first place.

Of course, you could still get messed up by aliases or functions that have
the same names as utilities, or named directory hashing, or a bogus $path.  
That's what you get for using an interpreted language.  The paranoid may
begin all scripts with

	#!/bin/sh

Then even /etc/zshenv won't be sourced.

} Scripts should _not_ depend on particular option(s) preset or, for
} that matter, on particular function(s) being available.

This is an excellent rule when writing scripts for public consumption.
It's unrealistic to apply it to an average user writing scripts for his
own convenience.  (Heck, even /etc/rc.d/init.d/* depend on being having
certain variables set and on using functions that are loaded by `.'-ing
other files.)  Perhaps, however, the FAQ should make a stronger point
that there are possible unintended side-effects of using .zshenv.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...

[Peter Stephenson]

I've just put this together.

3.2: In which startup file do I put...?

  When zsh starts up, there are four files you can change which it will
  run under various circumstances: .zshenv, .zprofile, .zshrc
  and .zlogin.  They are usually in your home directory, but the
  variable $ZDOTDIR may be set to alter that.  Here are a few simple
  hints about how to use them.  There are also files which the system
  administrator can set for all shells; you can avoid running all except
  /etc/zshenv by starting zsh with the -f option --- for this
  reason it is important for administrators to make sure /etc/zshenv
  is as brief as possible.

  The order in which the four files are searched (none of them _need_
  to exist) is the one just given.  However, .zprofile and .zlogin
  are only run when the shell is a login shell --- when you first login,
  of course, and whenever you start zsh with the -l option.  All
  login shells are interactive.  The order is the only difference
  between those; you should decide whether you need things set before or
  after .zshrc.  These files are a good place to set environment
  variables (i.e. `export' commands), since they are passed on to
  all shells without you having to set them again, and also to check
  that your terminal is set up properly (except that if you want to
  change settings for terminal emulator windows like xterm you will
  need to put those in .zshrc, since usually you do not get a login
  shell here).  

  The only file you can alter which is started with every zsh (unless
  you use the -f option) is .zshenv, so this is a good place to
  put things you want even if the shell is non-interactive: options for
  changing the the syntax, like EXTENDED_GLOB, any changes to set with
  `limit', any more variables you want to make sure are set as for
  example $fpath to find functions.  You almost certainly do not
  want .zshenv to produce any output.

  Finally, .zshrc is run for every interactive shell; that includes
  login shells, but also any other time you start up a shell, such as
  simply by typing `zsh' or opening a new terminal emulator window.
  This file is the place to change the editing behaviour via options or
  `bindkey', control how your history is saved, set aliases unless
  you want to use them in scripts too, and for any other clutter which
  can't be exported but you only use when interacting directly with the
  shell.  You probably don't want .zshrc to produce output, either,
  since there are occasions when this can be a problem, such as when
  using `rsh' from another host.  See 3.21 for what to
  put in .zshrc to save your history.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...

[Peter Stephenson]

"Bart Schaefer" wrote:
> Stuff you want in every shell goes in .zshenv.
> ...
> 
> Hey, PWS, why isn't this in the FAQ?  It's probably THE most FAQ I've
> ever seen.

I thought it was explicit enough in the manual, and it's the sort of
thing covered by the main UNIX FAQs, so I never felt the need.  Maybe
it would be safer.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...

[Bart Schaefer]

On Feb 3,  1:29pm, Greg Sylvain wrote:
> Subject: Re: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...
> 
> 1 - where is the most appropriate place to put the unlimit call (~/.zshenv
> or ~/.zshrc).  I never have been able to figure out what goes where.

Stuff you want in every shell goes in .zshenv.
Stuff you want in any interactive shell goes in .zshrc.
Stuff you want only in login shells goes in .zprofile or .zlogin (depending
on whether it needs to precede or follow stuff that's in .zshrc; usually
you won't need both).

Often stuff from your first login shell is inherited by all other shells
(exceptions include shells started with "rsh host command"), so anything
like that should go in .zlogin to speed startup of other shells.

Hey, PWS, why isn't this in the FAQ?  It's probably THE most FAQ I've
ever seen.

> Currently, I only specify my path in ~/.zshenv and everything else is done
> in ~/.zshrc, is this correct ?

It might be.

I'd say put the unlimit in .zshenv, too; but it may be sufficient for your
usage to have it happen once the first time you log in, thus in .zlogin.

> 2 - is there any way to determine the amount of resources consumed by zsh
> and in what areas ?

Only by using the "ps" command or something like the /proc filesystem on
linux, as far as I know.

Re: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...

[Sweth Chandramouli]

On Wed, Feb 03, 1999 at 01:29:10PM -0500, Greg Sylvain wrote:
> Ok. great.
> 
> unlimit worked, well on Sol24 box anyway.  To finish this off then, I have
> a couple last questions :
> 
> 1 - where is the most appropriate place to put the unlimit call (~/.zshenv
> or ~/.zshrc).  I never have been able to figure out what goes where.
> Currently, I only specify my path in ~/.zshenv and everything else is done
> in ~/.zshrc, is this correct ?

	from the comments i have in my zsh startup files:

# Sweth's No-Longer-Very-Portable .zshenv File
# 1st user initialization file, read for all non -f shells.

# Sweth's No-Longer-Very-Portable .zprofile File
# 2nd user initialization file, read for login shells

# Sweth's No-Longer-Very-Portable .zshrc File
# 3rd initialization file, read for interactive shells

# Sweth's No-Longer-Very-Portable .zlogin File
# 4th user initialization file, read for login shells

# .zlogout, sourced before exiting a login shell.
# remember to put some sort of sleep command at
# the end if this should produce user-visible output

	i put most env variables (not just path) in my .zshenv (so that
they are available to scripts that i run in addition to interactive 
sessions), along with limit/unlimit commands (again, so they affect
everything).
	i use .zprofile mainly for starting processes--things that
only need to happen once per "sit down at the computer" session,
regardless of how many actual shell sessions i start.  for example,
i start a fetchmail process (or wake a backgrounded one if it is
already running) to check for mail on other server, and set the
erase key depending on whether i'm logging in from my mac at home,
the console on my sun, or my desktop pc--it's an "environment"
variable, but it's only needed for interactive shells, and then
should stay the same for all of shells spawned from that same
terminal.
	in .zshrc, i set my zshoptions, define aliases, and do
compctl stuff--they are things that mostly affect how the
shell reacts to what i type during an interactive session.
	at the moment, i don't use .zlogin; soon, though, i
hope to move some of the stuff in my .zprofile there, to
take advantage of the functions i define in .zshrc so that
my scripts don't have to be so redundant.  (i could probably
move a lot of the environment definitions from .zshenv here
safely as well, and eliminate a lot more redundancy that way.)
	in .zlogout, i clean up whatever i started (including
killing process i might have started in .zprofile and .zlogin.

	-- sweth.

-- 
Sweth Chandramouli
IS Coordinator, The George Washington University
<sweth@gwu.edu> / (202) 994 - 8521 (V) / (202) 994 - 0458 (F)
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html">*</a>

Re: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...

[Greg Sylvain]

Ok. great.

unlimit worked, well on Sol24 box anyway.  To finish this off then, I have
a couple last questions :

1 - where is the most appropriate place to put the unlimit call (~/.zshenv
or ~/.zshrc).  I never have been able to figure out what goes where.
Currently, I only specify my path in ~/.zshenv and everything else is done
in ~/.zshrc, is this correct ?

2 - is there any way to determine the amount of resources consumed by zsh
and in what areas ?  (i.e. is it my environment that is causing the stack
space to blow or is it the datasize, etc ???)

Thanks,
greg





"Bart Schaefer" <schaefer@brasslantern.com> on 02/03/99 12:54:13 PM
                                                              
                                                              
                                                              
 To:      Greg Sylvain/LSC, zsh-users@sunsite.auc.dk          
                                                              
 cc:                                                          
                                                              
                                                              
                                                              
 Subject: Re: Problem w/ ulimit killing compiles on sol       
          2.4&2.6 ...                                         
                                                              








On Feb 3, 12:38pm, Greg Sylvain wrote:
} Subject: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...
}
} I'm running zsh 3.0.5 on a Solaris 2.4 and 2.6 machine, while attempting
to
} build a large C++ application with gcc -2.7.2.1 the compile exits
} prematurly after attempting to link the resulting objects.

I presume you get some kind of error message that leads you to believe
this is a limits problem?

} When I got to a fresh ksh with nothing int he evnironment, I'm able to
} build and link the program just fine.

Some versions of Sun operating systems have problems executing processes
if there's too much stuff in the environment.  I'd be surprised if Sol 2.6
was still susceptible, but it's possible.  You don't use `setopt allexport`
in zsh or anything silly like that, do you?

} My question is why is this happening and how can I fix it?  (I have 24
} directories in my PATH!)  What contributes to this limit problem and is
} there any way to increase the limit any more..

Have you tried the `unlimit` command (note the "n") which with no argument
should increase all limits to their maximum allowed values?

--
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...

[Greg Sylvain]

Hi,

Thanks for the quick reply... comments interposed with original message ...





"Bart Schaefer" <schaefer@brasslantern.com> on 02/03/99 12:54:13 PM
                                                              
                                                              
                                                              
 To:      Greg Sylvain/LSC, zsh-users@sunsite.auc.dk          
                                                              
 cc:                                                          
                                                              
                                                              
                                                              
 Subject: Re: Problem w/ ulimit killing compiles on sol       
          2.4&2.6 ...                                         
                                                              








On Feb 3, 12:38pm, Greg Sylvain wrote:
> } Subject: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...
> }
> } I'm running zsh 3.0.5 on a Solaris 2.4 and 2.6 machine, while
attempting to
> } build a large C++ application with gcc -2.7.2.1 the compile exits
> } prematurly after attempting to link the resulting objects.

> I presume you get some kind of error message that leads you to believe
> this is a limits problem?

nop.  just an assumption on my part.  Sorry 'bout that, didn't mean to
mislead people.  Anything else come to mind ?

> } When I got to a fresh ksh with nothing int he evnironment, I'm able to
> } build and link the program just fine.
>
> Some versions of Sun operating systems have problems executing processes
> if there's too much stuff in the environment.  I'd be surprised if Sol
2.6
> was still susceptible, but it's possible.  You don't use `setopt
allexport`
> in zsh or anything silly like that, do you?
>

Sol 2.6 has the same problem, it *may* build the smaller test program along
the way to linking the final huge executable, but compiling and linking
fails on both OSs, eventually.
The errors that I get from the links are duplicate symbols in different
libraries that use the same part of the STL (i.e. duplicate vector
class,etc.).

> } My question is why is this happening and how can I fix it?  (I have 24
> } directories in my PATH!)  What contributes to this limit problem and is
> } there any way to increase the limit any more..
>
> Have you tried the `unlimit` command (note the "n") which with no
argument
> should increase all limits to their maximum allowed values?

No I haven't.  I'm trying it now.  I'll let you know the results...


Thanks,
greg

--
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...

[Bart Schaefer]

On Feb 3, 12:38pm, Greg Sylvain wrote:
} Subject: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...
}
} I'm running zsh 3.0.5 on a Solaris 2.4 and 2.6 machine, while attempting to
} build a large C++ application with gcc -2.7.2.1 the compile exits
} prematurly after attempting to link the resulting objects.

I presume you get some kind of error message that leads you to believe
this is a limits problem?

} When I got to a fresh ksh with nothing int he evnironment, I'm able to
} build and link the program just fine.

Some versions of Sun operating systems have problems executing processes
if there's too much stuff in the environment.  I'd be surprised if Sol 2.6
was still susceptible, but it's possible.  You don't use `setopt allexport`
in zsh or anything silly like that, do you?

} My question is why is this happening and how can I fix it?  (I have 24
} directories in my PATH!)  What contributes to this limit problem and is
} there any way to increase the limit any more..

Have you tried the `unlimit` command (note the "n") which with no argument
should increase all limits to their maximum allowed values?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Problem w/ ulimit killing compiles on sol 2.4&2.6 ...

[Greg Sylvain]

Hi,

I'm running zsh 3.0.5 on a Solaris 2.4 and 2.6 machine, while attempting to
build a large C++ application with gcc -2.7.2.1 the compile exits
prematurly after attempting to link the resulting objects.  The program
uses HP STL (old Standard Template Library) and the -frepo compile option
to gcc.  (-frepo is used recompiling objects to allevitate the template
instantion problem - from what I understand.)

When I got to a fresh ksh with nothing int he evnironment, I'm able to
build and link the program just fine.

My question is why is this happening and how can I fix it ?  (I have 24
directories in my PATH!)  What contributes to this limit problem and is
there any way to increase the limit any more..

output from ulimit on sol 2.4 :

pts/1 zsh-3.0.5 > ulimit -a
cpu time (seconds)         unlimited
file size (blocks)         unlimited
data seg size (kbytes)     1024
stack size (kbytes)        8192
core file size (blocks)    unlimited
file descriptors           1024
virtual memory size (kb)   unlimited


Thanks in advance for any assistance,
greg