Chapter 13. User Environments(第13章 用户環境)
This book’s primary focus is on the Linux system that normally lies underneath server processes and interactive user sessions. But eventually, the system and the user have to meet somewhere. Startup files play an important role at this point, because they set defaults for the shell and other interactive programs. They determine how the system behaves when a user logs in.
這本書的主要關注點是位於服務器進程和交互式用户會話之下的Linux系統。
但最終,系統和用户必須在某個地方相遇。
啓動文件在這一點上起着重要作用,因為它們為shell和其他交互式程序設置了默認值。
它們決定了用户登錄時系統的行為方式。
Most users don’t pay close attention to their startup files, only touching them when they want to add something for convenience, such as an alias. Over time, the files become cluttered with unnecessary environment variables and tests that can lead to annoying (or quite serious) problems.
大多數用户在啓動文件上並不關注,只有在想要添加一些方便的內容時才會涉及,比如別名。
隨着時間的推移,這些文件會積累一些不必要的環境變量和測試,可能會導致煩人(或相當嚴重的)問題。
If you’ve had your Linux machine for a while, you may notice that your home directory accumulates a bafflingly large array of startup files over time. These are sometimes called dot files because they nearly always start with a dot (.). Many of these are automatically created when you first run a program, and you’ll never need to change them. This chapter primarily covers shell startup files, which are the ones you’re most likely to modify or rewrite from scratch. Let’s first look at how much care you need to take when working on these files.
如果你使用Linux機器已經有一段時間了,你可能會注意到你的主目錄隨着時間的推移積累了大量令人困惑的啓動文件。
它們有時被稱為點文件,因為它們幾乎總是以點(.)開頭。
其中許多是在你第一次運行程序時自動創建的,你永遠不需要更改它們。
本章主要介紹了shell啓動文件,這些文件是你最有可能修改或從頭開始重寫的文件。
讓我們首先看看在處理這些文件時需要注意多少。
13.1 Guidelines for Creating Startup Files(創建創業文件的指南)
When designing startup files, keep the user in mind. If you’re the only user on a machine, you don’t have much to worry about because errors only affect you and they’re easy enough to fix. However, if you’re creating startup files meant to be the defaults for all new users on a machine or network, or if you think that someone might copy your files for use on a different machine, your task becomes considerably more difficult. If you make an error in a startup file for 10 users, you might end up fixing this error 10 times.
在設計啓動文件時,要考慮到用户的需求。
如果你是機器上唯一的用户,那麼你就沒什麼可擔心的,因為錯誤只會影響到你自己,並且很容易修復。
但是,如果你正在創建啓動文件,這些文件將成為機器或網絡上所有新用户的默認設置,或者你認為有人可能會複製你的文件在另一台機器上使用,那麼你的任務就會變得更加困難。
如果你在為10個用户創建啓動文件時犯了一個錯誤,那麼你可能需要修復這個錯誤10次。
Keep two essential goals in mind when creating startup files for other users:
在為其他用户創建啓動文件時,要牢記兩個基本目標:
o Simplicity. Keep the number of startup files small, and keep the files as small and simple as possible so that they are easy to modify but hard to break. Each item in a startup file is just one more thing that can break.
o Readability. Use extensive comments in files so that the users get a good picture of what each part of a file does.
- 簡單性。保持啓動文件的數量較少,使文件儘可能簡單,這樣它們就容易修改但不容易出錯。啓動文件中的每一項都可能導致出錯。
-
可讀性。在文件中使用大量註釋,以便用户清楚瞭解文件的每個部分的作用。
13.2 When to Alter Startup Files(何時修改啓動文件)
Before making a change to a startup file, ask yourself whether you really should be making that change. Here are some good reasons for changing startup files
在對啓動文件進行更改之前,請問自己是否真的應該進行這種更改。以下是更改啓動文件的一些好理由:
o You want to change the default prompt.
o You need to accommodate some critical locally installed software. (Consider using wrapper scripts first, though.)
o Your existing startup files are broken. If everything in your Linux distribution works, be careful. Sometimes the default startup files interact with other files in /etc.:
o Your existing startup files are broken.
- 您想要更改默認提示符。
- 您需要適應一些關鍵的本地安裝軟件。(不過,首先考慮使用包裝腳本。)
- 您現有的啓動文件已損壞。如果您的Linux發行版的一切正常,請小心。有時默認的啓動文件會與/etc目錄中的其他文件相互作用。
- 您現有的啓動文件已損壞。
If everything in your Linux distribution works, be careful. Sometimes the default startup files interact with other files in /etc.
如果您的Linux發行版的一切正常,請小心。
有時默認的啓動文件會與/etc目錄中的其他文件相互作用。
That said, you probably wouldn’t be reading this chapter if you weren’t interested in changing the defaults, so let’s examine what’s important.
話雖如此,如果您對更改默認設置不感興趣,您可能不會閲讀本章,所以讓我們來看看什麼是重要的。
13.3 Shell Startup File Elements(Shell 啓動文件元素)
What goes into a shell startup file? Some things might seem obvious, such as the path and a prompt setting. But what exactly should be in the path, and what does a reasonable prompt look like? And how much is too much to put in a startup file?
shell 啓動文件包含哪些內容?有些東西看似顯而易見,比如路徑和提示設置。
但路徑中到底應該包含哪些內容,合理的提示符應該是什麼樣的?在啓動文件中放多少內容才算多?
The next few sections discuss the essentials of a shell startup file—from the command path, prompt, and aliases through the permissions mask.
接下來的幾節將討論 shell 啓動文件的基本要素--從命令路徑、提示符和別名到權限掩碼。
13.3.1 The Command Path(命令路徑)
The most important part of any shell startup file is the command path. The path should cover the directories that contain every application of interest to a regular user. At the very least, the path should contain these components, in order:
任何shell啓動文件中最重要的部分是命令路徑。
路徑應該包括包含對常規用户有興趣的每個應用程序的目錄。
至少,路徑應按照以下順序包含以下組件:
/usr/local/bin
/usr/bin
/bin
This order ensures that you can override standard default programs with site-specific variants located in /usr/local.
這個命令確保您可以用位於/usr/local目錄下的特定於站點的變體覆蓋標準的默認程序。
Most Linux distributions install executables for nearly all packaged software in /usr/bin. There are occasional differences, such as putting games in /usr/games and graphical applications in a separate location, so check your system’s defaults first. And make sure that every general-use program on the system is available through one of the directories listed above. If not, your system is probably getting out of control. Don’t change the default path in your user environment to accommodate a new software installation directory. A cheap way to accommodate separate installation directories is to use symbolic links in /usr/local/bin.
大多數Linux發行版將幾乎所有打包軟件的可執行文件安裝在/usr/bin目錄下。
有時會有一些區別,比如將遊戲放在/usr/games目錄下,將圖形應用程序放在其他位置,所以請先檢查系統的默認設置。
確保系統上的每個通用程序都可以通過上述目錄之一訪問。
如果不能,那麼您的系統可能已經失控了。
不要更改用户環境中的默認路徑以適應新的軟件安裝目錄。
一個簡單的方法是在/usr/local/bin目錄中使用符號鏈接來容納獨立的安裝目錄。
Many users use a bin directory of their own to store shell scripts and programs, so you may want to add this to the front of the path:
許多用户使用自己的bin目錄來存儲shell腳本和程序,所以您可能希望將其添加到路徑的前面:
$HOME/bin
NOTE A newer convention is to place binaries in $HOME/.local/bin.
注意 新的慣例是將二進制文件放在 $HOME/.local/bin。
If you’re interested in systems utilities (such as traceroute, ping, and lsmod), add the sbin directories to your path:
如果你對系統實用程序(如 traceroute、ping 和 lsmod)感興趣,請在路徑中添加 sbin 目錄:
/usr/local/sbin
/usr/sbin
/sbin
Adding Dot (.) to the Path(在路徑中添加點 (.))
There is one small but controversial command path component to discuss: the dot. Placing a dot (.) in your path allows you to run programs in the current directory without using ./ in front of the program name. This may seem convenient when writing scripts or compiling programs, but it’s a bad idea for two reasons:
有一個小但有爭議的命令路徑組件需要討論:點號(.)。
在路徑中加入一個點號(.)可以讓你在當前目錄中運行程序,而無需在程序名稱前加上./。
這在編寫腳本或編譯程序時可能很方便,但出於以下兩個原因,這是一個不好的主意:
o It can be a security problem. You should never put a dot at the front of the path. Here’s an example of what can happen: An attacker could put a Trojan horse named ls in an archive distributed on the Internet. Even if a dot were at the end of the path, you’d still be vulnerable to typos such as sl or ks.
o It is inconsistent and can be confusing. A dot in a path can mean that a command’s behavior will change according to the current directory.
o 它可能會造成安全問題。你絕不應該在路徑的開頭放置一個點號。
下面是一個可能發生的例子:攻擊者可以在互聯網上分發一個名為ls的特洛伊木馬。
即使路徑的末尾有一個點號,你仍然容易受到類似於sl或ks的拼寫錯誤的影響。
o 它不一致且容易引起混淆。路徑中的點號可能意味着命令的行為會根據當前目錄而改變。
13.3.2 The Manual Page Path(手冊頁面路徑)
The traditional manual page path was determined by the MANPATH environment variable, but you shouldn’t set it because doing so overrides the system defaults in /etc/manpath.config.
傳統的手動頁面路徑是由MANPATH環境變量確定的,但是您不應該設置它,因為這樣會覆蓋/etc/manpath.config中的系統默認值。
13.3.3 The Prompt(提示)
Experienced users tend to avoid long, complicated, useless prompts. In comparison, many administrators and distributions drag everything into a default prompt. Your choice should reflect your users’ needs; place the current working directory, hostname, and username in the prompt if it really helps.
Above all, avoid characters that mean something significant to the shell, such as these:
有經驗的用户往往會避免使用冗長、複雜和無用的提示符。
相比之下,許多管理員和發行版會將所有內容都放入默認提示符中。
您的選擇應該反映出用户的需求;只有在確實有幫助時,才將當前工作目錄、主機名和用户名放入提示符中。
最重要的是,避免使用對shell來説具有重要意義的字符,比如以下字符:
{ } = & < >
NOTE Take extra care to avoid the > character, which can cause erratic, empty files to appear in your current directory if you accidentally copy and paste a section of your shell window (recall that > redirects output to a file).
注意:要格外小心避免使用大於號(>)字符,因為如果你在shell窗口中意外複製粘貼一部分內容,可能會導致在當前目錄中出現不穩定的空文件(請回憶一下,> 用於將輸出重定向到文件)。
Even a shell’s default prompt isn’t ideal. For example, the default bash prompt contains the shell name and version number.
即使是shell的默認提示符也不是最理想的。例如,默認的bash提示符包含了shell的名稱和版本號。
This simple prompt setting for bash ends with the customary $ (the traditional csh prompt ends with %):
對於bash的這個簡單提示符設置以$符號結尾(傳統的csh提示符以%結尾)。
PS1='\u\$ '
The \u is a substitution for the current username (see the PROMPTING section of the bash(1) manual page). Other popular substitutions include the following:
\u 是當前用户名的替代符號(請參閲 bash(1) 手冊頁的 PROMPTING 部分)。其他常用的替代包括以下內容:
o \h The hostname (the short form, without domain names)
o \! The history number
o \w The current directory. Because this can become long, you can limit the display to just the final component with \W.
o $ $ if running as a user account, # if root
- \h 主機名(短格式,不包含域名)
- \! 歷史記錄編號
- \w 當前目錄。由於路徑可能很長,您可以使用 \W 來僅顯示最後一個組件。
-
$ 如果作為用户賬户運行,則為 $,如果是 root 則為 #。
13.3.4 Aliases(別名)
Among the stickier points of modern user environments is the role of aliases, a shell feature that substitutes one string for another before executing a command. These can be efficient shortcuts that save some typing. However, aliases also have these drawbacks:
在現代用户環境中,一個較為棘手的問題是別名的角色,別名是一種在執行命令之前用一個字符串替換另一個字符串的 shell 功能。
這些可以是高效的快捷方式,可以節省一些輸入。
然而,別名也存在以下缺點:
o It can be tricky to manipulate arguments.
o They are confusing; a shell’s built-in which command can tell you if something is an alias, but it won’t tell you where it was defined.
o They are frowned upon in subshells and noninteractive shells; they do not work in other shells.
- 操縱參數可能有些棘手。
- 它們會讓人感到困惑;shell 內置的 which 命令可以告訴你某個東西是否是別名,但它不會告訴你別名是在哪裏定義的。
- 在子 shell 和非交互式 shell 中,別名不受歡迎;它們在其他 shell 中不起作用。
Given these disadvantages, you should probably avoid aliases whenever possible because it’s easier to write a shell function or an entirely new shell script. Modern computers can start and execute shells so quickly that the difference between an alias and an entirely new command should mean nothing to you.
考慮到這些缺點,儘可能避免使用別名,因為編寫一個 shell 函數或者一個全新的 shell 腳本會更容易。
現代計算機啓動和執行 shell 的速度如此之快,以至於別名和全新命令之間的區別對你來説應該毫無意義。
That said, aliases do come in handy when you wish to alter a part of the shell’s environment. You can’t change an environment variable with a shell script, because scripts run as subshells. (You can also define shell functions to perform this task.)
話雖如此,當你希望修改 shell 環境的一部分時,別名確實會派上用場。
你無法通過 shell 腳本更改環境變量,因為腳本會作為子 shell 運行。(你也可以定義 shell 函數來執行此任務。)
13.3.5 The Permissions Mask(權限掩碼)
As described in Chapter 2, a shell’s built-in umask (permissions mask) facility sets your default permissions. You should run umask in one of your startup files to make certain that any program you run creates files with your desired permissions. The two reasonable choices are these:
如第二章所述,shell的內置umask(權限掩碼)功能用於設置默認權限。
您應該在啓動文件中運行umask,以確保您運行的任何程序都以您所需的權限創建文件。有兩個合理的選擇:
o 077 This mask is the most restrictive permissions mask because it doesn’t give any other users access to new files and directories. This is often appropriate on a multi-user system where you don’t want other users to look at any of your files. However, when set as the default, it can sometimes lead to problems when your users want to share files but don’t understand how to set permissions correctly. (Inexperienced users have a tendency to set files to a world-writable mode.)
o 022 This mask gives other users read access to new files and directories. This can be important on a singleuser system because many daemons that run as pseudo-users are not be able to see files and directories created with the more restrictive 077 umask.
o 077 這個掩碼是最嚴格的權限掩碼,因為它不允許其他用户訪問新文件和目錄。
這在多用户系統中通常是適用的,因為您不希望其他用户查看您的任何文件。
然而,當設置為默認值時,當用户想要共享文件但不瞭解如何正確設置權限時,可能會導致問題。
(經驗不足的用户有將文件設置為可寫入模式的傾向。)
o 022 這個掩碼允許其他用户對新文件和目錄進行讀取訪問。這在單用户系統中可能很重要,因為許多以偽用户身份運行的守護進程無法看到使用更嚴格的077 umask創建的文件和目錄。
NOTE Certain applications (especially mail programs) override the umask, changing it to 077 because they feel that their files are the business of no one but the file owner.
注意 某些應用程序(特別是郵件程序)會覆蓋umask,將其更改為077,因為它們認為它們的文件只屬於文件所有者。
13.4 Startup File Order and Examples(啓動文件順序和示例)
Now that you know what to put into shell startup files, it’s time to see some specific examples. Surprisingly, one of the most difficult and confusing parts of creating startup files is determining which of several startup files to use. The next sections cover the two most popular Unix shells: bash and tcsh.
既然你已經知道要將什麼內容放入shell啓動文件中,現在是時候看一些具體的示例了。
令人驚訝的是,創建啓動文件中最困難和令人困惑的部分之一是確定要使用哪個啓動文件中的幾個。
接下來的部分將介紹兩種最流行的Unix shell:bash和tcsh。
13.4.1 The bash Shell
In bash, you can choose from the startup filenames .bash_profile, .profile, .bash_login, and .bashrc. Which one is appropriate for your command path, manual page path, prompt, aliases, and permissions mask? The answer is that you should have a .bashrc file accompanied by a .bash_profile symbolic link pointing to .bashrc because there are a few different kinds of bash shell instance types.
在bash中,你可以從以下啓動文件名中選擇:.bash_profile、.profile、.bash_login和.bashrc。
哪一個適合你的命令路徑、手冊頁路徑、提示符、別名和權限掩碼?
答案是你應該有一個伴隨着一個指向.bashrc的.bash_profile符號鏈接的.bashrc文件,因為有幾種不同類型的bash shell實例。
The two main shell instance types are interactive and noninteractive, but of those, only interactive shells are of interest because noninteractive shells (such as those that run shell scripts) usually don’t read any startup files. Interactive shells are the ones that you use to run commands from a terminal, such as the ones you’ve seen in this book, and they can be classified as login or non-login.
主要的兩種shell實例類型是交互式和非交互式,但其中只有交互式shell是感興趣的,因為非交互式shell(例如運行shell腳本的shell)通常不會讀取任何啓動文件。
交互式shell是你用來從終端運行命令的那些,就像你在本書中看到的那些,它們可以被分類為登錄或非登錄。
Login Shells(登陸 Shell)
Traditionally, a login shell is what you get when you first log in to a system with the terminal using a program such as /bin/login. Logging in remotely with SSH also gives you a login shell. The basic idea is that the login shell is an initial shell. You can tell if a shell is a login shell by running echo $0; if the first character is a -, the shell’s a login shell.
傳統上,登錄 shell 是當你使用類似 /bin/login 的程序在終端上首次登錄系統時所得到的。
通過 SSH 遠程登錄也會給你一個登錄 shell。
基本的概念是,登錄 shell 是一個初始的 shell。
你可以通過運行 echo $0 來判斷一個 shell 是否是登錄 shell;
如果第一個字符是 -,那麼這個 shell 就是一個登錄 shell。
When bash runs as a login shell, it runs /etc/profile. Then it looks for a user’s .bash_profile, .bash_login, and .profile files, running only the first one that it sees.
當 bash 作為登錄 shell 運行時,它會運行 /etc/profile。然後它會尋找用户的 .bash_profile、.bash_login 和 .profile 文件,並且只運行它所找到的第一個文件。
As strange as it sounds, it’s possible to run a noninteractive shell as a login shell to force it to run startup files. To do so, start the shell with the -l or --login option
儘管聽起來很奇怪,但也有可能將一個非交互式的 shell 作為登錄 shell 運行,以強制它運行啓動文件。
要這樣做,可以使用 -l 或 --login 選項啓動 shell。
Non-Login Shells(非登錄 shell)
A non-login shell is an additional shell that you run after you log in. It’s simply any interactive shell that’s not a login shell. Windowing system terminal programs (xterm, GNOME Terminal, and so on) start non-login shells unless you specifically ask for a login shell.
非登錄shell是在登錄後運行的額外shell。它只是一個交互式的shell,不是登錄shell。
窗口系統終端程序(如xterm、GNOME Terminal等)在沒有明確要求登錄shell的情況下啓動非登錄shell。
Upon starting up as a non-login shell, bash runs /etc/bash.bashrc and then runs the user’s .bashrc.
作為非登錄shell啓動時,bash會運行/etc/bash.bashrc,然後運行用户的.bashrc文件。
The Consequences of Two Kinds of Shells(兩種貝殼的後果)
The reasoning behind the two different startup filesystems is that in the old days, users logged in through a traditional terminal with a login shell, then started non-login subshells with windowing systems or the screen program. For the non-login subshells, it was deemed a waste to repeatedly set the user environment and run a bunch of programs that had already been run. With login shells, you could run fancy startup commands in a file such as .bash_profile, leaving only aliases and other “lightweight” things to your .bashrc.
兩種不同的啓動文件系統背後的原因是,在過去的日子裏,用户通過傳統終端登錄,然後通過窗口系統或屏幕程序啓動非登錄子shell。
對於非登錄子shell來説,重複設置用户環境並運行已經運行過的一堆程序被認為是浪費。
通過登錄shell,您可以在類似.bash_profile的文件中運行花哨的啓動命令,只留下別名和其他“輕量級”內容在.bashrc中。
Nowadays, most desktop users log in through a graphical display manager (you’ll learn more about these in the next chapter). Most of these start with one noninteractive login shell in order to preserve the login versus non-login model described above. When they do not, you need to set up your entire environment (path, manual path, and so on) in your .bashrc, or you’ll never see any of your environment in your terminal window shells. However, you also need a .bash_profile if you ever want to log in on the console or remotely, because those login shells don’t ever bother with .bashrc.
如今,大多數桌面用户通過圖形顯示管理器登錄(您將在下一章中瞭解更多相關信息)。
其中大部分都會啓動一個非交互式登錄shell,以保留上述登錄與非登錄模型。
如果沒有啓動非交互式登錄shell,您需要在.bashrc中設置整個環境(路徑、手動路徑等),否則您將無法在終端窗口shell中看到任何環境。
然而,如果您想在控制枱或遠程登錄,您還需要一個.bash_profile,因為這些登錄shell從不關心.bashrc。
Example .bashrc(.bashrc 示例)
In order to satisfy both non-login and login shells, how would you create a .bashrc that can also be used as your .bash_profile? Here’s one very elementary (yet perfectly sufficient) example:
為了同時滿足非登錄和登錄 shell 的需要,你該如何創建一個 .bashrc 文件,並將其用作 .bash_profile 文件呢?
下面是一個非常簡單(但完全足夠)的例子:
# Command path.
PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
PATH=$HOME/bin:$PATH
# PS1 is the regular prompt.
# Substitutions include:
# \u username \h hostname \w current directory
# \! history number \s shell name \$ $ if regular user
PS1='\u\$ '
# EDITOR and VISUAL determine the editor that programs such as less
# and mail clients invoke when asked to edit a file.
EDITOR=vi
VISUAL=vi
# PAGER is the default text file viewer for programs such as man.
PAGER=less
# These are some handy options for less.
# A different style is LESS=FRX
# (F=quit at end, R=show raw characters, X=don't use alt screen)
LESS=meiX
# You must export environment variables.
export PATH EDITOR VISUAL PAGER LESS
# By default, give other users read-only access to most new files.
umask 022
As described earlier, you can share this .bashrc file with .bash_profile via a symbolic link, or you can make the relationship even clearer by creating .bash_profile as this one-liner:
如前所述,你可以通過符號鏈接將 .bashrc 文件與 .bash_profile 文件共享,也可以將 .bash_profile 創建為單行文件,使兩者之間的關係更加清晰:
. $HOME/.bashrc
Checking for Login and Interactive Shells(檢查登錄和交互式Shell)
With a .bashrc matching your .bash_profile, you don’t normally run extra commands for login shells. However, if you want to define different actions for login and non-login shells, you can add the following test to your .bashrc, which checks the shell’s $- variable for an i character:
如果你的 .bashrc 文件與你的 .bash_profile 文件相匹配,通常不需要為登錄Shell運行額外的命令。
然而,如果你想為登錄和非登錄Shell定義不同的操作,你可以在你的 .bashrc 文件中添加以下測試,它會檢查Shell的 $- 變量是否包含字符 "i":
case $- in
*i*) # interactive commands go here
command
--snip--
;;
*) # non-interactive commands go here
command
--snip-
;;
esac
13.4.2 The tcsh Shell(tcsh Shell)
The standard csh on virtually all Linux systems is tcsh, an enhanced C shell that popularized features such as command-line editing and multi-mode filename and command completion. Even if you don’t use tcsh as the default new user shell (we suggest using bash), you should still provide tcsh startup files in case your users happen to come across tcsh. You don’t have to worry about the difference between login shells and non-login shells in tcsh. Upon startup, tcsh looks for a .tcshrc file. Failing this, it looks for the csh shell’s .cshrc startup file. The reason for this order is that you can use the .tcshrc file for tcsh extensions that don’t work in csh. You should probably stick to using the traditional .cshrc instead of .tcshrc; it’s highly unlikely that anyone will ever use your startup files with csh. And if a user actually does come across csh on some other system, your .cshrc will work.
幾乎所有Linux系統上的標準csh都是tcsh,這是一個增強型的C shell,它推廣了命令行編輯、多模式文件名和命令補全等功能。
即使您不使用tcsh作為默認的新用户shell(我們建議使用bash),您仍然應該提供tcsh的啓動文件,以防萬一您的用户碰巧遇到tcsh。
您不必擔心tcsh中登錄shell和非登錄shell之間的區別。
在啓動時,tcsh會尋找.tcshrc文件。如果找不到,它會尋找csh shell的.cshrc啓動文件。
之所以採用這個順序,是因為您可以使用.tcshrc文件來進行tcsh擴展,而這些擴展在csh中不起作用。
您應該使用傳統的.cshrc文件而不是.tcshrc文件;幾乎沒有人會在csh中使用您的啓動文件。
而且,如果用户在其他系統上真的遇到csh,您的.cshrc文件也會起作用。
Example .cshrc(.cshrc 示例)
Here is sample .cshrc file:
下面是 .cshrc 文件的示例:
# Command path.
setenv PATH /usr/local/bin:/usr/bin:/bin:$HOME/bin
# EDITOR and VISUAL determine the editor that programs such as less
# and mail clients invoke when asked to edit a file.
setenv EDITOR vi
setenv VISUAL vi
# PAGER is the default text file viewer for programs such as man.
setenv PAGER less
# These are some handy options for less.
setenv LESS meiX
# By default, give other users read-only access to most new files.
umask 022
# Customize the prompt.
# Substitutions include:
# %n username %m hostname %/ current directory
# %h history number %l current terminal %% %
set prompt="%m%% "
13.5 Default User Settings(用户默認設置)
The best way to write startup files and choose defaults for new users is to experiment with a new test user on the system. Create the test user with an empty home directory and refrain from copying your own startup files to the test user’s directory. Write the new startup files from scratch
編寫啓動文件並選擇新用户的默認設置的最佳方法是在系統上使用一個新的測試用户進行實驗。
創建一個空的家目錄並避免將自己的啓動文件複製到測試用户的目錄中。
從頭開始編寫新的啓動文件。
When you think you have a working setup, log in as the new test user in all possible ways (on the console, remotely, and so on). Make sure that you test as many things as possible, including the windowing system operation and manual pages. When you’re happy with the test user, create a second test user, copying the startup files from the first test user. If everything still works, you now have a new set of startup files that you can distribute to new users.
當您認為已經設置好了,以所有可能的方式(在控制枱上、遠程等)作為新的測試用户登錄。
確保儘可能多地測試各種事物,包括窗口系統操作和手冊頁。當您對測試用户滿意時,創建第二個測試用户,並從第一個測試用户複製啓動文件。
如果一切正常,您現在有一組新的啓動文件可以分發給新用户。
The following sections outline reasonable defaults for new users.
以下部分概述了新用户的合理默認設置。
13.5.1 Shell Defaults(shell 默認值)
The default shell for any new user on a Linux system should be bash because:
任何Linux系統上新用户的默認shell應該是bash,因為:
o Users interact with the same shell that they use to write shell scripts (for example, csh is a notoriously bad
scripting tool—don’t even think about it).
o bash is standard on Linux systems.
o bash uses GNU readline, and therefore its interface is identical to that of many other tools.
o bash gives you fine, easy-to-understand control over I/O redirection and file handles.
o 用户與用於編寫shell腳本的相同shell進行交互(例如,csh是一個臭名昭著的糟糕腳本工具-甚至不要想)。
o bash在Linux系統上是標準的。
o bash使用GNU readline,因此其界面與許多其他工具的界面完全相同。
o bash提供了對I/O重定向和文件句柄的精細且易於理解的控制。
However, many seasoned Unix wizards use shells such as csh and tcsh simply because they can’t bear to switch. Of course, you can choose any shell you like, but choose bash if you don’t have any preference, and use bash as the default shell for any new user on the system. (A user can change his or her shell with the chsh command to suit individual preferences.)
然而,許多經驗豐富的Unix專家使用csh和tcsh等shell,僅僅是因為他們無法忍受切換。
當然,您可以選擇任何您喜歡的shell,但如果沒有任何偏好,請選擇bash,並將其作為系統上任何新用户的默認shell。
(用户可以使用chsh命令更改他們的shell以適應個人偏好。)
NOTE There are plenty of other shells out there (rc, ksh, zsh, es, and so on). Some are not appropriate as beginner shells, but zsh and fish are sometimes popular with new users looking for an alternative shell.
注意 還有很多其他的shell(rc,ksh,zsh,es等)。
有些不適合初學者使用的shell,但zsh和fish有時受到新用户的歡迎,他們在尋找替代shell時會選擇這兩個。
13.5.2 Editor(編輯)
On a traditional system, the default editor should be vi or emacs. These are the only editors virtually guaranteed to exist on nearly any Unix system, which means they’ll cause the least trouble in the long run for a new user. However, Linux distributions often configure nano to be the default editor, because it’s easier for beginners to use.
在傳統的系統上,默認的編輯器應該是vi或者emacs。
幾乎所有的Unix系統都會有這兩個編輯器,這意味着對於新用户來説,它們會在長期使用中帶來最少的麻煩。
然而,Linux發行版通常將nano配置為默認編輯器,因為它對於初學者來説更容易使用。
As with shell startup files, avoid large default editor startup files. A little set showmatch in the .exrc startup file never hurt anyone but steer clear of anything that significantly changes the editor’s behavior or appearance, such as the showmode feature, auto-indentation, and wrap margins.
與shell啓動文件一樣,避免使用過大的默認編輯器啓動文件。
在.exrc啓動文件中設置一些簡單的showmatch功能是沒有問題的,但要避免使用任何顯著改變編輯器行為或外觀的功能,比如showmode特性、自動縮進和換行邊界。
13.5.3 Pager(呼叫器)
It’s perfectly reasonable to set the default PAGER environment variable to less
將默認的PAGER環境變量設置為less是完全合理的。
13.6 Startup File Pitfalls(啓動文件陷阱)
Avoid these in startup files:
在啓動文件中避免以下內容:
o Don’t put any kind of graphical command in a shell startup file.
o Don’t set the DISPLAY environment variable in a shell startup file.
o Don’t set the terminal type in a shell startup file.
o Don’t skimp on descriptive comments in default startup files.
o Don’t run commands in a startup file that print to the standard output.
o Never set LD_LIBRARY_PATH in a shell startup file (see 15.1.4 Shared Libraries).
- 不要在shell啓動文件中放置任何圖形命令。
- 不要在shell啓動文件中設置DISPLAY環境變量。
- 不要在shell啓動文件中設置終端類型。
- 在默認的啓動文件中不要吝嗇描述性註釋。
- 不要在啓動文件中運行打印到標準輸出的命令。
-
絕對不要在shell啓動文件中設置LD_LIBRARY_PATH變量(參見15.1.4共享庫)。
13.7 Further Startup Topics(更多創業主題)
Because this book deals only with the underlying Linux system, we won’t cover windowing environment startup files. This is a large issue indeed, because the display manager that logs you in to a modern Linux system has its own set of startup files, such as .xsession, .xinitrc, and the endless combinations of GNOMEand KDE-related items.
因為本書僅涉及Linux系統的基礎部分,我們不會涵蓋窗口環境啓動文件。
這確實是一個重要問題,因為登錄到現代Linux系統的顯示管理器有自己的一套啓動文件,例如.xsession、.xinitrc以及與GNOME和KDE相關的無盡組合。
The windowing choices may seem bewildering, and there is no one common way to start a windowing environment in Linux. The next chapter describes some of the many possibilities. However, when you determine what your system does, you may get a little carried away with the files that relate to your graphical environment. That’s fine, but don’t carry it over to new users. The same tenet of keeping things simple in shell startup files works wonders for GUI startup files, too. In fact, you probably don’t need to change your GUI startup files at all.
窗口環境的選擇可能令人困惑,並且在Linux中沒有一種通用的啓動窗口環境的方法。
下一章將介紹一些許多可能性。
然而,當你確定了你的系統所做的事情時,你可能會對與你的圖形環境相關的文件感到有些着迷。
這沒問題,但不要把它帶給新用户。
在shell啓動文件中保持簡單的原則同樣適用於GUI啓動文件。
實際上,你可能根本不需要改變你的GUI啓動文件。