[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS update: ozone-modules/ozoneDoc
Per Nyfelt wrote:
>
> No, it is not different but lets say you open a console and do various stuff
> from this one console (including running the build script).
> E.g.
> [cmd shell]>build
> ...build runs and changes environment
> [cmd shell]>xemacs myFile.java
> 'xemacs' is not recognized as an internal or external command,
> operable program or batch file.
>
> You would in this particular case to not have the build script change your
> environment but to have it unchanged after the execution of build hence the
> fix. Personally I seldom work in this mode but open a new console (process)
> every time I execute a script but the fix that Lars proposed allows for both
> ways of working.
Okay, then it is different as in UNIX a subprocess from a shell such as
build.sh does not change anything in the parent process environment
space. Otherwise nasty processes could change init(s) env space.
Eric
> > eric wrote:
> >
> > This has been bothering me for awhile. I was thinking about environment
> > variables in UNIX and realized that the shell is the parent process for
> > the script that calls ant. Unless I'm completely messed up, exporting
> > env vars changes the vars for only the current process and child
> > processes. Thus the parent process (ie shell) should not be affected by
> > the exports. Is this different in a Windows shell or is there just some
> > misunderstanding?
> >
> > Example:
> >
> > #!/bin/sh
> > export PATH=""
> > echo path=$PATH
> >
> > echo $PATH, then run script and then do echo $PATH.
> >
> > PATH is the same befor and after.
> >
> > Eric
> >
> >