Professional Web Applications Themes

Environmental variables - Sun Solaris

Hello. I was wondering if there is a good online listing of all the environmental variables that Solaris contains/uses, for reference? I have searched over and over, and either it doesn't exist, or I'm just not searching intelligently... Also, I'm going to need to purchase some reference books before long, can anyone suggest the best ones to purchase? I'm looking at Solaris shell scripting OS reference (have the sysadmin pdf's) Anything else that would be of use to a Solaris Sysadmin Thanks!! Ted...

  1. #1

    Default Environmental variables

    Hello.

    I was wondering if there is a good online listing of all the
    environmental variables that Solaris contains/uses, for reference? I
    have searched over and over, and either it doesn't exist, or I'm just
    not searching intelligently...

    Also, I'm going to need to purchase some reference books before long,
    can anyone suggest the best ones to purchase? I'm looking at

    Solaris shell scripting
    OS reference (have the sysadmin pdf's)
    Anything else that would be of use to a Solaris Sysadmin

    Thanks!!
    Ted
    frogswallow Guest

  2. #2

    Default Re: Environmental variables

    dunno, but 'set' will list all your variables currently set, if thats
    any use.
    Geezer Guest

  3. #3

    Default Re: Environmental variables

    frogswallow wrote: 

    It doesn't exist, as such. Solaris doesn't "contain" any environment
    variables - these are dependent on a given application. If you're
    talking about the environment variables used and/or set by a given shell
    (a shell is itself an application), look at the manual page for that
    shell. The environ(5) manpage gives a list of useful variables that
    (according to the manual page) "can be used by applications and are
    expected to be set in the target run-time environment." however this
    list isn't exhaustive. Effectively the number of environment variables
    is infinite - for instance you won't find "FLARGLE" doented anywhere
    because I've just made it up, but it's used by this shell script

    #!/bin/sh
    echo "Today is `date \"+%A\"" > $FLARGLE

    otherwise you'll need to look at the doentation for whichever
    application you're interested in; Solaris and (more importantly) the
    shell you're running allows you to set environment variables and
    probably sets constraints on what you can put in them, but this isn't
    something that the OS itself dictates in general.

    HTH

    --
    Tony

    Tony Guest

  4. #4

    Default Re: Environmental variables

    In article <com>,
    Tony Walton <com> wrote:
     
    >
    > It doesn't exist, as such. Solaris doesn't "contain" any environment
    > variables - these are dependent on a given application. If you're
    > talking about the environment variables used and/or set by a given shell
    > (a shell is itself an application), look at the manual page for that
    > shell. The environ(5) manpage gives a list of useful variables that
    > (according to the manual page) "can be used by applications and are
    > expected to be set in the target run-time environment." however this
    > list isn't exhaustive. Effectively the number of environment variables
    > is infinite - for instance you won't find "FLARGLE" doented anywhere
    > because I've just made it up, but it's used by this shell script
    >
    > #!/bin/sh
    > echo "Today is `date \"+%A\"" > $FLARGLE
    >
    > otherwise you'll need to look at the doentation for whichever
    > application you're interested in; Solaris and (more importantly) the
    > shell you're running allows you to set environment variables and
    > probably sets constraints on what you can put in them, but this isn't
    > something that the OS itself dictates in general.[/ref]

    I've always made the distinction between shell variables (e.g. $FLARGLE)
    which are only scoped to the current process and environment variables
    (e.g. $TERM) which can be inherited by child processes.

    Tony, are you saying these are only a construct of a shell (whichever
    one that's being used) and there's no Solaris construct (like VMS'
    logical names) that's manages these things? I just looked at the man
    pages on my MacOS X system and it discussed environ(7) and execve(2).
    Are these environment variables strictly constructs of a shell,
    regardless of inheritance?

    --
    DeeDee, don't press that button! DeeDee! NO! Dee...



    Michael Guest

  5. #5

    Default Re: Environmental variables

    In comp.unix.solaris "Michael wrote: [/ref]
     

    Excellent for you to do so.
     

    It's a construct of a *process* (shells are one type of process). When
    a child is created, the default is that the parent environment (all the
    variables set) will be inherited.

    Unfortunately, I'm not familiar with VMS logical names, so I can't say
    how they compare.

    I just looked at the man 

    Constructs of a *process*.

    Note that a perl script wouldn't be a "shell". You can have it print
    the environment it's running under, which would be enherited from your
    shell.

    % perl -e 'while (($key, $val)=each %ENV) {print "$key = $val\n";}'

    This environment can be modified in the shell...
    VARIABLE=foo; export VARIABLE

    or in perl...
    $ENV{VARIABLE}="foo"

    Note that in Solaris there are some particular variables mentioned in
    environ(5) as being generally useful to many processes (PATH, TZ, LANG,
    Locale specifiers..), but that's not any type of exhaustive list.

    -
    Darren Dunham com
    Unix System Administrator Taos - The SysAdmin Company
    Got some Dr Pepper? San Francisco, CA bay area
    < This line left intentionally blank to confuse you. >
    Darren Guest

  6. #6

    Default Re: Environmental variables

    In article <R7ihb.10756$news.prodigy.com>, Darren Dunham <taos.com> writes: [/ref]

    >
    > Excellent for you to do so.

    >
    > It's a construct of a *process* (shells are one type of process). When
    > a child is created, the default is that the parent environment (all the
    > variables set) will be inherited.
    >
    > Unfortunately, I'm not familiar with VMS logical names, so I can't say
    > how they compare.
    >
    > I just looked at the man 
    >
    > Constructs of a *process*.
    >
    > Note that a perl script wouldn't be a "shell". You can have it print
    > the environment it's running under, which would be enherited from your
    > shell.
    >
    > % perl -e 'while (($key, $val)=each %ENV) {print "$key = $val\n";}'
    >
    > This environment can be modified in the shell...
    > VARIABLE=foo; export VARIABLE
    >
    > or in perl...
    > $ENV{VARIABLE}="foo"
    >[/ref]

    Or in C:
    putenv("PATH=/usr/xpg4/bin:/bin:/usr/bin");
    putenv("LD_LIBRARY_PATH=/usr/lib");

     


    --
    Michael Tosch
    IT Specialist
    HP Managed Services Germany
    Phone +49 2407 575 313


    Michael Guest

  7. #7

    Default Re: Environmental variables

    "Michael Vilain " wrote: 

    They are distinct. That's why the "export" command exists in
    the Bourne shell. Just doing this:

    FOO=mystring

    will set the shell variable. However, doing "export FOO" will
    bind the shell variable to an environment variable, so that
    whenever the shell variable is changed, the environment variable's
    value will be changed as well.

    Tony's example worked (and was a valid demonstration of environment
    variables) because when you start the shell, it imports all
    the environment variables as shell variables.

    Interestingly, "export FOO" doesn't just copy the value of a shell
    variable to an environment variable. It really does permanently
    bind them together:

    $ FOO=99
    $ export FOO
    $ sh -c 'echo $FOO'
    99
    $ FOO=42
    $ sh -c 'echo $FOO'
    42
    $

    Note that the child process sees 42 even though I haven't reexported
    the variable.

    Whether the shell does this by instantly updating the environment
    or by just making sure it's correct before doing an exec(), I'm
    not sure. As far as I know, there would be no way to tell from
    inside the shell which one it's doing.

    I've never known for sure, but I can only assume that this was
    done originally for efficiency reasons. Unless removed explicitly,
    environment variables take up space in child processes, and their
    child processes, etc., so it's wasteful to set one that isn't
    needed. I guess it's also good for cleanliness and security.
    I.e., it makes both my life (as parent process) and your life
    (as child process) easier if I don't pollute your namespace with
    my own private information.

    - Logan

    Logan Guest

  8. #8

    Default Re: Environmental variables

    Environment variables are passed just like command line arguments (see
    execve(); it's the real syscall, all the other exec*() flavors are just
    more elaborate wrappers *). Typically (although you shouldn't count on
    it) they're stored right after the command line arguments (i.e. on many
    systems, argv[argc+1] is the first environment variable, but it's
    incorrect to refer to it that way).

    Most of the time, programs choose to use the versions of exec*() that do
    not _explicitly_ pass the environment. Those instead implicitly pass
    environ, an external variable that was initialized by the run-time startup
    code from the incoming environment variables (and may have been modified
    either by putenv() or by the more elaborate environment variable managing
    code that shells may contain). That's all the "magic" there is to
    environment variables - that they're passed implicitly by execv(),
    execl(), execvp(), and execlp(), as contrasted with command line
    arguments that are passed explicitly.

    The binding of shell variables to environment variables is strictly a
    matter of how the shell manages things, it's not anything to do with the
    kernel, whose only direct interest in environment variables is to
    facilitate passing them via execve(); the kernel has nothing to do with
    managing them, and doesn't even care if they're not of the form
    name=value. In fact, at least one program purposely passes an environment
    string that's _not_ of that form, as an indication of a special case of
    how it's being used; the exec'd instance then removes that before exec'ing
    anything else. (that happens when doing a subsystem login (asterisk in
    login shell field, see login(1)). This means that "correct" use of
    environment variables (in the sense of having a name=value form and
    reasonable constrains on the name part) is strictly a matter of convention
    amongst programs using environment variables; anything _could_ violate it,
    although not profitably except in the narrow case of when a program is
    re-exec()'ing itself and cleans up afterward.

    An environment variable changed in a parent does not have any effect on
    that variable in already-running children; it only affects what's
    inherited by new children when they're fork()'ed off, and (perhaps) what
    any new program the child executes will have handed off to it.

    * there is another exec that's a real syscall, but inside the kernel
    it too is just a wrapper. It's only there for binary compatibility;
    none of the libraries use it AFAIK; it passes no environment variables
    at all, neither explicitly nor implicitly, which means any program it
    transferred control to would inherit _no_ environment variables. That's
    really a legacy of ancient history, before environment variables were
    invented; you'll probably never encounter it, and I mention it only 'cause
    there are a few people out there that know about it and would bring it
    up just to muddy the waters.

    --
    mailto:net http://www.smart.net/~rlhamil
    Richard Guest

  9. #9

    Default Re: Environmental variables

    "Michael Vilain " wrote:
     

    A distinction also made by some shells (csh for example uses "set" for
    variables and "setenv" for environment variables). I'm not sure how
    useful it is in terms of pure shell programming - I tend to think in
    terms of shell varables some of which are exported and some of which
    aren't. YMMV.
     

    No. Shells are one thing that uses env vars - there are others, as I
    hoped I'd mentioned.... "these are dependent on a given application. If
    you're talking about the environment variables used and/or set by a
    given shell (a shell is itself an application)" - oh look, I did :-)
    Perhaps I should have said "...talking SPECIFICALLY about..."

    You can set an environment variable in a shell, ( export
    FLARGLE=/tmp/foo ) or otherwise ( putenv(FLARGLE, "/tmp/foo") );
     

    Absolutely not. If a calling program written in C sticks things in the
    callee's envp[] then execve's it, they'll be in the callee's environment
    even though it wasn't called by a shell.

    main()
    {
    char *envp[2];
    envp[0]="FLARGLE=ribbit";
    envp[1]=(char *)0;
    execle("/tmp/called","/tmp/called", (char *)0,envp);
    }

    $ cat called.c
    main()
    {
    printf("%s\n",getenv("FLARGLE"));
    }

    FLARGLE is a variable in called's environment and it wasn't put there by
    any shell!


    HTH

    --
    Tony

    Tony Guest

Similar Threads

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139