![[Previous]](prev.gif) |
![[Contents]](contents.gif) |
![[Index]](keyword_index.gif) |
![[Next]](next.gif) |
|
|
|
|
This chapter includes:
The Controlling How Neutrino Starts chapter describes what happens when you boot your system, and what you can do to customize the system. This chapter describes how you can customize the environment that you get when you log in, and then describes some of the setup you might need to do.
Before you start customizing your login environment, you should understand just what happens when you log in, because the nature of the customization determines where you should make it. You should consider these questions:
When you log in, the system starts the login shell that's specified in your entry in the account database (see “/etc/passwd” in Managing User Accounts). The login shell is typically sh, which is usually just a link to the Korn shell, ksh.
When ksh starts as a login shell, it executes these profiles, if they exist and are executable:
Why have two profiles? Settings that apply to all users go into /etc/profile; your own customizations go into your own .profile. As you might expect, you need to be root to edit /etc/profile.
There's actually a third profile for the shell. The special thing about it is that it's executed whenever you start a shell; see “ksh's startup file,” below.
Your home directory is where you can store all the files and directories that are relevant to you. It's a good place to store your own binaries and scripts. Your entry in the password database specifies your home directory (see “/etc/passwd” in Managing User Accounts), and the HOME environment variable stores this directory's name.
Your home directory is also where you store information that configures your environment when you log in. By default, applications pick this spot to install configuration files. Configuration files are generally preceded by a period (.) and run either when you log in (such as .profile) or when you start an application (such as .jedrc).
Photon applications are a special case. Applications that are run in Photon generally store their configurations in the $HOME/.ph directory. If you want to automatically start any applications when you start Photon, put the commands in your $HOME/.ph/phapps file.
There are many files that configure your environment; this section describes some of the more useful ones:
The login shell executes /etc/profile if this file exists and is readable. This file does the shell setup that applies to all users, so you'll be interested in it if you're the system administrator; you need to log in as root in order to edit it.
The /etc/profile file:
If you have a script that you want to run whenever anyone on the system runs a login shell, put it in the /etc/profile.d directory. You must have root-level privileges to add a file to this directory.
For example, if you need to set global environment variables or run certain tasks when anyone logs in, then this is the place to put a script to handle it. If you're using sh as your login shell, make sure that the script has a .sh extension.
The system runs $HOME/.profile whenever you log in, after it runs /etc/profile. If you change your .profile, the changes don't go into effect until you next log in.
You should use your .profile to do the customizations that you need to do only once, or that you want all shells to inherit. For example, you could:
 |
If you want to create an alias, you should do it in your shell's
profile (see
“ksh's startup file,”
below), not in .profile, because the shell doesn't export
aliases.
If you do set an alias in .profile, the alias is set only
in shells that you start as login shells, using the -l option.
Don't start Photon applications in .profile, because Photon isn't running when this script is executed; use the $HOME/.ph/phapps file instead. |
For an example of .profile, see the Examples appendix.
As described above, the login shell runs certain profiles. In addition, you can have a profile that ksh runs whenever you start a shell — whether or not it's a login shell.
This profile doesn't have a specific name; when you start ksh, it checks the ENV environment variable. If this variable exists, ksh gets the name of the profile from it. To set up ENV, add a line like this to your $HOME/.profile file:
export ENV=$HOME/.kshrc
People frequently call the profile .kshrc, but you can give it whatever name you want. This file doesn't need to be executable.
Use ksh's profile to set up your favorite aliases, and so on. For example, if you want ls to always display characters that tell you if a file is executable, a directory, or a link, add this line to the shell's profile:
alias ls="ls -F"
Any changes that you make to the profile apply to new shells, but not to existing instances.
For an example of .kshrc, see the Examples appendix.
Many applications use environment variables to control their behavior. For example, less gets the width of the terminal or window from the COLUMNS environment variable; many utilities write any temporary files in the directory specified by TMPDIR. For more information, see the Commonly Used Environment Variables appendix of the Utilities Reference.
When you start a process, it inherits a copy of its parent's environment. This means that you can set an environment variable in your .profile, and all your shells and processes inherit it — provided that no one in the chain undefines it.
For example, if you have your own bin directory, you can add it to your PATH by adding a line like this to your .profile:
export PATH=$PATH:/home/username/bin
If you're the system administrator, and you want this change to apply to everyone, export the environment variables from /etc/profile or from a script in /etc/profile.d. For more information, see the discussion of /etc/profile earlier in this chapter.
The login utility doesn't preserve environment variables, except for a few special ones, such as PATH and TERM.
The PATH environment variable specifies the search paths for commands, while LD_LIBRARY_PATH specifies the search paths for shared libraries for the linker.
The initial default values of PATH and LD_LIBRARY_PATH are specified in the buildfile before procnto is started. Two configuration strings (see “Configuration strings,” below), _CS_PATH and _CS_LIBPATH, take the default values of PATH and LD_LIBRARY_PATH. The login utility uses _CS_PATH to set the value of PATH and passes this environment variable and both configuration strings to its child processes.
If you type set or env in a shell that was started from login, you'll see the PATH variable, but not LD_LIBRARY_PATH; _CS_LIBPATH works in the same manner as LD_LIBRARY_PATH.
You can use the /etc/default/login file to indicate which environment variables you want login to preserve. You can edit this file to add new variables, such as LD_LIBRARY_PATH, but you can't change existing variables such as PATH and TERM.
If you use ksh as your login shell, you can edit /etc/profile and $HOME/.profile to override existing variables and add new ones. Any environment variables set in /etc/profile override previous settings in /etc/default/login; and $HOME/.profile overrides both /etc/default/login and /etc/profile.
For more information on configuration strings, see “Configuration strings,” below.
In addition to environment variables, Neutrino uses configuration strings. These are system variables that are like environment variables, but are more dynamic.
When you set an environment variable, the new value affects only the current instance of the shell and any of its children that you create after setting the variable; when you set a configuration string, its new value is immediately available to the entire system.
|
Neutrino also supports configurable limits, which are variables that store information about the system. For more information, see the Understanding System Limits chapter. |
You can use the POSIX getconf utility to get the value of a configurable limit or a configuration string. Neutrino also defines a non-POSIX setconf utility that you can use to set configuration strings if you're logged in as root. In a program, call confstr() to get the value of a configuration string.
The names of configuration strings start with _CS_ and are in uppercase, although getconf and setconf let you use any case, omit the leading underscore, or the entire prefix — provided that the rest of the name is unambiguous.
The configuration strings include:
|
A hostname can consist only of letters, numbers, and hyphens, and
must not start or end with a hyphen.
For more information, see RFC 952.
If you change this configuration string, be sure you also change the HOSTNAME environment variable. The hostname utility always gives the value of the _CS_HOSTNAME configuration string. |
If you're running Photon, the easiest way to set the time zone is via phlocale. You simply select the appropriate zone, and phlocale does everything else.
If you aren't running Photon, you need to set the TZ environment variable or the _CS_TIMEZONE configuration string. To set the time zone when you boot your machine, you have to put the same information in the /etc/TIMEZONE file; see the description of /etc/system/sysinit in Controlling How Neutrino Starts.
|
If TZ isn't set, the system uses the value of the _CS_TIMEZONE configuration string instead. The POSIX standards include the TZ environment variable; _CS_TIMEZONE is a Neutrino implementation. The description below applies to both. |
Various time functions use the time-zone information to compute times relative to Coordinated Universal Time (UTC), formerly known as Greenwich Mean Time (GMT).
You usually set the time on your computer to UTC. Use the date command if the time isn't automatically maintained by the computer hardware.
You can set the TZ environment variable by using the env utility or the export shell command. You can use setconf to set _CS_TIMEZONE. For example:
env TZ=PST8PDT export TZ=PST8PDT setconf _CS_TIMEZONE PST8PDT
The format of the TZ environment variable or _CS_TIMEZONE string is as follows (spaces are for clarity only):
std offset dst offset, rule
The expanded format is as follows:
stdoffset[dst[offset][,start[/time],end[/time]]]
The components are:
hh[:mm[:ss]]
Minutes (mm) and seconds (ss) are optional. The hour (hh) is required; it may be a single digit.
The offset following std is required. If no offset follows dst, summer time is assumed to be one hour ahead of standard time.
You can use one or more digits; the value is always interpreted as a decimal number. The hour may be between 0 and 24; the minutes (and seconds), if present, between 0 and 59. If preceded by a “-”, the time zone is east of the prime meridian; otherwise it's west (which may be indicated by an optional preceding “+”).
date/time,date/time
where the first date describes when the change from standard to summer time occurs, and the second date describes when the change back happens. Each time field describes when, in current local time, the change to the other time is made.
The format of date may be one of the following:
The time has the same format as offset, except that no leading sign (“+” or “-”) is allowed. The default, if time is omitted, is 02:00:00.
| Daylight Saving Time: | Old: | New: |
|---|---|---|
| Starts | The first Sunday in April | The second Sunday in March |
| Ends | The last Sunday in October | The first Sunday in November |
While the standard rule changed across all states, US states still have the right not to observe daylight saving time, as per the Uniform Time Act of 1966. For information about American time zones, see http://www.time.gov.
This section examines some sample time-zone settings.
|
As mentioned above, the library interprets the short specifications of North American time zones according to the rules that went into effect March 1, 2007. |
The default time zone is Eastern time; the short specification is:
EST5EDT
The full specification is:
EST5EDT4,M3.2.0/02:00:00,M11.1.0/02:00:00
Both are interpreted as follows:
The short specification for Pacific time is:
PST8PDT
The full specification is:
PST08PDT07,M3.2.0/2,M11.1.0/2
Both are interpreted as follows:
The short specification for Newfoundland time is:
NST3:30NDT2:30
The full specification is:
NST03:30NDT02:30,M3.2.0/00:01,M11.1.0/00:01
Both are interpreted as follows:
The specification for Central European time is:
Central Europe Time-2:00
The specification for Japanese time is:
JST-9
Inside a program, you can set the TZ environment variable by calling setenv() or putenv():
setenv( "TZ", "PST08PDT07,M3.2.0/2,M11.1.0/2", 1 ); putenv( "TZ=PST08PDT07,M3.2.0/2,M11.1.0/2" );
To obtain the value of the variable, use the getenv() function:
char *tzvalue; … tzvalue = getenv( "TZ" );
You can get the value of _CS_TIMEZONE by calling confstr(), like this:
confstr( _CS_TIMEZONE, buff, BUFF_SIZE );
or set it like this:
confstr( _CS_SET | _CS_TIMEZONE, "JST-9", 0 );
The tzset() function gets the current value of TZ — or _CS_TIMEZONE if TZ isn't set — and sets the following global variables:
Whenever you call ctime(), ctime_r(), localtime(), or mktime(), the library sets tzname, as if you had called tzset(). The same is true if you use the %Z directive when you call strftime().
For more information about these functions and variables, see the Neutrino Library Reference.
If you want to run a Photon application whenever Photon starts, put it in your $HOME/.ph/phapps file. Put each command on a separate line. For example, to start the Photon editor when you start Photon, include this line:
ped &
|
This file isn't a shell script, so don't set any environment variables in it. |
The Photon environment supports a wide variety of font types. Any Unicode font should work inside of the Photon environment.
The font files on your system are stored in /usr/photon/font_repository. This directory contains the following:
To install a new font on your system, copy the font files into the font_repository directory, and run the mkfontdir utility to create the new fontdir file. You then need to restart your font manager, which is usually io-graphics. If you run a standalone phfont server, restart it too.
Photon includes input methods for Chinese, Japanese, and Korean. You can launch these applications by typing cpim (Chinese Input Method), vpim (Japanese), or kpim (Korean). Using a standard keyboard, you can input characters in these languages to any application that normally accepts text. For more information, see the Photon Multilingual Input bookset.
You need to set the TERM environment variable to indicate to your console or pterm what type of terminal you're using. The /usr/lib/terminfo directory contains directories that contain terminal database information. You can use the utilities tic and infocmp to change the mappings in the database.
For example, you could run infocmp on /usr/lib/terminfo/q/qansi-m and this would generate the source for this database. You could then modify the source and then run the tic utility on that source to compile the source back in to a reconcilable database. The /etc/termcap file is provided for compatibility with programs that use the older single-file database model as opposed to the newer library database model.
For more information, see:
Strang, John, Linda Mui, and Tim O'Reilly. 1988. termcap & terminfo. Sebastopol, CA: O'Reilly and Associates. ISBN 0937175226.
Here are some common problems you might encounter while customizing your environment:
#! /bin/sh
Under Neutrino, you usually set the hardware clock to use UTC (Coordinated Universal Time) and then set the time zone. Under Windows, you set the hardware clock to use local time.
To set the time so that it's correct in both operating systems, set the hardware clock to use local time under Neutrino. For more information, see the description of /etc/system/sysinit in the Controlling How Neutrino Starts chapter of this guide.
case $- in
*i*)
set -o emacs
export EDITOR=vi
export VISUAL=vi
export PS1='`hostname -s`:`/bin/pwd` >'
bind ^[[z=list
bind ^I=complete
...
esac
The $- parameter is a concatenation of all the single-letter options that are set for the script. For more information, see “Parameters” in the entry for ksh in the Utilities Reference.
|
|
|
|